DB2 與 MySQL 字元集設定實戰：從建庫到命令列編碼一致性

字元集設定錯誤是資料庫中文亂碼的首因。本文以 MySQL 與 DB2 為例，解析三層編碼鏈路：資料庫/表層級設定 → 用戶端/命令列編碼 → SQL 腳本檔案編碼，三者必須一致才能正確存取中文。

資料庫與表層級字元集設定

MySQL

-- 建庫指定預設字元集
CREATE DATABASE mydb DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

-- 建表指定（可覆蓋資料庫預設）
CREATE TABLE t1 (
  id VARCHAR(255)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

建議：使用 utf8mb4（支援完整 Unicode 包含 Emoji），而非舊版 utf8（僅支援 BMP 平面）。

DB2

-- 建庫指定 CODESET 與 TERRITORY
CREATE DATABASE mydb USING CODESET UTF-8 TERRITORY CN;
-- 或使用數值代碼頁
CREATE DATABASE mydb USING CODESET 1208 TERRITORY CN;

• CODESET UTF-8 / 1208：Unicode UTF-8 編碼
• TERRITORY CN：中國地區設定（影響日期/貨幣/排序規則）
• DB2 資料庫建立後無法修改 CODESET，必須建庫時決定

命令列/用戶端編碼設定（關鍵）

資料庫儲存為 UTF-8，但命令列視窗預設編碼通常為 GBK (CP936/1386)。若不調整，輸入中文會被誤解碼。

MySQL

• 臨時：SET NAMES gbk;（僅當前連線）
• 永久：修改 my.ini [client] default-character-set=gbk

DB2

• 臨時：db2set DB2CODEPAGE=1386（1386 = GBK/CP936）
• 永久：db2set DB2CODEPAGE=1386 -g（全域/實例級）

原理：設定後，用戶端以 GBK 輸入 → DB2 自動轉為 UTF-8 存入 → 查詢時 UTF-8 轉 GBK 顯示，實現「所見即所得」。

SQL 腳本檔案編碼要求

執行 source file.sql (MySQL) 或 db2 -tf file.sql (DB2) 時：

• 檔案編碼 必須等於當前命令列編碼（即 GBK/ANSI）
• Windows 記事本：另存為 → 編碼選 ANSI（實為系統預設代碼頁，中文環境即 GBK）
• 不可使用 UTF-8 編碼的 .sql 檔：GBK 命令列無法正確解碼 UTF-8 檔案中的中文，導致入庫亂碼或錯誤

完整驗證流程

1. 建庫指定 UTF-8 / utf8mb4
2. 命令列設定 GBK (DB2CODEPAGE=1386 / SET NAMES gbk)
3. SQL 檔存為 ANSI (GBK)
4. 執行腳本建表、插入中文測試資料
5. 查詢驗證：命令列顯示正常、十六進制檢視確認儲存為 UTF-8

常見誤區與避坑

進階：應用程式連線編碼

• JDBC：連線字串無需指定編碼，驅動程式自動協商
• ODBC/CLI：db2cli.ini 設定 CodePage=1386
• .NET：連線字串無需特殊設定，ADO.NET 自動處理