最近在做回归测试，将已经写好的脚本导入到初始化的数据库中，出现如下结果。
SQL> insert into DCT (ID, DCTID, SEQNO, VALUE, TEXT, PARAM) values (‘OrgType_City’, ‘OrgType’, 2, ‘3’, ‘中文字符’, null);
ERROR:
ORA-01756: quoted string not properly terminated
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的编码方式，重启机器，大功告成。
推荐一个更深层次的好文：使用AL32UTF8字符集遇到的问题。