PL/SQL 連接 Oracle 亂碼終極解決：源頭編碼才是關鍵

問題現象

PL/SQL 查詢 Oracle 數據庫，中文顯示為問號 (???)。嘗試過修改註冊表 NLS_LANG、設置環境變量、重啟服務均無效。

排查過程回顧

1. 確認服務端字符集：SELECT * FROM NLS_DATABASE_PARAMETERS → ZHS16GBK
2. 確認註冊表：HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OraClient11g_home1\NLS_LANG → SIMPLIFIED CHINESE_CHINA.ZHS16GBK
3. 設置環境變量：NLS_LANG=SIMPLIFIED CHINESE_CHINA.ZHS16GBK
4. 重啟 Oracle 服務與 PL/SQL
5. 結果：仍然亂碼

真相大白：建表腳本文件編碼不匹配

建表 SQL 腳本在記事本中編輯，默認保存為 ANSI/GBK，但數據庫期望 UTF-8，導致寫入數據時編碼錯位。

解決方案

1. 用 Notepad++ / VS Code 打開 .sql 文件
2. 選中「編碼」→「轉為 UTF-8 編碼」或「另存為 UTF-8」
3. 重新執行建表腳本
4. 重新插入中文數據
5. PL/SQL 查詢恢復正常

編碼鏈路完整圖譜

客戶端工具 (PL/SQL) 
    ↓ NLS_LANG 設置
網絡傳輸層 (OCI/OJDBC)
    ↓ 字符集轉換
數據庫服務端 (NLS_DATABASE_PARAMETERS)
    ↓ 存儲
數據文件 / 內存

關鍵點：任何一環編碼不一致都會導致亂碼。文件編碼屬於「寫入端」源頭，最容易被忽視。

最佳實踐清單

1. 統一編碼：項目全鏈路使用 UTF-8 (AL32UTF8)
2. 工具配置：IDE/編輯器默認編碼設為 UTF-8
3. 腳本管理：版本控制中的 .sql 文件強制 UTF-8
4. 連接字符串：JDBC URL 添加 ?characterEncoding=utf8
5. 驗證命令：SELECT DUMP('中文', 1016) FROM DUAL 檢查實際存儲字節

總結

亂碼問題 90% 是編碼不一致。當客戶端、驅動、服務端配置都正確時，請檢查數據源頭文件編碼。記事本默認 ANSI 是巨坑，專業開發請使用支持編碼顯示和轉換的編輯器。