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