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

由于最近在通过导入导出的方式迁移数据库，联想到前段时间处理过的一个问题，非常经典，现拿来与大家分享，重点是说明字符集正确设置的重要性。

前段时间一朋友的公司连接数据库时，终于内牛满面出现下面我们的常用生活用语了。

通过最简单的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/test
Connected.
SQL> create table chartest(name varchar2(20));
SQL> insert into chartest values('今天心情不错');
1 row created.
SQL> commit;
Commit complete.
客户端修改：
C:\Users\bsui>SET 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@dbp admin]$ env|grep NLS_LANG
NLS_LANG=AMERICAN_AMERICA.ZHS16GBK
修改：
[oracle@dbp admin]$ cd ~
[oracle@dbp ~]$ vi .bash_profile
加入这一行即可：
NLS_LANG=AMERICAN_AMERICA.ZHS16GBK;export NLS_LANG
当然，我们公司及很多环境常用的是AL32UTF8：
SET NLS_LANG=AMERICAN_AMERICA.AL32UTF8
若最初建库的时候，字符集就已经选错，这就需要看是不是跟想要转换的字符集的包含关系了。

虽然有转
换的方法，但是，非常危险，需要强行修改大量的数据字典，而且每个oracle的版本所要修改的各不相当，非常容易全库崩溃及数据丢失。

因此，在最初部署服务端与客户端的环境变量的时候，要非常小心。

客户
端的字符集若设置有问题，则在进行平时的操作以前IMP/DMP操作形成新的数据库时，emp导出的全是“靠”的数据将被导入到目标数据库，一旦目标数据库没有发现这个问题而参与了应用，产生了新的数据，将造成不成估量的隐患与损失。