DB2 Code Page 實戰意義：字符集轉換、跨平台遷移與亂碼根治指南

許多 DBA 對 `CODEPAGE` 概念模糊：建庫時指定 `CODESET UTF-8`，卻發現 `CODEPAGE` 固定為 1208（UTF-8 對應代碼頁），以為兩者等價甚至無實際作用。實則不然——Code Page 是 DB2 執行字符編碼轉換的核心標識，直接決定跨庫連接、複寫、聯邦查詢、應用驅動程式連接時的字元正確性。

Code Page vs Code Set：一組映射關係

• Code Set (CODESET)：資料庫層級的字符集名稱（如 `UTF-8`、`GBK`、`BIG5`、`ISO8859-1`），建庫時指定，建庫後不可變。
• Code Page (CODEPAGE)：DB2 內部用於識別編碼的數值 ID（如 1208=UTF-8, 1386=GBK, 950=Big5, 819=ISO-8859-1），由 Code Set 一對一映射得出，可通過 `DB2 GET DB CFG` 查看 `Database code page`。

同一 Code Set 在不同平台（Windows/Linux/AIX）對應的 Code Page 完全相同，這是跨平台遷移不產生編碼偏移的基礎。

實戰場景：為何連接成功卻報轉換錯誤？

現象：來源庫 Code Page 1208 (UTF-8)，目標庫 Code Page 950 (Big5)。`CONNECT TO` 成功，但 `INSERT`/`SELECT` 或複寫時報 `SQL30081N` / `SQL3303N` 轉換表缺失或字元無法映射。

原因：DB2 連接建立階段不驗證字符轉換可行性，僅在首次跨 Code Page 數據傳輸時載入轉換表（`sqllib/conv/` 下 `.cnv` 檔）。若目標平台缺少對應 `.cnv`、或字元確實無法映射（如 Emoji 寫入 Big5），即拋錯。

避坑指南與最佳實踐

1. 新建庫統一 UTF-8 (Code Page 1208)：支援全字符集、無轉換損失、跨平台零配置，是現代應用首選。
2. 舊系統遷移必做字符集評估：`db2move`/`db2look` 導出前，用 `DESCRIBE TABLE` 確認字元欄位實際編碼；若目標庫 Code Page 不同，務必預先測試轉換：`db2 "CALL SYSPROC.ADMIN_CMD('EXPORT ...')"` 觀察是否報 `SQL0332N`。
3. 應用端驅動程式 Code Page 對齊：JDBC `clientEncoding`、CLI `DB2CODEPAGE` 環境變數、.NET `DB2ConnectionString` 的 `CodePage` 屬性，必須與資料庫 Code Page 一致，否則驅動層會嘗試轉換導致雙重轉碼或亂碼。
4. 聯邦/複寫跨 Code Page 強制同質：來源/目標庫 Code Page 不同時，需在聯邦包裝器/複寫訂閱定義中顯式指定 `CODEPAGE` 選項，並確認雙端 `sqllib/conv` 目錄完整。

快速驗證命令

-- 查看資料庫 Code Page 與 Code Set
GET DB CFG FOR  | grep -i -e "code page" -e "codeset"

-- 列出平台支援的所有 Code Page 映射
db2 "SELECT CODEPAGE, CODESET FROM SYSIBM.SYSCODEPAGES"

-- 測試特定字元在目標 Code Page 下是否可表達
-- (需在目標資料庫執行)
VALUES CHR(HEX('F09F9880')) -- 嘗試插入 Emoji 😀，若目標非 UTF-8 會報錯

結語：Code Page 非理論概念，而是字元在 DB2 內部流轉的「護照號」。統一 UTF-8 (1208) 是消除 90% 編碼故障的銀彈；若歷史系統必須共存異構 Code Page，請建立「轉換表完整性檢查」與「應用端編碼對齊清單」兩道防線，將亂碼風險壓縮至最低。