Oracle 字符集亂碼根因深度解析：客戶端轉換、NLS_LANG 與網絡包實證

亂碼本質：雙端字符集不一致導致的錯誤轉換

Oracle 字符集轉換發生在客戶端 OCI 庫 (普通字符串)；NCHAR/NVARCHAR2 經歷客戶端→服務端雙重轉換。

實證環境

• 數據庫字符集：NLS_CHARACTERSET = ZHS16GBK，NLS_NCHAR_CHARACTERSET = AL16UTF16
• 客戶端未設 NLS_LANG → 默認取 OS 字符集 (此處同為 ZHS16GBK)

實驗一：默認環境插入「中」字

INSERT INTO t1 VALUES ('中');
-- 網絡包抓包 (TCP payload)
... 27 D6 D0 27 ...  -- 0xD6D0 = '中' 的 GBK 編碼

客戶端直接發送 GBK 字節，服務端識別為 GBK → 存儲正確。

實驗二：強制客戶端 NLS_LANG=US7ASCII

SET NLS_LANG=AMERICAN_AMERICA.US7ASCII
INSERT INTO t1 VALUES ('中');
-- 網絡包
... 27 3F 3F 27 ...  -- 0x3F3F = '??' (US7ASCII 無法表示雙字節)

OCI 認為客戶端編碼為 US7ASCII，將輸入字節按單字節處理，'中' (D6 D0) 非法 → 替換為 3F (?) → 入庫變「??」。

實驗三：客戶端 NLS_LANG=ZHS16CGB231280 (GB2312)

SET NLS_LANG=SIMPLIFIED CHINESE_CHINA.ZHS16CGB231280
INSERT INTO t1 VALUES ('中');
-- 網絡包: 發送 D6 D0 (GB2312中'中'同碼)
-- 服務端按 GBK 接收 → 正確 (GB2312⊂GBK)

核心結論

1. NLS_LANG 必須等於客戶端實際編碼環境 (終端/IDE/應用服務器 JVM file.encoding)。
2. 服務端字符集 只能擴不能縮：US7ASCII → ZHS16GBK → AL32UTF8。遷移只能用 DMU/CSALTER 重建。
3. NCHAR 列雙重轉換：客戶端按 NLS_LANG 轉 UTF-16 → 服務端再按 NLS_NCHAR_CHARACTERSET 存儲。
4. JDBC Thin 驅動不依賴 NLS_LANG，直接用 Java char (UTF-16) 與服務端協商字符集。

最佳實踐清單

• 新建庫統一用 AL32UTF8，避免所有字符集問題。
• 客戶端環境變量：NLS_LANG=.AL32UTF8 (語言/地域可省略)。
• Linux 終端：export LANG=zh_CN.UTF-8 + export NLS_LANG=.AL32UTF8。
• Windows CMD/PowerShell：chcp 65001 + 設置註冊表 HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_...\NLS_LANG = .AL32UTF8。
• 應用層：JDBC URL 附加 oracle.jdbc.defaultNChar=true 正確處理 NCHAR。