搞懂oracle字符集-不错.doc

搞懂oracle字符集-不错 搞懂oracle字符集 作为一个ORACLE DBA,在工作中会经常处理由于字符集产生的一些问题。但是当真正想写一些这方面的东西时，却突然又没有了头绪。发了半天呆，还是决定用两个字符集方面的例子作为切入点，倒不失为一个头绪，说不定在实验的过程中，问题就会一个接着一个的浮现出来。 现在，让我们切入正题。 我用的数据库是oracle10.2.0.3,数据库字符集是al32utf8。 客户端就是同一台机器的windows xp. 下面是演示的例子： SQL drop table test purge; Table dropped. SQL create table test(col1 number(1),col2 varchar2(10)); Table created. --session 1 设置客户端字符集为 zhs16gbk（修改注册表nls_lang项的characterset 为zhs16gbk） 向表中插入两个中文字符。 SQL insert into test values(1,中国); --1为session 1的标记 1 row created. SQL commit; Commit complete. --session 2 设置客户端字符集 al32utf8（修改注册表nls_lang项的characterset 为al32utf8），与数据库字符集相同。 向表中插入两个和session 1相同的中文字符。 SQL insert into test values(2,中国); --2为session 2的标记 1 row created. SQL commit; Commit complete. --session 1 SQL select * from test; COL1 COL2 2 ？?? 1 中国 --session 2 SQL select * from test; COL1 COL2 2 中国 1 涓浗 从session 1和session 2的结果中可以看到，相同的字符（注意，我指的是我们看到的，显示为相同的字符），在不同的字符集输入环境下，显示成了乱码。 在zhs16gbk字符集的客户端，我们看到了utf8字符集客户端输入的相同的中文变成了乱码--col1=2的col2字段 在utf8字符集客户端，我们看到zhs16gbk字符集的客户端输入的中文变成了另外的字符 --col1=1的col2字段 从这个例子里，我们好像感觉到出了什么问题，也可能会联想起现实环境中出现的乱码问题。 问题似乎有了思路，ok，让我们继续把实验做下去： --session 1 （或者session 2，在这里无所谓） SQL select col1,dump(col2,1016) from test; COL1 DUMP(COL2,1016) 2 Typ=1 Len=4 CharacterSet=AL32UTF8: d6,d0,b9,fa 1 Typ=1 Len=6 CharacterSet=AL32UTF8: e4,b8,ad,e5,9b,bd 我们使用了dump函数，结果看起来很明显了，两个完全相同的字符，在不同的字符集环境下，在数据库中存储成了不同的编码。 对于ZHS16GBK的字符集客户端输入的字符中国，AL32UTF8使用了3个字节来分别存储一个字符，即： 中--e4,b8,ad 国--e5,9b,bd 我们也可以分别对这个字符进行验证： --session 1 SQL select dump(中,1016) from dual; DUMP(中,16) Typ=96 Len=3 CharacterSet=AL32UTF8: e4,b8,ad --字符“中” ，和上面直接从数据库中读取存储的字符编码一致。 SQL select dump(国,1016) from dual; DUMP(国,16) Typ=96 Len=3CharacterSet=AL32UTF8: e5,9b,bd --字符“国” ，和上面直接从数据库中读取存储的字符编码一致。 如果使用session 2直接对着两个字符进行测试，一样会得到相同的结果（笔者已经做过测试，这里为了避免冗长，删掉了）. 让我们重新来理一下思路，并提出几个问题： 1：为什么显示为相同的字符，存储到数据库中却变成了不同的编码？ 2：我们在向数据库中插入数据的时候，oracle究竟做了些什么？ 3：操作系统字符集，客户端字符集，数据库字符集究竟是什么关系？ 带着这些疑惑，让我们接着做实验，所有的疑团和猜测都会在试验中得以验证。 我的思路是，先取得测试环境的相关参数。 1：windows字符集(codepa