JDBC 讀取 Oracle US7ASCII 字元集中文亂碼解決方案與字元編碼深度解析

JDBC 讀取 Oracle US7ASCII 字元集中文亂碼解決方案與字元編碼深度解析

遇到 Oracle 資料庫字元集為 US7ASCII 時，JDBC 讀取中文會出現亂碼。本文記錄排查過程、解決方案，並深入探討不同字元集下中文位元組佔用差異。

問題現場

• 資料庫：Oracle 10g，字元集 SIMPLIFIED CHINESE_CHINA.US7ASCII
• JDK：1.6.0_45，驅動 ojdbc14.jar
• 現象：PL/SQL Developer 顯示正常，JDBC 查詢中文全為亂碼，且資料從資料庫取出時已是亂碼

解決方案 1：程式碼層面強制轉碼

經測試，雙層轉碼可修正：

// 錯誤嘗試：單層轉碼無效
new String(fieldValue.getBytes("ISO-8859-1"));

// 正確寫法：指定源編碼與目標編碼
String correctValue = new String(fieldValue.getBytes("ISO-8859-1"), "GBK");

原理：US7ASCII 環境下，驅動以 ISO-8859-1 讀取位元組流，實際內容為 GBK 編碼中文，需先還原位元組再按 GBK 解碼。

缺點：所有中文欄位皆需手動轉碼，維護成本高。

解決方案 2：設定 NLS_LANG 環境變數（推薦）

在客戶端機器設定系統環境變數：

變數名：NLS_LANG
值：SIMPLIFIED CHINESE_CHINA.ZHS16GBK

重啟應用程式後，JDBC 自動按正確字元集交換資料，無需修改代碼。

註冊表同樣可設：HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOME0\NLS_LANG

字元集與中文位元組佔用對照表

實戰踩坑：跨庫遷移字元長度不足

將 US7ASCII 庫中文遷移至 AL32UTF8 庫時，原 VARCHAR2(20) 欄位存 10 個中文會報錯：

• 源端：10 中文 × 1 位元組 = 10 位元組（但實際已損壞）
• 目標端：10 中文 × 3 位元組 = 30 位元組 > 20

解決：擴充欄位長度或改用 NVARCHAR2（按字元計長度，中英同為 1 字元）。

快速驗證當前字元集中文位元組數

SELECT LENGTH('汗'), LENGTHB('汗') FROM DUAL;
-- LENGTH 回傳字元數，LENGTHB 回傳位元組數

最佳實踐建議

1. 新系統嚴禁使用 US7ASCII，預設採用 AL32UTF8
2. 舊系統遷移時務必評估欄位長度擴充
3. 統一設定客戶端 NLS_LANG，避免應用層處理編碼
4. 跨字元集遷移前用 LENGTHB 實測位元組長度