10g以后Oracle不支持ZHS32GB18030

在9i中Oracle存在字符集ZHS32GB18030,而10g以后,这个字符集在安装数据库的时候已经不可选了。
由于客户的环境需要输入大量的生僻字,要求客户端采用GB18030编码,这使得数据库无法使用ZHS16GBK字符集。
查询了一下字符编码方面的资料,最早推出的GB2312-80编码,包含了大约6000多个汉字,而对应的Oracle字符集编码为ZHS16CGB231280。这6000多个汉字对应日常应用足够,但是稍微生僻一些的汉字就无法在系统中显示。
此后推出了GBK编码,所支持的汉字超过了20000,这对于大部分情况来说足够使用了,其对应的Oracle数据库字符集就是中文中最常用的ZHS16GBK。GBK包含的所有GB2312编码中的汉字,但是二者并非严格意义上的超集关系。
在2000年的时候,出现了GB18030编码,它使用4位字符编码,因此覆盖的汉字达到了60000以上,这时GB18030中编码符合UNICODE 3.0。到2005年的时候,GB18030-2005又收录了一些新的汉字或图形,这时符合UNICODE 4.0编码。在Oracle9i中,存在字符集ZHS32GB18030,对于GB18030编码,但是从10g开始,数据库字符集不再支持ZHS32GB18030字符集了。虽然包括metalink在内介绍了先创建US7ASCII字符集在通过修改数据库字符集的方法将数据库字符集转化为ZHS32GB18030,但是这种方法毕竟不是官方推荐的方法,如果说10g的数据库安装过程中不能选择ZHS32GB18030字符集,是Oracle漏掉了这个字符集,那么在11.2中,同样无法选择这个字符集,就明确说明了Oracle的态度了。事实上,从10g开始,ZHS32GB18030变为客户端字符集,而数据库中之所以还可以创建这个字符集,是Oracle为了后向兼容性,确保9i中ZHS32GB18030字符集的数据库可以顺利的升级。
10g中不再支持ZHS32GB18030字符集,因此Oracle建议用户更改字符集为AL32UTF8或UTF8字符集,详细文档可以参考ID 1144903.1。不过在11.2中UTF8同样是不推荐的字符集之一,那么如果需要在客户端使用GB18030编码,那么推荐使用AL32UTF8字符集。如果客户端使用GB18030-2000编码,那么可以在数据库中选择AL32UTF8字符集,而客户端字符集选择ZHS32GB18030,所有的客户端字符都可以顺利的保存到服务器端或从服务器端读取。如果客户端选择GB18030-2005编码,那么没有专门的客户端字符集与之对应,因此客户端应该与数据库保持一致,都选择AL32UTF8字符集。

This entry was posted in ORACLE and tagged , , . Bookmark the permalink.

One Response to 10g以后Oracle不支持ZHS32GB18030

  1. lt says:

    这是中国国家强制标准,上次我就和Oracle的工程师,想了一招,先用dbca存一个模板,然后把里面的utf-8替换成gb18030,再执行修改的模板。

Leave a Reply

Your email address will not be published. Required fields are marked *