如题，除了SCII编码，还有 ＵＴＦ－８编码、ＧＢＫ编码 、ISO８８５９编码。
晚上学习oracle，接触到一个语句：select ename,sal from emp where ename > 'CBA';
运行到这里我那个郁闷啊，我什么都不懂。问人家的时候，说让百度查。查百度到时候因为文章太专业，根本都看不懂，
想请教人家，想起上次被人家说是花瓶，哎。决心扫盲。
晚上学习oracle，接触到一个语句：select ename,sal from emp where ename > 'CBA';
运行到这里我那个郁闷啊，我什么都不懂。问人家的时候，说让百度查。查百度到时候因为文章太专业，根本都看不懂，
想请教人家，想起上次被人家说是花瓶，哎。决心扫盲。
select ename,sal from emp where ename > 'CBA'这条语句这样解释查找出emp表中满足ename字段 > 'CBA' 这个条件的ename字段和sal字段的值这里的CBA不是什么编码的
只是一个字符串,你可以把这里的 > 'CBA' 理解为 > 1
这个是一个道理的
如:ABA , BBA 等比 CBA小
DBA , EBA 等比CBA大
有些朋友可能会认为这是多此一举，但实际上正是由于对相关基本概念把握不清，才导致了诸多问题和疑问。
首先是字符集的概念。
我们知道，电子计算机最初是用来进行科学计算的（所以叫做“计算机”），但随着技术的发展，还需要计算机进行其它方面的应用处理。这就要求计算机不仅能处理数值，还能处理诸如文字、特殊符号等其它信息，而计算机本身能直接处理的只有数值信息，所以就要求对这些文字、符号信息进行数值编码，最初的字符集是我们都非常熟悉的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.ZHS16GBKD:\>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.US7ASCIID:\>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.ZHS16GBKD:\>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:
--------------------------------------------------------------------------------更改客户端字符集为US7ASCIID:\>SET NLS_LANG=AMERICAN_AMERICA.US7ASCIID:\>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.ZHS16GBKD:\>SQLPLUS "/ AS SYSDBA"无法显示用US7ASCII插入的字符集，但可以显示用ZHS16GBK插入的字符集
SQL> SELECT * FROM TEST;R1
--------------------
东北
??
东北
6+11SQL>
疑问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设置）。
2009-12-10 14:44一、什么是oracle字符集 Oracle字符集是一个字节数据的解释的符号集合,有大小之分,有相互的包容关系。ORACLE 支持国家语言的体系结构允许你使用本地化语言来存储，处理，检索数据。它使数据库工具，错误消息，排序次序，日期，时间，货币，数字，和日历自动适应本地化语言和平台。 影响oracle数据库字符集最重要的参数是NLS_LANG参数。它的格式如下: NLS_LANG = language_territory.charset 它有三个组成部分(语言、地域和字符集)，每个成分控制了NLS子集的特性。其中: Language 指定服务器消息的语言，territory 指定服务器的日期和数字格式，charset 指定字符集。如:AMERICAN _ AMERICA. ZHS16GBK 从NLS_LANG的组成我们可以看出，真正影响数据库字符集的其实是第三部分。所以两个数据库之间的字符集只要第三部分一样就可以相互导入导出数据，前面影响的只是提示信息是中文还是英文。二.查看数据库字符集这涉及三方面的字符集，一是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端相同的字符集。补充：(1).数据库服务器字符集select * from nls_database_parameters来源于props$，是表示数据库的字符集。(2).客户端字符集环境select * from nls_instance_parameters其来源于v$parameter，表示客户端的字符集的设置，可能是参数文件，环境变量或者是注册表(3).会话字符集环境select * from nls_session_parameters来源于v$nls_parameters，表示会话自己的设置，可能是会话的环境变量或者是alter session完成，如果会话没有特殊的设置，将与nls_instance_parameters一致。(4).客户端的字符集要求与服务器一致，才能正确显示数据库的非Ascii字符。如果多个设置存在的时候，alter session>环境变量>注册表>参数文件字符集要求一致，但是语言设置却可以不同，语言设置建议用英文。如字符集是zhs16gbk，则nls_lang可以是American_America.zhs16gbk。三、修改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注意：如果没有大对象，在使用过程中进行语言转换没有什么影响，（切记设定的字符集必须是ORACLE支持，不然不能start）按上面的做法就可以,但是可能会出现‘ORA-12717: Cannot ALTER DATABASE NATIONAL CHARACTER SET when NCLOB data exists’ 这样的提示信息要解决这个问题有两种方法一个是,利用INTERNAL_USE 关键字修改区域设置,还有一个是利用re-create,但是re-create有点复杂,所以请用internal_use,SQL>SHUTDOWN IMMEDIATE;SQL>STARTUP MOUNT EXCLUSIVE;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 NATIONAL CHARACTER SET INTERNAL_USE UTF8;SQL>SHUTDOWN immediate;SQL>startup;如果按上面的做法做,National charset的区域设置就没有问题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无法打开，就需要用程序的方法了。-----------------------------------------------------------------------------------------------------------------------------------数据库服务器字符集更改步骤 问题描述： 在客户端插入字符“咪咪”，从数据库中查询显示时出现乱码 处理步骤： 10.1 对数据库做全库导出，备份全库数据，以防故障发生 首先设定客户端的字符集，必须以ZHS16GBK的字符集导出，然后才能在更改失败后顺利倒入新建的库。 #setenv NLS_LANG "SIMPLIFIED CHINESE_CHINA.ZHS16GBK"; #stty -istrip -parity cs8; #setenv LANG zh 拟在/sybdata(磁盘阵列)下建立一个目录orabak,用于存放dmp文件。 #mkdir /sybdata/orabak #chown oracle:oinstall /sybdata/orabak #su – oracle #cd /sybdata/orabak %exp system/manager@hnsdh file=hnsdh_2005-8-17 log=hnsdh_exp_2005-8-17 full=y (此处命名为示例，以实施当日日期为准) 察看日志结尾，以判定导出是否成功。 #cat hnsdh_2005-8-17.dmp | od -x | head 看第二和第三个字节组成的十六进制数是多少可判断导出文件的字符集。 示例如下
#cat example.dmp | od -x | head
0000000 0303 5445 5850 4f52 543a 5630 392e 3032
0000220 646d 7000 0000 0000 0000 0000 0000 0000
十六进制的0354化为十进制为852，参造下表
NLS_CHARSET_ID NLS_CHARSET_NAME HEX_ID
-------------- ------------------------------ -------------
1 US7ASCII 1
2 WE8DEC 2
3 WE8HP 3
4 US8PC437 4
5 WE8EBCDIC37 5
6 WE8EBCDIC500 6
7 WE8EBCDIC1140 7
8 WE8EBCDIC285 8
...................
850 ZHS16CGB231280 352
851 ZHS16MACCGB231280 353
852 ZHS16GBK 354
853 ZHS16DBCS 355
860 ZHT32EUC 35c
861 ZHT32SOPS 35d
862 ZHT16DBT 35e
863 ZHT32TRIS 35f
864 ZHT16DBCS 360
865 ZHT16BIG5 361
866 ZHT16CCDC 362
867 ZHT16MSWIN950 363
868 ZHT16HKSCS 364
870 AL24UTFFSS 366
871 UTF8 367
872 UTFE 368
即可得出这个dmp文件的字符集为ZHS16GBK。 10.2 在数据库中直接更改字符集参数 操作步骤如下：
SQL> 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 session set events '10046 trace name context forever,level 12';
SQL> alter database character set INTERNAL_USE ZHS16GBK;
SQL> shutdown immediate
SQL> startup
察看系统字符集 SQL> SELECT * FROM NLS_DATABASE_PARAMETERS; 看NLS_CHARACTERSET的值为多少，如果为ZHS16GBK则说明改动成功。 如果执行正常，则按照下一节进行测试操作。 10.3 更改成功后的测试 测试1，在数据库服务器端下测试 %setenv NLS_LANG "SIMPLIFIED CHINESE_CHINA.ZHS16GBK";
%stty -istrip -parity cs8;
%setenv LANG zh
%sqlplus /nolog
SQL〉conn / as sysdba
SQL〉create table test_tq (a char(20));
SQL〉insert into test_tq
1>(a)
2>values ('洣洣');
SQL〉select * from test_tq;
如显示为 A -------------------- 洣洣 则成功。 测试2，Windows客户端环境下测试
运 行REGEDIT,第一步选HKEY_LOCAL_MACHINE,第二步选择SOFTWARE， 第三步选择 ORACLE， 第四步选择 NLS_LANG， 键 入 与服 务 器 端 相 同 的 字 符 集(本例为：AMERICAN_AMERICAN.US7ASCII)。 右击我的电脑，然后点击属性，“高级”页面下，点击“环境变量”，在系统变量中添加： 变量名：NLS_LANG 变量值:SIMPLIFIED CHINESE_CHINA.ZHS16GBK 运行cmd，输入echo %NLS_LANG%，查看系统变量设置时否成功 然后运行：
$sqlplus system/manager@hnsdh
SQL〉conn / as sysdba
SQL〉create table test_tq (a char(20));
SQL〉insert into test_tq
1>(a)
2>values ('洣洣');
SQL〉select * from test_tq;
如显示为 A -------------------- 洣洣 则成功。 10.4 更改不成功时的措施 新建数据库，设定字符集为ZHS16GBK,其他参数先照搬原来的，并倒入数据。建库时所需的具体参数在重建之前要搜集。注意在配置控制文件时设定最大数据文件数。 建好数据库以后，执行以下命令即可恢复数据库 %cd /sybdata/orabak %imp system/manager@hnsdh full=y ignore=y file=hnsdh_2005-8-17 log=hnsdh_imp_2005 -8-17