为什么“今天心情不错”全变成“靠靠靠”的研究.docxVIP

由于最近在通过导入导出的方式迁移数据库，联想到前段时间处理过的一个问题，非常经典，现拿来与大家分享，重点是说明字符集正确设置的重要性。前段时间一朋友的公司连接数据库时，终于内牛满面出现下面我们的常用生活用语了。通过最简单的sqlplus连接，这时，这个数据库不管你查什么，只要是汉字，就全是“靠”了（比如应该是今天心情不错）：SQL select * from abc;NAME--------------------靠靠靠虽然这几个字确实比较带劲，但问题还是要解决的。首先，看下当时的环境，windows下使用的是cmd命令：可以看到现在cmd的字符代码是936，也就是GBK（ZHS16GBK），我们再模拟下当时的情况，服务端确认下：SQL select * from v$nls_parameters where parameter=NLS_CHARACTERSET;PARAMETER VALUE---------------------------------------------------------------- ----------------------------------------------------------------NLS_CHARACTERSET ZHS16GBK服务端是正常的。插入测试数据，加入中文：SQL conn test/testConnected.SQL create table chartest(name varchar2(20));SQL insert into chartest values(今天心情不错);1 row created.SQL commit;Commit complete.客户端修改：C:\Users\bsuiSET NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1当然我们经常在linux下的默认是：Sqlplus登录查询：SQL select * from chartest;NAME--------------------靠靠靠立刻出来了。。。不过是6个汉字变成 了3个靠。下面我们来分析下，我们知道，oracle是把查询的结果传输到客户端的，原服务器是ZHS16GBK，说明数据不存在问题，再从服务端查一下：SQL select * from chartest;NAME--------------------今天心情不错我们再回到客户端，查看下：SQL select name,dump(name) from chartest;NAME------------------------------DUMP(NAME)----------------------------------------------------------------------靠靠靠Typ=1 Len=12: 189,241,205,237,192,199,200,203,184,227,198,240那么肯定是在中间环境发了转换。我们知道WE8ISO8859P1是一个8位的单byte编码方案，但我们的GBK是16位的。也就是说WE8ISO8859P1铁定不是GBK的超集，这样很多的中文汉字编码在其中没有对应关系，无法转换。此时WE8ISO8859P1就会用一个倒过来的问号，“?”来代替那些不可识别的汉字。我们开启Locale Builder，从开始里的oracle目录下的Configuration and Migration Tools里，file open如下：选中WE8ISO8859P1，我们留意到，这个倒置的？的编码是BF，也就是说，如果WE8ISO8859P1无法从ZHS16GBK转换的6汉字：今天心情不错，它就用了6个倒置的问号，“?”来代替，也就是说，转换之后，有了6个BF的编码（Unicode值），我们再去看下BF的编码是什么，去上微软的网站：/zh-CN/goglobal/cc305153.aspx如下：我们点一下这个BF，这个图就换了下：真相便显露出来了，BFBF在GBK中就是靠。也就是说，我们前面的，今天心情不错-??????-BFBFBFBF-靠靠靠当然我们也可以再回到ZHS16GBK，看下靠的本来面目，留意到他们的Unicode值是一样的，都是9760：到此，看到这么多的靠，心里就踏实了，知道这不是什么大的问题。若出来乱码，改下客户端的环境变量即可了。对于windows下，修改注册表：对于linux下，查看当前NLS设置：[oracle