Oracle字符集问题总结

收藏自某些高手的总结，不敢独享，与有缘来此者共享。

-----------------------------------------------------------------------------------

Oracle字符集问题总结

经常有同事咨询oracle数据库字符集相关的问题，如在不同数据库做数据迁移、同其它系统交换数据等，常常因为字符集不同而导致迁移失败或数据库内数据变成乱码。现在我将oracle字符集相关的一些知识做个简单总结，希望对大家今后的工作有所帮助。

　　一、什么是oracle字符集

　　Oracle字符集是一个字节数据的解释的符号集合,有大小之分,有相互的包容关系。ORACLE 支持国家语言的体系结构允许你使用本地化语言来存储，处理，检索数据。它使数据库工具，错误消息，排序次序，日期，时间，货币，数字，和日历自动适应本地化语言和平台。

　　影响oracle数据库字符集最重要的参数是NLS_LANG参数。它的格式如下:

　　NLS_LANG = language_territory.charset

　　它有三个组成部分(语言、地域和字符集)，每个成分控制了NLS子集的特性。其中:

　　Language 指定服务器消息的语言，territory 指定服务器的日期和数字格式，charset 指定字符集。如:AMERICAN _ AMERICA. ZHS16GBK

　　从NLS_LANG的组成我们可以看出，真正影响数据库字符集的其实是第三部分。所以两个数据库之间的字符集只要第三部分一样就可以相互导入导出数据，前面影响的只是提示信息是中文还是英文。

　　二、如何查询Oracle的字符集

　　很多人都碰到过因为字符集不同而使数据导入失败的情况。这涉及三方面的字符集，一是oracel server端的字符集，二是oracle client端的字符集;三是dmp文件的字符集。在做数据导入的时候，需要这三个字符集都一致才能正确导入。

　　1、查询oracle server端的字符集

　　有很多种方法可以查出oracle server端的字符集，比较直观的查询方法是以下这种:SQL>select userenv(‘language’) from dual;

　　结果类似如下:AMERICAN _ AMERICA. ZHS16GBK

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

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

　　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端的字符集

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

　　set nls_lang=AMERICAN_AMERICA.ZHS16GBK

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

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

　　$echo $NLS_LANG

　　AMERICAN_AMERICA.ZHS16GBK

　　如果检查的结果发现server端与client端字符集不一致，请统一修改为同server端相同的字符集。

　　三、修改oracle的字符集

　　上文说过，oracle的字符集有互相的包容关系。如us7ascii就是zhs16gbk的子集,从us7ascii到zhs16gbk不会有数据解释上的问题,不会有数据丢失。在所有的字符集中utf8应该是最大,因为它基于unicode,双字节保存字符(也因此在存储空间上占用更多)。

　　一旦数据库创建后，数据库的字符集理论上讲是不能改变的。因此，在设计和安装之初考虑使用哪一种字符集十分重要。根据Oracle的官方说明，字符集的转换是从子集到超集受支持,反之不行。如果两种字符集之间根本没有子集和超集的关系，那么字符集的转换是不受oracle支持的。对数据库server而言，错误的修改字符集将会导致很多不可测的后果，可能会严重影响数据库的正常运行，所以在修改之前一定要确认两种字符集是否存在子集和超集的关系。一般来说，除非万不得已，我们不建议修改oracle数据库server端的字符集。特别说明，我们最常用的两种字符集ZHS16GBK和ZHS16CGB231280之间不存在子集和超集关系，因此理论上讲这两种字符集之间的相互转换不受支持。

　　1、修改server端字符集(不建议使用)

　　在oracle 8之前，可以用直接修改数据字典表props$来改变数据库的字符集。但oracle8之后，至少有三张系统表记录了数据库字符集的信息，只改props$表并不完全，可能引起严重的后果。正确的修改方法如下:

　　$sqlplus /nolog

　　SQL>conn / as sysdba;

　　若此时数据库服务器已启动，则先执行SHUTDOWN IMMEDIATE命令关闭数据库服务器，然后执行以下命令:

　　SQL>STARTUP MOUNT;

　　SQL>ALTER SYSTEM ENABLE RESTRICTED SESSION;

　　SQL>ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;

　　SQL>ALTER SYSTEM SET AQ_TM_PROCESSES=0;

　　SQL>ALTER DATABASE OPEN;

　　SQL>ALTER DATABASE CHARACTER SET ZHS16GBK;

　　SQL>ALTER DATABASE national CHARACTER SET ZHS16GBK;

　　SQL>SHUTDOWN IMMEDIATE;

　　SQL>STARTUP

　　2、修改dmp文件字符集

　　上文说过，dmp文件的第2第3字节记录了字符集信息，因此直接修改dmp文件的第2第3字节的内容就可以‘骗’过oracle的检查。这样做理论上也仅是从子集到超集可以修改，但很多情况下在没有子集和超集关系的情况下也可以修改，我们常用的一些字符集，如US7ASCII，WE8ISO8859P1，ZHS16CGB231280，ZHS16GBK基本都可以改。因为改的只是dmp文件，所以影响不大。

　　具体的修改方法比较多，最简单的就是直接用UltraEdit修改dmp文件的第2和第3个字节。比如想将dmp文件的字符集改为ZHS16GBK，可以用以下SQL查出该种字符集对应的16进制代码:

　　SQL> select to_char(nls_charset_id('ZHS16GBK'), 'xxxx') from dual;

　　0354

　　然后将dmp文件的2、3字节修改为0354即可。

　　如果dmp文件很大，用ue无法打开，就需要用程序的方法了。网上有人用java存储过程写了转换的程序(用java存储过程的好处是通用性教好，缺点是比较麻烦)。我在windows下测试通过。但要求oracle数据库一定要安装JVM选项。有兴趣的朋友可以研究一下程序代码

-----------------------------------------------------------------------
[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; 就是将客户端字符集设置和数据库一致，其实这是没有太多根据的。
设想一下，假如数据库字符集是al32utf8,里面存储这一些中文字符，而我的客户端操作系统是英文的，此时我将客户端的nls_lang设置成al32utf8，这样会解决问题吗？这样客户端就能显示中文了吗？客户端就能输入中文了吗？现在客户端是英文的，它的字符集里根本就没有汉字的编码，我们简单的修改一下客户端的字符集又有什么用？前面已经讨论了，这个设置无非就是告诉oracle我将以什么样的字符集与数据库进行数据交换，对于解决乱码问题毫无关系。
正确的做法是将客户端的操作系统改成支持中文字符，并将客户端字符集改成和操作系统一致的字符集，这样才能真正的解决问题。
--作者 alantany

------------------------------------------------------------------------------------------
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=<Language>_<Territory>.<Clients Characterset>，其中第三部分<Clients Characterset>的本意就是用来指明客户端操作系统缺省使用的字符集。所以按正规的用法，NLS_LANG应该按照客户端机器的实际情况进行配置，尤其对于字符集一项更是如此，这样Oracle就能够在最大程度上实现数据库字符集与客户端字符集的自动转换（当然是如果需要转换的话）。
总结一下第一次迭代的重点：
字符集：将特定的符号集编码为计算机能够处理的数值；
字符集间的转换：对于在源字符集与目标字符集都存在的符号，理论上转换将不会产生信息丢失；而对于在源字符集中存在而在目标字符集中不存在的符号，理论上转换将会产生信息丢失；
数据库字符集：选择能够包含所有将要存储的信息符号的字符集；
客户端字符集设置：指明客户端操作系统缺省使用的字符集。

第二次迭代：通过实例加深对基本概念的理解
下面我将引用网友tellin在ITPUB上发表的“CHARACTER SET研究及疑问”帖子，该朋友在帖子中列举了他做的相关实验，并对实验结果提出了一些疑问，我将对他的实验结果进行分析，并回答他的疑问。
实验结果分析一

quote:
--------------------------------------------------------------------------------
最初由 tellin 发布
设置客户端字符集为US7ASCII
D:/>SET NLS_LANG=AMERICAN_AMERICA.US7ASCII
查看服务器字符集为US7ASCII
SQL> SELECT * FROM NLS_DATABASE_PARAMETERS;
PARAMETER VALUE
------------------------------ ----------------------------------------
NLS_CHARACTERSET US7ASCII

建立测试表
SQL> CREATE TABLE TEST (R1 VARCHAR2(10));

Table created.

插入数据
SQL> INSERT INTO TEST VALUES('东北');

1 row created.

SQL> SELECT * FROM TEST;

R1
----------
东北

SQL> EXIT

--------------------------------------------------------------------------------

 

这一部分的实验数据的存取与显示都正确，好象没什么问题，但实际上却隐藏着很大的隐患。
首先，要将汉字存入数据库，而将数据库字符集设置为US7ASCII是不合适的。US7ASCII字符集只定义了128个符号，并不支持汉字。另外，由于在SQL*PLUS中能够输入中文，操作系统缺省应该是支持中文的，但在NLS_LANG中的字符集设置为US7ASCII，显然也是不正确的，它没有反映客户端的实际情况。
但实际显示却是正确的，这主要是因为Oracle检查数据库与客户端的字符集设置是同样的，那么数据在客户与数据库之间的存取过程中将不发生任何转换。具体地说，在客户端输入“东北”，“东”的汉字的编码为182（10110110）、171（10101011），“北”汉字的编码为177（10110001）、177（10110001），它们将不做任何变化的存入数据库中，但是这实际上导致了数据库标识的字符集与实际存入的内容是不相符的，从某种意义上讲，这也是一种不一致性，也是一种错误。而在SELECT的过程中，Oracle同样检查发现数据库与客户端的字符集设置是相同的，所以它也将存入的内容原封不动地传送到客户端，而客户端操作系统识别出这是汉字编码所以能够正确显示。
在这个例子中，数据库与客户端的设置都有问题，但却好象起到了“负负得正”的效果，从应用的角度看倒好象没问题。但这里面却存在着极大的隐患，比如在应用length或substr等字符串函数时，就可能得到意外的结果。另外，如果遇到导入/导出（import /export）将会遇到更大的麻烦。有些朋友在这方面做了大量的测试，如eygle研究了“源数据库字符集为US7ASCII，导出文件字符集为US7ASCII或ZHS16GBK，目标数据库字符集为ZHS16GBK”的情况，他得出的结论是 “如果的是在Oracle92中，我们发现对于这种情况，不论怎样处理，这个导出文件都无法正确导入到Oracle9i数据库中”、“对于这种情况，我们可以通过使用Oracle8i的导出工具，设置导出字符集为US7ASCII，导出后修改第二、三字符，修改 0001 为0354,这样就可以将US7ASCII字符集的数据正确导入到ZHS16GBK的数据库中”。我想对于这些结论，这样理解可能更合适一些：由于ZHS16GBK字符集是US7ASCII的超级，所以如果按正常操作，这种转换应该没有问题；但出现问题的本质是我们让本应只存储英文字符的US7ASCII数据库，非常规地存储了中文信息，那么在转化过程中出现错误或麻烦就没什么奇怪的了，不出麻烦倒是有些奇怪了。
所以说要避免这种情况，就是要在建立数据库时选择合适的字符集，不让标签（数据库的字符集设置）与实际（数据库中实际存储的信息）不符的情况发生。

实验结果分析二

quote:
--------------------------------------------------------------------------------
[ 更改客户端字符集为ZHS16GBK
D:/>SET NLS_LANG=AMERICAN_AMERICA.ZHS16GBK

D:/>SQLPLUS "/ AS SYSDBA"

无法正常显示数据

SQL> SELECT * FROM TEST;

R1
--------------------
6+11

疑问1：ZHS16GBK为US7ASCII的超集，为什么在ZHS16GBK环境下无法正常显示

--------------------------------------------------------------------------------

 

这主要是因为Oracle检查发现数据库设置的字符集与客户端配置字符集不同，它将对数据进行字符集的转换。数据库中实际存放的数据为182（10110110）、171（10101011）、177（10110001）、177（10110001），由于数据库字符集设置为US7ASCII，它是一个7bit的字符集，存储在8bit的字节中，则Oracle忽略各字节的最高bit，则182（10110110）就变成了54（0110110），在ZHS16GBK中代表数字符号“6”（当然在其它字符集中也是“6”），同样过程也发生在其它3个字节，这样“东北”就变成了“6+11”。

实验结果分析三

quote:
--------------------------------------------------------------------------------
最初由 tellin 发布
用ZHS16GBK插入数据
SQL> INSERT INTO TEST VALUES('东北');

1 row created.

SQL> SELECT * FROM TEST;

R1
--------------------
6+11
??

SQL> EXIT

--------------------------------------------------------------------------------

当客户端字符集设置为ZHS16GBK后向数据库插入“东北”，Oracle检查发现数据库设置的字符集为US7ASCII与客户端不一致，需要进行转换，但字符集ZHS16GBK中的“东北”两字在US7ASCII中没有对应的字符，所以Oracle用统一的“替换字符”插入数据库，在这里为“？”，编码为63（00111111），这时，输入的信息实际上已经丢失，不管字符集设置如何改变（如下面引用的实验结果），第二行SELECT出来的结果也都是两个“？”号（注意是2个，而不是4个）。

quote:
--------------------------------------------------------------------------------

更改客户端字符集为US7ASCII
D:/>SET NLS_LANG=AMERICAN_AMERICA.US7ASCII

D:/>SQLPLUS "/ AS SYSDBA"

无法显示用ZHS16GBK插入的字符集，但可以显示用US7ASCII插入的字符集
SQL> SELECT * FROM TEST;

R1
----------
东北
??

更改服务器字符集为ZHS16GBK
SQL> update props$ set value$='ZHS16GBK' WHERE NAME='NLS_CHARACTERSET';

1 row updated.

SQL> COMMIT;

更改客户端字符集为ZHS16GBK
D:/>SET NLS_LANG=AMERICAN_AMERICA.ZHS16GBK

D:/>SQLPLUS "/ AS SYSDBA"

可以显示以前US7ASCII的字符集，但无法显示用ZHS16GBK插入的数据，说明用ZHS16GBK插入的数据为乱码。

SQL> SELECT * FROM TEST;

R1
--------------------
东北
??

--------------------------------------------------------------------------------

需要指出的是，通过“update props$ set value$='ZHS16GBK' WHERE NAME='NLS_CHARACTERSET';”来修改数据库字符集是非常规作法，很可能引起问题，在这里只是原文引用网友的实验结果。

实验结果分析四

quote:
--------------------------------------------------------------------------------

SQL> INSERT INTO TEST VALUES('东北');

1 row created.

SQL> SELECT * FROM TEST;

R1
--------------------
东北
??
东北

SQL> EXIT

--------------------------------------------------------------------------------

由于此时数据库与客户端的字符集设置均为ZHS16GBK，所以不会发生字符集的转换，第一行与第三行数据显示正确，而第二行由于存储的数据就是63（00111111），所以显示的是“？”号。

quote:
--------------------------------------------------------------------------------

更改客户端字符集为US7ASCII

D:/>SET NLS_LANG=AMERICAN_AMERICA.US7ASCII

D:/>SQLPLUS "/ AS SYSDBA"

无法显示数据

SQL> SELECT * FROM TEST;

R1
----------
??
??
??

疑问2：第一行数据是用US7ASCII环境插入的，为何无法正常显示？

--------------------------------------------------------------------------------

将客户端字符集设置改为US7ASCII后进行SELECT，Oracle检查发现数据库设置的字符集为ZHS16GBK，数据需要进行字符集转换，而第一行与第三行的汉字“东”与“北”在客户端字符集US7ASCII中没有对应字符，所以转换为“替换字符”（“？”），而第二行数据在数据库中存的本来就是两个“？”号，所以虽然在客户端显示的三行都是两个“？”号，但在数据库中存储的内容却是不同的。

实验结果分析五

quote:
--------------------------------------------------------------------------------

SQL> INSERT INTO TEST VALUES('东北');

1 row created.

SQL> EXIT
更改客户端字符集为ZHS16GBK
D:/>SET NLS_LANG=AMERICAN_AMERICA.ZHS16GBK

D:/>SQLPLUS "/ AS SYSDBA"

无法显示用US7ASCII插入的字符集，但可以显示用ZHS16GBK插入的字符集
SQL> SELECT * FROM TEST;

R1
--------------------
东北
??
东北
6+11

SQL>
疑问3：US7ASCII为ZHS16GBK的子集，为何在US7ASCII环境下插入的数据无法显示？ [/B]
--------------------------------------------------------------------------------

在客户端字符集设置为US7ASCII时，向字符集为ZHS16GBK的数据库中插入“东北”，需要进行字符转换，“东北”的ZHS16GBK编码为182（10110110）、171（10101011）与177（10110001）、177（10110001），由于US7ASCII为7bit编码，Oracle将这两个汉字当作四个字符，并忽略各字节的最高位，从而存入数据库的编码就变成了54（00110110）、43（00101011）与49（00110001）、49（00110001），也就是“6+11”，原始信息被改变了。这时，将客户端字符集设置为ZHS16GBK再进行SELECT，数据库中的信息不需要改变传到客户端，第一、三行由于存入的信息没有改变能显示“东北”，而第二、四行由于插入数据时信息改变，所以不能显示原有信息了。

 

分析了这么多的内容，但实际上总结起来也很简单
分析了这么多的内容，但实际上总结起来也很简单，要想在字符集方面少些错误与麻烦，需要坚持两条基本原则：
在数据库端：选择需要的字符集（通过create database中的CHARACTER SET与NATIONAL CHARACTER SET子句指定）；
在客户端：设置操作系统实际使用的字符集（通过环境变量NLS_LANG设置）。

Oracle字符集子集与超级的对应关系

很多朋友经常问起Oracle字符集子集与超级的对应关系，我将从Oracle8.1.6到9.2.0的对应关系列举在这里供大家参考.参考文档Metalink Doc: 119164.1
尤其是在更改字符集时，大家应该参考此对应关系:
8.1.6 Subset/Superset Pairs
===========================

A. Current Char set             B. New Char set (Superset of A.)

-------------------             --------------------------------

US7ASCII                        WE8DEC

US7ASCII                        US8PC437

US7ASCII                        WE8PC850

US7ASCII                        IN8ISCII

US7ASCII                        WE8PC858

US7ASCII                        WE8ISO8859P1

US7ASCII                        EE8ISO8859P2

US7ASCII                        SE8ISO8859P3

US7ASCII                        NEE8ISO8859P4

US7ASCII                        CL8ISO8859P5

US7ASCII                        AR8ISO8859P6

US7ASCII                        EL8ISO8859P7

US7ASCII                        IW8ISO8859P8

US7ASCII                        WE8ISO8859P9

US7ASCII                        NE8ISO8859P10

US7ASCII                        TH8TISASCII

US7ASCII                        BN8BSCII

US7ASCII                        VN8VN3

US7ASCII                        VN8MSWIN1258

US7ASCII                        WE8ISO8859P15

US7ASCII                        WE8NEXTSTEP

US7ASCII                        AR8ASMO708PLUS

US7ASCII                        EL8DEC

US7ASCII                        TR8DEC

US7ASCII                        LA8PASSPORT

US7ASCII                        BG8PC437S

US7ASCII                        EE8PC852

US7ASCII                        RU8PC866

US7ASCII                        RU8BESTA

US7ASCII                        IW8PC1507

US7ASCII                        RU8PC855

US7ASCII                        TR8PC857

US7ASCII                        CL8MACCYRILLICS

US7ASCII                        WE8PC860

US7ASCII                        IS8PC861

US7ASCII                        EE8MACCES

US7ASCII                        EE8MACCROATIANS

US7ASCII                        TR8MACTURKISHS

US7ASCII                        EL8MACGREEKS

US7ASCII                        IW8MACHEBREWS

US7ASCII                        EE8MSWIN1250

US7ASCII                        CL8MSWIN1251

US7ASCII                        ET8MSWIN923

US7ASCII                        BG8MSWIN

US7ASCII                        EL8MSWIN1253

US7ASCII                        IW8MSWIN1255

US7ASCII                        LT8MSWIN921

US7ASCII                        TR8MSWIN1254

US7ASCII                        WE8MSWIN1252

US7ASCII                        BLT8MSWIN1257

US7ASCII                        N8PC865

US7ASCII                        BLT8CP921

US7ASCII                        LV8PC1117

US7ASCII                        LV8PC8LR

US7ASCII                        LV8RST104090

US7ASCII                        CL8KOI8R

US7ASCII                        BLT8PC775

US7ASCII                        WE8DG

US7ASCII                        WE8NCR4970

US7ASCII                        WE8ROMAN8

US7ASCII                        WE8MACROMAN8S

US7ASCII                        TH8MACTHAIS

US7ASCII                        HU8CWI2

US7ASCII                        EL8PC437S

US7ASCII                        LT8PC772

US7ASCII                        LT8PC774

US7ASCII                        EL8PC869

US7ASCII                        EL8PC851

US7ASCII                        CDN8PC863

US7ASCII                        HU8ABMOD

US7ASCII                        AR8ASMO8X

US7ASCII                        AR8NAFITHA711T

US7ASCII                        AR8SAKHR707T

US7ASCII                        AR8MUSSAD768T

US7ASCII                        AR8ADOS710T

US7ASCII                        AR8ADOS720T

US7ASCII                        AR8APTEC715T

US7ASCII                        AR8NAFITHA721T

US7ASCII                        AR8HPARABIC8T

US7ASCII                        AR8NAFITHA711

US7ASCII                        AR8SAKHR707

US7ASCII                        AR8MUSSAD768

US7ASCII                        AR8ADOS710

US7ASCII                        AR8ADOS720

US7ASCII                        AR8APTEC715

US7ASCII                        AR8MSAWIN

US7ASCII                        AR8NAFITHA721

US7ASCII                        AR8SAKHR706

US7ASCII                        AR8ARABICMACS

US7ASCII                        LA8ISO6937

US7ASCII                        JA16VMS

US7ASCII                        JA16EUC

US7ASCII                        JA16SJIS

US7ASCII                        KO16KSC5601

US7ASCII                        KO16KSCCS

US7ASCII                        KO16MSWIN949

US7ASCII                        ZHS16CGB231280

US7ASCII                        ZHS16GBK

US7ASCII                        ZHT32EUC

US7ASCII                        ZHT32SOPS

US7ASCII                        ZHT16DBT

US7ASCII                        ZHT32TRIS

US7ASCII                        ZHT16BIG5

US7ASCII                        ZHT16CCDC

US7ASCII                        ZHT16MSWIN950

US7ASCII                        AL24UTFFSS

US7ASCII                        UTF8

US7ASCII                        JA16TSTSET2

US7ASCII                        JA16TSTSET

 

8.1.7 Additions

===============

US7ASCII                        ZHT16HKSCS 

US7ASCII                        KO16TSTSET 

WE8DEC                          TR8DEC 

WE8DEC                          WE8NCR4970 

WE8PC850                        WE8PC858 

D7DEC                           D7SIEMENS9780X 

I7DEC                           I7SIEMENS9780X 

WE8ISO8859P1                    WE8MSWIN1252 

AR8ISO8859P6                    AR8ASMO708PLUS 

AR8ISO8859P6                    AR8ASMO8X 

IW8EBCDIC424                    IW8EBCDIC1086 

IW8EBCDIC1086                   IW8EBCDIC424 

LV8PC8LR                        LV8RST104090 

DK7SIEMENS9780X                 N7SIEMENS9780X 

N7SIEMENS9780X                  DK7SIEMENS9780X 

I7SIEMENS9780X                  I7DEC 

D7SIEMENS9780X                  D7DEC 

WE8NCR4970                      WE8DEC 

WE8NCR4970                      TR8DEC 

AR8SAKHR707T                    AR8SAKHR707 

AR8MUSSAD768T                   AR8MUSSAD768 

AR8ADOS720T                     AR8ADOS720 

AR8NAFITHA711                   AR8NAFITHA711T 

AR8SAKHR707                     AR8SAKHR707T 

AR8MUSSAD768                    AR8MUSSAD768T 

AR8ADOS710                      AR8ADOS710T 

AR8ADOS720                      AR8ADOS720T 

AR8APTEC715                     AR8APTEC715T 

AR8NAFITHA721                   AR8NAFITHA721T 

AR8ARABICMAC                    AR8ARABICMACT 

AR8ARABICMACT                   AR8ARABICMAC 

KO16KSC5601                     KO16MSWIN949 

WE16DECTST2                     WE16DECTST 

WE16DECTST                      WE16DECTST2 

  

9.0.1 Additions

===============

US7ASCII                        BLT8ISO8859P13 

US7ASCII                        CEL8ISO8859P14 

US7ASCII                        CL8ISOIR111 

US7ASCII                        CL8KOI8U 

US7ASCII                        AL32UTF8 

BLT8CP921                       BLT8ISO8859P13 

US7ASCII                        AR8MSWIN1256 

UTF8                            AL32UTF8 (added in patchset 9.0.1.2)

 

Character Set Subset/Superset Pairs Obsolete from 9.0.1

=======================================================

US7ASCII                        AR8MSAWIN

AR8ARABICMAC                    AR8ARABICMACT

 

9.2.0 Additions

===============

US7ASCII                        JA16EUCTILDE

US7ASCII                        JA16SJISTILDE

US7ASCII                        ZHS32GB18030

US7ASCII                        ZHT32EUCTST

WE8ISO8859P9                    TR8MSWIN1254

LT8MSWIN921                     BLT8ISO8859P13

LT8MSWIN921                     BLT8CP921

BLT8CP921                       LT8MSWIN921

AR8ARABICMAC                    AR8ARABICMACT

ZHT32EUC                        ZHT32EUCTST

UTF8                            AL32UTF8

 

Character Set Subset/Superset Pairs Obsolete from 9.2.0

=======================================================

LV8PC8LR                        LV8RST104090

 理解ORACLE数据库字符集
http://wqkiller.blog.163.com/blog/static/241660652007220102813949/

一．引言

    ORACLE数据库字符集，即Oracle全球化支持(Globalization Support)，或即国家语言支持（NLS）其作用是用本国语言和格式来存储、处理和检索数据。利用全球化支持，ORACLE为用户提供自己熟悉的数据库母语环境，诸如日期格式、数字格式和存储序列等。Oracle可以支持多种语言及字符集，其中oracle8i支持48种语言、76个国家地域、229种字符集，而oracle9i则支持57种语言、88个国家地域、235种字符集。由于oracle字符集种类多，且在存储、检索、迁移oracle数据时多个环节与字符集的设置密切相关，因此在实际的应用中，数据库开发和管理人员经常会遇到有关oracle字符集方面的问题。本文通过以下几个方面阐述，对oracle字符集做简要分析

二．字符集基本知识

2.1字符集
    实质就是按照一定的字符编码方案，对一组特定的符号，分别赋予不同数值编码的集合。Oracle数据库最早支持的编码方案是US7ASCII。
    Oracle 的字符集命名遵循以下命名规则 :
   
    <语言><比特位数><编码 >
    比如: ZHS16GBK表示采用GBK编码格式、16位（两个字节）简体中文字符集

2.2字符编码方案
2.2.1 单字节编码
    （1）单字节7位字符集，可以定义128个字符，最常用的字符集为 US7ASCII
    （2）单字节8位字符集，可以定义256个字符，适合于欧洲大部分国家
    例如：WE8ISO8859P1(西欧、8位、ISO标准8859P1编码 )
2.2.2 多字节编码
    （1）变长多字节编码
     某些字符用一个字节表示，其它字符用两个或多个字符表示，变长多字节编码常用于对亚洲语言的支持，   例如日语、汉语、印地语等
    例如：AL32UTF8（其中AL代表ALL,指适用于所有语言）、 zhs16cgb231280
    （2）定长多字节编码
    每一个字符都使用固定长度字节的编码方案，目前oracle唯一支持的定长多字节编码是AF16UTF16，也是仅用于国家字符集
2.2.3 unicode 编码
    Unicode 是一个涵盖了目前全世界使用的所有已知字符的单一编码方案，也就是说Unicode为每一个字符提供唯一的编码。UTF-16是unicode的16位编码方式，是一种定长多字节编码，用2个字节表示一个unicode字符，AF16UTF16是UTF-16编码字符集。
    UTF-8 是unicode的8位编码方式，是一种变长多字节编码，这种编码可以用1、2、3个字节表示一个unicode字符，AL32UTF8，UTF8、UTFE是UTF-8编码字符集

2.3 字符集超级
    当一种字符集（字符集A）的编码数值包含所有另一种字符集（字符集B）的编码数值，并且两种字符集相同编码数值代表相同的字符时，则字符集A是字符集B的超级，或称字符集B是字符集A的子集。
    Oracle8i 和oracle9i官方文档资料中备有子集-超级对照表（subset-superset pairs），例如：WE8ISO8859P1是WE8MSWIN1252的子集。由于US7ASCII是最早的Oracle数据库编码格式，因此有许多字符集是US7ASCII的超集，例如WE8ISO8859P1、ZHS16CGB231280、ZHS16GBK都是US7ASCII的超集。

2.4 数据库字符集（oracle服务器端字符集）
    数据库字符集在创建数据库时指定，在创建后通常不能更改。在创建数据库时，可以指定字符集(CHARACTER SET)和国家字符集(NATIONAL CHARACTER SET)。
2.4.1 字符集
    (1) 用来存储CHAR, VARCHAR2, CLOB, LONG等类型数据
    (2) 用来标示诸如表名、列名以及PL/SQL变量等
    (3) 用来存储SQL和PL/SQL程序单元等
2.4.2 国家字符集：
    (1) 用以存储NCHAR, NVARCHAR2, NCLOB等类型数据
    (2) 国家字符集实质上是为oracle选择的附加字符集，主要作用是为了增强oracle的字符处理能力，因为NCHAR数据类型可以提供对亚洲使用定长多字节编码的支持，而数据库字符集则不能。国家字符集在oracle9i中进行了重新定义，只能在unicode编码中的AF16UTF16和UTF8中选择，默认值是 AF16UTF16
2.4.3查询字符集参数
    可以查询以下数据字典或视图查看字符集设置情况
    nls_database_parameters 、props$、 v$nls_parameters
    查询结果中NLS_CHARACTERSET表示字符集，NLS_NCHAR_CHARACTERSET表示国家字符集
2.4.4 修改数据库字符集
    按照上文所说，数据库字符集在创建后原则上不能更改。如果需要修改字符集，通常需要导出数据库数据，重建数据库，再导入数据库数据的方式来转换，或通过ALTER DATABASE CHARACTER SET语句修改字符集，但创建数据库后修改字符集是有限制的，只有新的字符集是当前字符集的超集时才能修改数据库字符集，例如UTF8是US7ASCII的超集，修改数据库字符集可使用ALTER DATABASE CHARACTER SET UTF8。

2.5 客户端字符集（NLS_LANG参数）
2.5.1 客户端字符集含义
    客户端字符集定义了客户端字符数据的编码方式，任何发自或发往客户端的字符数据均使用客户端定义的字符集编码,客户端可以看作是能与数据库直接连接的各种应用，例如sqlplus,exp/imp等。客户端字符集是通过设置NLS_LANG参数来设定的。
2.5.2 NLS_LANG 参数格式
    NLS_LANG=_.
    Language: 显示oracle消息,校验，日期命名
    Territory ：指定默认日期、数字、货币等格式
    Client character set ：指定客户端将使用的字符集
    例如： NLS_LANG=AMERICAN_AMERICA.US7ASCII 
    AMERICAN是语言，AMERICA是地区，US7ASCII是客户端字符集
2.5.3 客户端字符集设置方法
     1)UNIX 环境
         $NLS_LANG=“simplified chinese”_china.zhs16gbk
         $export NLS_LANG
         编辑oracle用户的profile文件
    2)Windows 环境
         编辑注册表
         Regedit.exe---HKEY_LOCAL_MACHINE---SOFTWARE---ORACLE—HOME0
2.5.4 NLS 参数查询
    Oracle 提供若干NLS参数定制数据库和用户机以适应本地格式，例如有NLS_LANGUAGE,NLS_DATE_FORMAT,NLS_CALENDER等，可以通过查询以下数据字典或v$视图查看。
    NLS_DATABASE_PARAMETERS-- 显示数据库当前NLS参数取值，包括数据库字符集取值
    NLS_SESSION_PARAMETERS-- 显示由NLS_LANG 设置的参数，或经过alter session 改变后的参数值（不包括由NLS_LANG 设置的客户端字符集）
    NLS_INSTANCE_PARAMETE-- 显示由参数文件init.ora 定义的参数V$NLS_PARAMETERS--显示数据库当前NLS参数取值
2.5.5 修改NLS参数
    使用下列方法可以修改NLS参数
    （1）修改实例启动时使用的初始化参数文件
    （2）修改环境变量 NLS_LANG
    （3）使用ALTER SESSION语句，在oracle会话中修改
    （4）使用某些SQL函数
    NLS 作用优先级别：Sql function>alter session>环境变量或注册表>参数文件>数据库默认参数

三．导入/导出与字符集转换

3.1 EXP/IMP
    Export 和 Import 是一对读写Oracle数据的工具。Export 将 Oracle 数据库中的数据输出到操作系统文件中, Import 把这些文件中的数据读到Oracle 数据库中，由于使用exp/imp进行数据迁移时，数据从源数据库到目标数据库的过程中有四个环节涉及到字符集，如果这四个环节的字符集不一致，将会发生字符集转换。

EXP
     ____________   _________________  _____________
     |imp导入文件|<-><->
     ------------   -----------------  -------------

IMP
     ____________   _________________  _____________
     |imp导入文件|->|环境变量NLS_LANG|->|数据库字符集|
     ------------   -----------------  -------------

    四个字符集是
   （1）源数据库字符集
   （2）Export过程中用户会话字符集（通过NLS_LANG设定）
   （3）Import过程中用户会话字符集（通过NLS_LANG设定）
   （4）目标数据库字符集

3.2导出的转换过程
    在Export过程中，如果源数据库字符集与Export用户会话字符集不一致，会发生字符集转换，并在导出文件的头部几个字节中存储Export用户会话字符集的ID号。在这个转换过程中可能发生数据的丢失。
例:如果源数据库使用ZHS16GBK，而Export用户会话字符集使用US7ASCII，由于ZHS16GBK是16位字符集,而US7ASCII是7位字符集，这个转换过程中，中文字符在US7ASCII中不能够找到对等的字符，所以所有中文字符都会丢失而变成“?? ”形式，这样转换后生成的Dmp文件已经发生了数据丢失。
因此如果想正确导出源数据库数据，则Export过程中用户会话字符集应等于源数据库字符集或是源数据库字符集的超集

3.3导入的转换过程
    （1）确定导出数据库字符集环境
    通过读取导出文件头，可以获得导出文件的字符集设置
    （2）确定导入session的字符集，即导入Session使用的NLS_LANG环境变量
    （3）IMP读取导出文件
    读取导出文件字符集ID，和导入进程的NLS_LANG进行比较
    （4）如果导出文件字符集和导入Session字符集相同，那么在这一步骤内就不需要转换，如果不同，就需要把数据转换为导入Session使用的字符集。可以看出，导入数据到数据库过程中发生两次字符集转换
    第一次:导入文件字符集与导入Session使用的字符集之间的转换，如果这个转换过程不能正确完成，Import向目标数据库的导入过程也就不能完成。
    第二次:导入Session字符集与数据库字符集之间的转换。
    然而,oracle8i的这种转换只能在单字节字符集之间进行,oracle8i导入Session不支持多字节字符集之间的转换，因此为了避免第一次转换，导入Session使用的NLS_LANG与导出文件字符集相同，第二次转换（通过SQL*Net）支持任何两种字符集。以上情况在Oracle9i中略有不同

四．乱码问题

    oracle在数据存储、迁移过程中经常发生字符乱码问题，归根到底是由于字符集使用不当引起。下面以使用客户端sqlplus向数据库插入数据和导入/导出（EXP/IMP）过程为例，说明乱码产生的原因。

4.1使用客户端sqlplus向数据库存储数据
    这个过程存在3个字符集设置
    （1）客户端应用字符集
    （2）客户端NLS_LANG参数设置
    （3）服务器端数据库字符集(Character Set)设置
    客户端应用sqlplus中能够显示什么样的字符取决于客户端操作系统语言环境(客户端应用字符集)，但在应用中录入这些字符后，这些字符能否在数据库中正常存储，还与另外两个字符集设置紧密相关，其中客户端NLS_LANG参数主要用于字符数据传输过程中的转换判断。常见的乱码大致有两种情形：
    （1）汉字变成问号“？”；
当从字符集A 转换成字符集B时，如果转换字符之间不存在对应关系，NLS_LANG使用替代字符“？”替代无法映射的字符
    （2）汉字变成未知字符（虽然有些是汉字，但与原字符含义不同）
转换存在对应关系，但字符集A 中的字符编码与字符集B 中的字符编码代表不同含义

4.2发生乱码原因 
    乱码产生是由于几个字符集之间转换不匹配造成，分以下几种情况：
    （注：字符集之间如果不存在子集、超集对应关系时的情况不予考虑，因为这种情况下字符集之间转换必产生乱码）   
    1）服务器端数据库字符集与客户端应用字符集相同，与客户端NLS_LANG参数设置不同
    如果客户端NLS_LANG字符集是其它两种字符集的子集，转换过程将出现乱码。
    解决方法：将三种字符集设置成同一字符集，或NLS_LANG字符集是其它两种字符集的超集
    2 ）服务器端数据库字符集与客户端NLS_LANG参数设置相同，与客户端应用字符集不同
    如果客户端应用字符集是其它两种字符集的超集时，转换过程将出现乱码，但对于单字节编码存储中文问题，可参看本文第5章节的分析
    3 ）客户端应用字符集、客户端NLS_LANG参数设置、服务器端数据库字符集互不相同
     此种情况较为复杂，但三种字符集之间只要有不能转换的字符，则必产生乱码

4.3导入/导出过程出现乱码原因
    这个过程存在4个字符集设置，在3.1章节中已分析
   （1）源数据库字符集
   （2）EXP过程中NLS_LANG参数
   （3）IMP过程中NLS_LANG参数
   （4）目标数据库字符集
    出现乱码原因
    1 ）当源数据库字符集不等于EXP过程中NLS_LANG参数，且源数据库字符集是EXP过程中NLS_LANG的子集，才能保证导出文件正确，其他情况则导出文件字符乱码
    2 ）EXP过程中NLS_LANG字符集不等于IMP过程中NLS_LANG字符集，且EXP过程中NLS_LANG字符集是IMP过程中NLS_LANG字符集的子级, 才能保证第一次转换正常，否则第一次转换中出现乱码。
    3 ）如果第一次转换正常，IMP过程中NLS_LANG字符集是目标数据库字符集的子集或相同，才能保证第二次转换正常，否则则第二次转换中出现乱码

五．单字节编码存储中文问题

    由于历史的原因，早期的oracle没有中文字符集（如oracle6、oracle7、oracle7.1）,但有的用户从那时起就使用数据库了，并用US7ASCII字符集存储了中文，或是有的用户在创建数据库时，不考虑清楚，随意选择一个默认的字符集，如WE8ISO8859P1或US7ASCII，而这两个字符集都没有汉字编码，虽然有些时候选用这种字符集好象也能正常使用，但用这种字符集存储汉字信息从原则上说就是错误的，它会给数据库的使用与维护带来一系列的麻烦。
    正常情况下，要将汉字存入数据库，数据库字符集必须支持中文，而将数据库字符集设置为US7ASCII等单字节字符集是不合适的。US7ASCII字符集只定义了128个符号，并不支持汉字。另外，如果在SQL*PLUS中能够输入中文，操作系统缺省应该是支持中文的，但如果在NLS_LANG中的字符集设置为US7ASCII，显然也是不正确的，它没有反映客户端的实际情况。但在实际应用中汉字显示却是正确的，这主要是因为Oracle检查数据库与客户端的字符集设置是同样的，那么数据在客户与数据库之间的存取过程中将不发生任何转换，但是这实际上导致了数据库标识的字符集与实际存入的内容是不相符的。而在SELECT的过程中，Oracle同样检查发现数据库与客户端的字符集设置是相同的，所以它也将存入的内容原封不动地传送到客户端，而客户端操作系统识别出这是汉字编码所以能够正确显示。
    在这个例子中，数据库与客户端都没有设置成中文字符集，但却能正常显示中文，从应用的角度看好象没问题。然而这里面却存在着极大的隐患，比如在应用length或substr等字符串函数时，就可能得到意外的结果。
    对于早期使用US7ASCII字符集数据库的数据迁移到oracle8i/9i中（使用zhs16gbk），由于原始数据已经按照US7ASCII格式存储，对于这种情况，可以通过使用Oracle8i的导出工具，设置导出字符集为US7ASCII，导出后使用UltraEdit等工具打开dmp文件，修改第二、三字符，修改 0001 为0354,这样就可以将US7ASCII字符集的数据正确导入到ZHS16GBK的数据库中。

六．结束语

    为了避免在数据库迁移过程中由于字符集不同导致的数据损失，oracle提供了字符集扫描工具（character set scanner），通过这个工具我们可以测试在数据迁移过程中由于字符集转换可能带来的问题，然后根据测试结果，确定数据迁移过程中最佳字符集解决方案。