在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字符集。