本文共 1231 字，大约阅读时间需要 4 分钟。

最近在做回归测试，将已经写好的脚本导入到初始化的数据库中，出现如下结果。

SQL> insert into DCT (ID, DCTID, SEQNO, VALUE, TEXT, PARAM) values (‘OrgType_City’, ‘OrgType’, 2, ‘3’, ‘中文字符’, null);

SQL> update fld t set t.options = ‘中文字符’ where t.id = ‘VUSR_GRPID’;

1 row inserted.

有些中文字符可以插入成功，有些则不可以，很是奇怪，而且，我将不成功的语句用sql窗口，也不可以，但是只要把中文字符去掉或者替换成英文字符就可以，这说明还是字符编码的问题。

查看数据库字符编码：

可以看到字符编码为：SIMPLIFIED CHINESE_CHINA.AL32UTF8 （SIMPLIFIED CHINESE:表示简体中文、CHINA:表示地区、AL32UTF8:数据库编码方式）。AL32UTF8与UTF8编码是不一致的哦。

查看Client端的字符编码：

“运行”->“regedit”->”HKEY_LOCAL_MACHINE”->”SOFTWARE”->”ORACLE”->”KEY_XE”(XE：我的数据库实例名)->”NLS_LANG”

可以发现我的Client编码为：SIMPLIFIED CHINESE_CHINA.ZHS16GBK（GBK编码格式）。

注意：如果我们设置了环境变量的话，那么数据库是会优先取读环境变量的NLS_LANG变量作为Client端的编码方式的。

好了，找到了这么多的编码方式，那么这些编码方式之间的关系是怎样的呢。

规则1：若client端的编码方式与数据库端的不一致，那么在进行插入更新的时候，数据会由client的编码方式，转化为数据库的编码方式。这个时候，你的sql脚本的编码方式要与client端的编码方式保持一致。例如：我的sql文件就应该为GBK的编码方式。

规则2：若client端的编码方式与数据库的一致，就不会进行编码转化，那么你的sql脚本就要与数据库端的编码方式一致，例如：我的sql脚本的编码方式就应该为AL32UTF8（与UTF8是不一致的），但是，在window上休想找到这个编码方式，所以最好还是老老实实的用规则1较好。

明白了这些，那么问题就容易找到了，我的原因是我的client端的编码方式为AL32UTF8（图中的是修改后的），sql文件使用的是UTF8的编码方式。

解决方案：将注册表中、环境变量中的NLS_LANG都设置为SIMPLIFIED CHINESE_CHINA.ZHS16GBK ，将sql文件设置为GBK的编码方式，重启机器，大功告成。

推荐一个更深层次的好文：。