Oracle 字符集查詢實戰：服務端、客戶端與 DMP 文件三重驗證

為何要三重驗證？

數據泵導入成功的鐵律：源庫字符集 = 目標庫字符集 = DMP 文件字符集 = 客戶端 NLS_LANG 兼容。任一環節不匹配，必現亂碼或 ORA-12899/ORA-3113。

1. 查詢服務端字符集

SELECT USERENV('language') FROM DUAL;
-- 輸出例：SIMPLIFIED CHINESE_CHINA.AL32UTF8
-- 格式：語言_地區.字符集

或查視圖：

SELECT * FROM V$NLS_PARAMETERS WHERE PARAMETER IN ('NLS_CHARACTERSET','NLS_NCHAR_CHARACTERSET');

2. 解析 DMP 文件字符集

Exp 導出的 DMP 文件第 2-3 字節存儲字符集 ID（16 進制）。

1. 用 UltraEdit 以 16 進制模式打開 DMP，記錄第 2-3 字節值（如 0354）。
2. 轉換查詢：

SELECT NLS_CHARSET_NAME(TO_NUMBER('0354','XXXX')) FROM DUAL;
-- 返回例：ZHS16GBK

注意：僅適用傳統 Exp/Imp 產生的 DMP，Data Pump (expdp) 格式不同，需用 DBMS_METADATA 或 impdp SHOW=Y 獲取。

3. 確認客戶端字符集

• 註冊表：HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_\NLS_LANG
• 會話級臨時修改：

SET NLS_LANG=AMERICAN_AMERICA.ZHS16GBK
-- 僅影響當前 CMD 窗口

實戰核對清單

常見誤區

• 以為 NLS_LANG 只影響顯示，實則決定客戶端發送/接收字節流的編碼解碼邏輯。
• 忽略國家字符集（NLS_NCHAR_CHARACTERSET），導致 NCHAR 列數據截斷或報錯。
• 跨版本導入（如 11g→19c）未檢查字符集兼容性矩陣。