oracle查询本身字符集,ORACLE字符集查看

ORACLE字符集查看

2007-08-20 17:45

1、查询oracle

server端的字符集

有很多种方法可以查出oracle

server端的字符集，比较直观的查询方法是以下这种:

select

userenv('language') from dual;

结果类似如下 :AMERICAN _ AMERICA.

ZHS16GBK 或：

select * from

nls_database_parameters;

结果类似如下:ZHS16GBK

2、如何查询dmp文件的字符集

用oracle的exp工具导出的dmp文件也包含了字符集信息，dmp文件的第2和第3个字节记录了dmp文件的字符集。如果dmp文件不大，比如只有几M或几十M，可以用UltraEdit打开(16进制方式)，看第2第3个字节的内容，如0354，然后用以下SQL查出它对应的字符集:

select

nls_charset_name(to_number('0354','xxxx')) from

dual;

ZHS16GBK

如果dmp文件很大，比如有2G以上(这也是最常见的情况)，用文本编辑器打开很慢或者完全打不开，可以用以下命令(在unix主机上):

cat exp.dmp |od

-x|head -1|awk '{print $2 $3}'|cut -c 3-6

然后用上述SQL也可以得到它对应的字符集。

3、查询oracle

client端的字符集

select * from

nls_instance_parameters;

这个比较简单。在windows平台下，就是注册表里面相应OracleHome的NLS_LANG。还可以在dos窗口里面自己设置，比如:

set

nls_lang=AMERICAN_AMERICA.ZHS16GBK

这样就只影响这个窗口里面的环境变量。

在unix平台下，就是环境变量NLS_LANG。

$echo $NLS_LANG

AMERICAN_AMERICA.ZHS16GBK

导入导出数据时，需要保证3者相同字符集

[Q]怎么样查看数据库字符集

[A]数据库服务器字符集select * from

nls_database_parameters，其来源于props$，是表示数据库的字符集。

客户端字符集环境select * from

nls_instance_parameters,其来源于v$parameter，

表示客户端的字符集的设置，可能是参数文件，环境变量或者是注册表

会话字符集环境 select * from

nls_session_parameters，其来源于v$nls_parameters，表示会话自己的设置，可能是会话的环境变量或者是alter

session完成，如果会话没有特殊的设置，将与nls_instance_parameters一致。

客户端的字符集要求与服务器一致，才能正确显示数据库的非Ascii字符。如果多个设置存在的时候，alter

session>环境变量>注册表>参数文件

字符集要求一致，但是语言设置却可以不同，语言设置建议用英文。如字符集是zhs16gbk，则nls_lang可以是American_America.zhs16gbk。

[Q]怎么样修改字符集

[A]8i以上版本可以通过alter

database来修改字符集，但也只限于子集到超集，不建议修改props$表，将可能导致严重错误。

Startup nomount;

Alter database mount exclusive;

Alter system enable restricted session;

Alter system set job_queue_process=0;

Alter database open;

Alter database character set zhs16gbk;

Oracle数据库字符集问题解析

经常看到一些朋友问ORACLE字符集方面的问题，我想以迭代的方式来介绍一下。

第一次迭代：掌握字符集方面的基本概念。

有些朋友可能会认为这是多此一举，但实际上正是由于对相关基本概念把握不清，才导致了诸多问题和疑问。

首先是字符集的概念。

我们知道，电子计算机最初是用来进行科学计算的(所以叫做“计算机”)，但随着技术的发展，还需要计算机进行其它方面的应用处理。这就要求计算机不仅能处理数值，还能处理诸如文字、特殊符号等其它信息，而计算机本身能直接处理的只有数值信息，所以就要求对这些文字、符号信息进行数值编码，最初的字符集是我们都非常熟悉的ASCII，它是用7个二进制位来表示128个字符，而后来随着不同国家、组织的需要，出现了许许多多的字符集，如表示西欧字符的ISO8859系列的字符集，表示汉字的GB2312-80、GBK等字符集。

字符集的实质就是对一组特定的符号，分别赋予不同的数值编码，以便于计算机的处理。

字符集之间的转换。字符集多了，就会带来一个问题，比如一个字符，在某一字符集中被编码为一个数值，而在另一个字符集中被编码为另一个数值，比如我来创造两个字符集demo_charset1与demo_charset2，在demo_charset1中，我规定了三个符号的编码为：A(0001)，B(0010)，？(1111)；而在demo_charset2中，我也规定了三个符号的编码为：A(1001)，C(1011)，？(1111)，这时我接到一个任务，要编写一个程序，负责在demo_charset1与demo_charset2之间进行转换。由于知道两个字符集的编码规则，对于demo_charset1中的0001，在转换为demo_charset2时，要将其编码改为1001；对于demo_charset1中的1111，转换为demo_charset2时，其数值不变；而对于demo_charset1中的0010，其对应的字符为B，但在demo_charset2没有对应的字符，所以从理论上无法转换，对于所有这类无法转换的情况，我们可以将它们统一转换为目标字符集中的一个特殊字符(称为“替换字符”)，比如在这里我们可以将？作为替换字符，所以B就转换为了？，出现了信息的丢失；同样道理，将demo_charset2的C字符转换到demo_charset1时，也会出现信息丢失。

所以说，在字符集转换过程中，如果源字符集中的某个字符在目标字符集中没有定义，将会出现信息丢失。

数据库字符集的选择。

我们在创建数据库时，需要考虑的一个问题就是选择什么字符集与国家字符集(通过create database中的CHARACTER

SET与NATIONAL CHARACTER

SET子句指定)。考虑这个问题，我们必须要清楚数据库中都需要存储什么数据，如果只需要存储英文信息，那么选择US7ASCII作为字符集就可以；但是如果要存储中文，那么我们就需要选择能够支持中文的字符集(如ZHS16GBK)；如果需要存储多国语言文字，那就要选择UTF8了。

数据库字符集的确定，实际上说明这个数据库所能处理的字符的集合及其编码方式，由于字符集选定后再进行更改会有诸多的限制，所以在数据库创建时一定要考虑清楚后再选择。

而我们许多朋友在创建数据库时，不考虑清楚，往往选择一个默认的字符集，如WE8ISO8859P1或US7ASCII，而这两个字符集都没有汉字编码，所以用这种字符集存储汉字信息从原则上说就是错误的。虽然在有些时候选用这种字符集好象也能正常使用，但它会给数据库的使用与维护带来一系列的麻烦，在后面的迭代过程中我们将深入分析。

客户端的字符集。

有过一些Oracle使用经验的朋友，大多会知道通过NLS_LANG来设置客户端的情况，NLS_LANG由以下部分组成：NLS_LANG=_.

Characterset>，其中第三部分

Characterset>的本意就是用来指明客户端操作系统缺省使用的字符集。所以按正规的用法，NLS_LANG应该按照客户端机器的实际情况进行配置，尤其对于字符集一项更是如此，这样Oracle就能够在最大程度上实现数据库字符集与客户端字符集的自动转换(当然是如果需要转换的话)。

总结一下第一次迭代的重点：

字符集：将特定的符号集编码为计算机能够处理的数值；

字符集间的转换：对于在源字符集与目标字符集都存在的符号，理论上转换将不会产生信息丢失；而对于在源字符集中存在而在目标字符集中不存在的符号，理论上转换将会产生信息丢失；

数据库字符集：选择能够包含所有将要存储的信息符号的字符集；

客户端字符集设置：指明客户端操作系统缺省使用的字符集。