经常看到一些朋友问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=
1<language>_<territory>.<clients characterset="">，其中第三部分<clients characterset="">的本意就是用来指明客户端操作系统缺省使用的字符集。所以按正规的用法，NLS_LANG应该按照客户端机器的实际情况进行配置，尤其对于字符集一项更是如此，这样Oracle就能够在最大程度上实现数据库字符集与客户端字符集的自动转换（当然是如果需要转换的话）。
2**总结一下第一次迭代的重点：**
3**字符集：** 将特定的符号集编码为计算机能够处理的数值；
4**字符集间的转换：** 对于在源字符集与目标字符集都存在的符号，理论上转换将不会产生信息丢失；而对于在源字符集中存在而在目标字符集中不存在的符号，理论上转换将会产生信息丢失；
5**数据库字符集：** 选择能够包含所有将要存储的信息符号的字符集；
6**客户端字符集设置：** 指明客户端操作系统缺省使用的字符集。
7
8第二次迭代：通过实例加深对基本概念的理解
9
10下面我将引用网友tellin在ITPUB上发表的“CHARACTER SET研究及疑问”帖子，该朋友在帖子中列举了他做的相关实验，并对实验结果提出了一些疑问，我将对他的实验结果进行分析，并回答他的疑问。
11**实验结果分析一**
12
13
14> quote:
15>
16> * * *
17>
18> _最初由 tellin 发布_
19> 设置客户端字符集为US7ASCII
20> D:\>SET NLS_LANG=AMERICAN_AMERICA.US7ASCII
21> 查看服务器字符集为US7ASCII
22> SQL> SELECT * FROM NLS_DATABASE_PARAMETERS;
23> PARAMETER VALUE
24> \------------------------------ ----------------------------------------
25> NLS_CHARACTERSET US7ASCII
26>
27> 建立测试表
28> SQL> CREATE TABLE TEST (R1 VARCHAR2(10));
29>
30> Table created.
31>
32> 插入数据
33> SQL> INSERT INTO TEST VALUES('东北');
34>
35> 1 row created.
36>
37> SQL> SELECT * FROM TEST;
38>
39> R1
40> \----------
41> 东北
42>
43> SQL> EXIT
44>
45>
46>
47> * * *
48
49
50
51这一部分的实验数据的存取与显示都正确，好象没什么问题，但实际上却隐藏着很大的隐患。
52首先，要将汉字存入数据库，而将数据库字符集设置为US7ASCII是不合适的。US7ASCII字符集只定义了128个符号，并不支持汉字。另外，由于在SQL*PLUS中能够输入中文，操作系统缺省应该是支持中文的，但在NLS_LANG中的字符集设置为US7ASCII，显然也是不正确的，它没有反映客户端的实际情况。
53但实际显示却是正确的，这主要是因为Oracle检查数据库与客户端的字符集设置是同样的，那么数据在客户与数据库之间的存取过程中将不发生任何转换。具体地说，在客户端输入“东北”，“东”的汉字的编码为182（10110110）、171（10101011），“北”汉字的编码为177（10110001）、177（10110001），它们将不做任何变化的存入数据库中，但是这实际上导致了 **数据库标识的字符集与实际存入的内容是不相符的，** 从某种意义上讲，这也是一种不一致性，也是一种错误。而在SELECT的过程中，Oracle同样检查发现数据库与客户端的字符集设置是相同的，所以它也将存入的内容原封不动地传送到客户端，而客户端操作系统识别出这是汉字编码所以能够正确显示。
54在这个例子中，数据库与客户端的设置都有问题，但却好象起到了“负负得正”的效果，从应用的角度看倒好象没问题。但这里面却存在着极大的隐患，比如在应用length或substr等字符串函数时，就可能得到意外的结果。另外，如果遇到导入/导出（import /export）将会遇到更大的麻烦。有些朋友在这方面做了大量的测试，如eygle研究了“源数据库字符集为US7ASCII，导出文件字符集为US7ASCII或ZHS16GBK，目标数据库字符集为ZHS16GBK”的情况，他得出的结论是 “如果的是在Oracle92中，我们发现对于这种情况，不论怎样处理，这个导出文件都无法正确导入到Oracle9i数据库中”、“对于这种情况，我们可以通过使用Oracle8i的导出工具，设置导出字符集为US7ASCII，导出后修改第二、三字符，修改 0001 为0354,这样就可以将US7ASCII字符集的数据正确导入到ZHS16GBK的数据库中”。我想对于这些结论，这样理解可能更合适一些： **由于ZHS16GBK字符集是US7ASCII的超级，所以如果按正常操作，这种转换应该没有问题；但出现问题的本质是我们让本应只存储英文字符的US7ASCII数据库，非常规地存储了中文信息，那么在转化过程中出现错误或麻烦就没什么奇怪的了，不出麻烦倒是有些奇怪了。**
55所以说要避免这种情况，就是要在建立数据库时选择合适的字符集，不让标签（数据库的字符集设置）与实际（数据库中实际存储的信息）不符的情况发生。
56
57实验结果分析二
58
59> quote:
60>
61> * * *
62>
63> [ 更改客户端字符集为ZHS16GBK
64> D:\>SET NLS_LANG=AMERICAN_AMERICA.ZHS16GBK
65>
66> D:\>SQLPLUS "/ AS SYSDBA"
67>
68> 无法正常显示数据
69>
70> SQL> SELECT * FROM TEST;
71>
72> R1
73> \--------------------
74> 6+11
75>
76> 疑问1：ZHS16GBK为US7ASCII的超集，为什么在ZHS16GBK环境下无法正常显示
77>
78>
79>
80> * * *
81
82
83
84这主要是因为Oracle检查发现数据库设置的字符集与客户端配置字符集不同，它将对数据进行字符集的转换。数据库中实际存放的数据为182（10110110）、171（10101011）、177（10110001）、177（10110001），由于数据库字符集设置为US7ASCII，它是一个7bit的字符集，存储在8bit的字节中，则Oracle忽略各字节的最高bit，则182（10110110）就变成了54（0110110），在ZHS16GBK中代表数字符号“6”（当然在其它字符集中也是“6”），同样过程也发生在其它3个字节，这样“东北”就变成了“6+11”。
85
86实验结果分析三
87
88> quote:
89>
90> * * *
91>
92> _最初由 tellin 发布_
93> 用ZHS16GBK插入数据
94> SQL> INSERT INTO TEST VALUES('东北');
95>
96> 1 row created.
97>
98> SQL> SELECT * FROM TEST;
99>
100> R1
101> \--------------------
102> 6+11
103> ??
104>
105> SQL> EXIT
106>
107>
108> * * *
109
110
111当客户端字符集设置为ZHS16GBK后向数据库插入“东北”，Oracle检查发现数据库设置的字符集为US7ASCII与客户端不一致，需要进行转换，但字符集ZHS16GBK中的“东北”两字在US7ASCII中没有对应的字符，所以Oracle用统一的“替换字符”插入数据库，在这里为“？”，编码为63（00111111），这时，输入的信息实际上已经丢失，不管字符集设置如何改变（如下面引用的实验结果），第二行SELECT出来的结果也都是两个“？”号（注意是2个，而不是4个）。
112
113
114> quote:
115>
116> * * *
117>
118>
119> 更改客户端字符集为US7ASCII
120> D:\>SET NLS_LANG=AMERICAN_AMERICA.US7ASCII
121>
122> D:\>SQLPLUS "/ AS SYSDBA"
123>
124> 无法显示用ZHS16GBK插入的字符集，但可以显示用US7ASCII插入的字符集
125> SQL> SELECT * FROM TEST;
126>
127> R1
128> \----------
129> 东北
130> ??
131>
132>
133> 更改服务器字符集为ZHS16GBK
134> SQL> update props$ set value$='ZHS16GBK' WHERE NAME='NLS_CHARACTERSET';
135>
136> 1 row updated.
137>
138> SQL> COMMIT;
139>
140> 更改客户端字符集为ZHS16GBK
141> D:\>SET NLS_LANG=AMERICAN_AMERICA.ZHS16GBK
142>
143> D:\>SQLPLUS "/ AS SYSDBA"
144>
145> 可以显示以前US7ASCII的字符集，但无法显示用ZHS16GBK插入的数据，说明用ZHS16GBK插入的数据为乱码。
146>
147> SQL> SELECT * FROM TEST;
148>
149> R1
150> \--------------------
151> 东北
152> ??
153>
154>
155> * * *
156
157
158需要指出的是，通过“update props$ set value$='ZHS16GBK' WHERE NAME='NLS_CHARACTERSET';”来修改数据库字符集是非常规作法，很可能引起问题，在这里只是原文引用网友的实验结果。
159
160
161
162
163实验结果分析四
164
165> quote:
166>
167> * * *
168>
169>
170> SQL> INSERT INTO TEST VALUES('东北');
171>
172> 1 row created.
173>
174> SQL> SELECT * FROM TEST;
175>
176> R1
177> \--------------------
178> 东北
179> ??
180> 东北
181>
182> SQL> EXIT
183>
184>
185> * * *
186
187
188由于此时数据库与客户端的字符集设置均为ZHS16GBK，所以不会发生字符集的转换，第一行与第三行数据显示正确，而第二行由于存储的数据就是63（00111111），所以显示的是“？”号。
189
190
191> quote:
192>
193> * * *
194>
195>
196> 更改客户端字符集为US7ASCII
197>
198> D:\>SET NLS_LANG=AMERICAN_AMERICA.US7ASCII
199>
200> D:\>SQLPLUS "/ AS SYSDBA"
201>
202> 无法显示数据
203>
204> SQL> SELECT * FROM TEST;
205>
206> R1
207> \----------
208> ??
209> ??
210> ??
211>
212> 疑问2：第一行数据是用US7ASCII环境插入的，为何无法正常显示？
213>
214>
215> * * *
216
217
218将客户端字符集设置改为US7ASCII后进行SELECT，Oracle检查发现数据库设置的字符集为ZHS16GBK，数据需要进行字符集转换，而第一行与第三行的汉字“东”与“北”在客户端字符集US7ASCII中没有对应字符，所以转换为“替换字符”（“？”），而第二行数据在数据库中存的本来就是两个“？”号，所以虽然在客户端显示的三行都是两个“？”号，但在数据库中存储的内容却是不同的。
219
220
221
222实验结果分析五
223
224> quote:
225>
226> * * *
227>
228>
229>
230> SQL> INSERT INTO TEST VALUES('东北');
231>
232> 1 row created.
233>
234> SQL> EXIT
235> 更改客户端字符集为ZHS16GBK
236> D:\>SET NLS_LANG=AMERICAN_AMERICA.ZHS16GBK
237>
238> D:\>SQLPLUS "/ AS SYSDBA"
239>
240> 无法显示用US7ASCII插入的字符集，但可以显示用ZHS16GBK插入的字符集
241> SQL> SELECT * FROM TEST;
242>
243> R1
244> \--------------------
245> 东北
246> ??
247> 东北
248> 6+11
249>
250> SQL>
251> 疑问3：US7ASCII为ZHS16GBK的子集，为何在US7ASCII环境下插入的数据无法显示？ [/B]
252>
253> * * *
254
255
256在客户端字符集设置为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，数据库中的信息不需要改变传到客户端，第一、三行由于存入的信息没有改变能显示“东北”，而第二、四行由于插入数据时信息改变，所以不能显示原有信息了。
257
258
259
260分析了这么多的内容，但实际上总结起来也很简单，要想在字符集方面少些错误与麻烦，需要坚持两条基本原则：
261**在数据库端：选择需要的字符集** （通过create database中的CHARACTER SET与NATIONAL CHARACTER SET子句指定）；
262**在客户端：设置操作系统实际使用的字符集** （通过环境变量NLS_LANG设置）。
263
264
265**例如:
266CHARACTER SET ZHS16GBK
267NATIONAL CHARACTER SET AL16UTF16 **</clients></clients></territory></language>