oracle character set2-air

gdx

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';”来修改数据库字符集是非常规作法，很可能引起问题，在这里只是原文引用网友的实验结果。