linux enterprise5 & oracle10g中如何修改oracle的字符集(测试与整理)

 

 在安装Oracle10g的时候在指定数据库字符集的时候我选择了默认的WE8ISO8859P1，但在存储中文字符的时候就会出现问题。现在想把数据库字符集改成ZHS16GBK，请问我改怎么做？
 经常看到一些朋友问ORACLE字符集方面的问题，我想以迭代的方式来介绍一下。

基础知识：掌握字符集方面的基本概念。
 
首先是字符集的概念。
我们知道，电子计算机最初是用来进行科学计算的（所以叫做“计算机”），但随着技术的发展，还需要计算机进行其它方面的应用处理。这就要求计算机不仅能处理数值，还能处理诸如文字、特殊符号等其它信息，而计算机本身能直接处理的只有数值信息，所以就要求对这些文字、符号信息进行数值编码，最初的字符集是我们都非常熟悉的ASCII，它是用7个二进制位来表示128个字符，而后来随着不同国家、组织的需要，出现了许许多多的字符集，如表示西欧字符的ISO8859系列的字符集，表示汉字的GB2312-80、GBK等字符集。
字符集的实质就是对一组特定的符号，分别赋予不同的数值编码，以便于计算机的处理。
为了大家更容易理解,请将"字符集"理解为字符的集合吧!! (数学中集合的概念大家都知道哦! 这里用到的是不相交的集合及子集的概念)
===========先说不相交的集合情况:
第1种:如果一个集合内charsetA的字符A --编码001在另一个字符集charsetB内有对应的字符A--编码101,那么将会做 001  >>> 101的转换
即在另一字符集中charsetB中字符A的仍然为A,但编码为101)
第2种:如果一个集合内charsetA的字符A --编码001 ,在另一个字符集charsetB内有对应的无对应字符,那么将会做 001  >>> 0000的转换
即在另一字符集中charsetB中字符A的未有表示,也可能表现为一个？号,出现信息丢失。

==========再说一个集合是另一个集合的子集的情况:
第3种:如果一个集合内charsetA是另一个字符集charsetB子集,那么charsetA中所有字符A都会在charsetB中有对应字符,但编码不一定相同,
如charsetA的字符A --编码001在另一个字符集charsetB内有对应的字符A--编码101,那么将会做 001  >>> 101的转换,并且一定不会出现未知字符?号,即不会出现信息丢失。
所以说，在字符集转换过程中，如果源字符集中的某个字符在目标字符集中没有定义，将会出现信息丢失。
大家知道西文字符集 WE8ISO8859P1或US7ASCII是不能表示汉字的,所以如果向数据表中写入一个汉字时,将会出现?号的现象,这就是信息丢失。
如果要存储中文，那么我们就需要选择能够支持中文的字符集（如ZHS16GBK）；如果需要存储多国语言文字，那就要选择UTF8了。
UTF-8是一种国际通用编码方式(是所有charset的父集,所以按原更来说,如果数据库的字符选定的是UTF-8,对于任何字符都不会现信息丢失。
特别说明，我们最常用的两种字符集ZHS16GBK和ZHS16CGB231280之间不存在子集和超集关系，因此理论上讲这两种字符集之间的相互转换不受支持。

实验与分析--通过实例加深对基本概念的理解(此部分内容网上摘录)
 
下面我将引用网友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';”来修改数据库字符集是非常规作法，很可能引起问题，在这里只是原文引用网友的实验结果。

分析了这么多的内容，但实际上总结起来也很简单

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

///实用技术:如何更改数据库的字符集  (这里只对新创建的数据库生效,旧的数据库中记录的编码转换,请参考其它的文档)

Oracle字符集是一个字节数据的解释的符号集合,有大小之分,有相互的包容关系。ORACLE 支持国家语言的体系结构允许你使用本地化语言来存储，处理，检索数据。它使数据库工具，错误消息，排序次序，日期，时间，货币，数字，和日历自动适应本地化语言和平台。
影响oracle数据库字符集最重要的参数是NLS_LANG参数。
它的格式如下:NLS_LANG = language_territory.charset它有三个组成部分(语言、地域和字符集)，每个成分控制了NLS子集的特性。其中:
Language 指定服务器消息的语言，territory 指定服务器的日期和数字格式，charset 指定字符集。如:AMERICAN _ AMERICA. ZHS16GBK
从NLS_LANG的组成我们可以看出，真正影响数据库字符集的其实是第三部分。所以两个数据库之间的字符集只要第三部分一样就可以相互导入导出数据，前面影响的只是提示信息是中文还是英文。

SQL> set linesize 200
SQL>    SELECT * FROM NLS_DATABASE_PARAMETERS;

-----------
NLS_LANGUAGE                                                 AMERICAN
NLS_TERRITORY                                                AMERICA
NLS_CURRENCY                                                 $
NLS_ISO_CURRENCY                                             AMERICA
NLS_NUMERIC_CHARACTERS                                       .,
NLS_CHARACTERSET                                             WE8ISO8859P1
NLS_CALENDAR                                                 GREGORIAN
NLS_DATE_FORMAT                                              DD-MON-RR
NLS_DATE_LANGUAGE                                            AMERICAN
NLS_SORT                                                     BINARY
NLS_TIME_FORMAT                                              HH.MI.SSXFF AM

-------------
 修改Oracle10g数据库字符集
SQL> connect sys/oracle as sysdba
SQL> startup mount
SQL> alter session set sql_trace=true;
Session altered.
SQL> alter system enable restricted session;
System altered.
SQL> alter system set job_queue_processes=0;
System altered.
SQL> alter system set aq_tm_processes=0;
System altered.
SQL> alter database open;
Database altered.
SQL> set linesize 120;
SQL> alter database character set zhs16gbk;
alter database character set zhs16gbk
*
ERROR at line 1:
ORA-12712: new character set must be a superset of old character set
SQL> ALTER DATABASE character set INTERNAL_USE zhs16gbk;
# 使用INTERNAL_USE可以跳过超集的检查,ALTER DATABASE character set INTERNAL_USE
Database altered.