代码改变世界

警示:AL32UTF8字符集不是ZHS16GBK字符集的超集

2018-03-26 22:17  AlfredZhao  阅读(...)  评论(...编辑  收藏

今天有客户向我咨询:数据库由ZHS16GBK字符集修改为AL32UTF8字符集,发现中文的数据中小部分出现乱码,客户认为AL32UTF8明明可以支持更多的文字,不应该出现这样的情况才对。
从现象看,基本可以确认故障是字符集转换导致的,Oracle也强烈不建议做这种字符集转换的操作,幸好该客户的操作只是在一个测试环境中操作的。不过,之前也一直有个误区,我们都知道AL32UTF8是可以支持多国语言的字符集,对于中文字节存储占用空间比ZHS16GBK多,然后第一反应就认为AL32UTF8应该是ZHS16GBK的超集。而如果是绝对的超集,就不应该出现任何乱码的情况,可实际用户反馈的现象的确是有小部分出现乱码的情况,所以有必要在测试环境再次验证一下。

1.首先我的库ZHS16GBK的字符集

SQL> select userenv('language') from dual;

USERENV('LANGUAGE')
----------------------------------------------------
AMERICAN_AMERICA.ZHS16GBK

2.尝试修改字符集为AL32UTF8
直接尝试修改,会发现Oracle明确给出错误提示ORA-12712:新的字符集必须是旧字符集的超集。这就说明我们要改的AL32UTF8字符集并不是ZHS16GBK的超集。

SQL> alter database character set al32utf8;
alter database character set al32utf8
*
ERROR at line 1:
ORA-12712: new character set must be a superset of old character set

如果非要修改,可以加internal_use参数强制修改,而这样的操作,自然就很有可能会造成部分数据出现乱码:

SQL> alter database character set internal_use al32utf8;

Database altered.

SQL> select userenv('language') from dual;

USERENV('LANGUAGE')
--------------------------------------------------------------------------------
AMERICAN_AMERICA.AL32UTF8

此时如果我们通过PL/SQL Developer工具连接到数据库,还会有这样的警告信息:

而客户端是Windows,chcp结果是936,也就是ZHS16GBK,这也进一步说明了ZHS16GBK和AL32UTF8字符集的不同。

同时实验还验证,如果数据库字符集本身是AL32UTF8,想修改成为ZHS16GBK字符集,也是一样的情况,需要加internal_use参数才可以转换,也就是说这种转换一样可能出现乱码,不过这个情况反倒好理解,也符合我们之前的认知,就不再赘述了。