深度解析 MySQL 字符集設定：從基本概念到轉換流程、常見亂碼場景與最佳實踐

基本概念

• 字符：人類語言最小表義符號 (如 'A'、'中')。
• 編碼：字符 → 數值映射 (如 'A' → 65)。
• 字符集：字符與編碼對的集合 (如 {'A'→65, 'B'→66})。
• 校對集：同一字符集內字符比較/排序規則 (如 utf8_general_ci 不分大小寫)。
• 命名慣例：<charset>_<rule>_ci/cs/bin。

MySQL 字符集系統變量

字符集轉換全流程

1. Server 收到請求：**client → connection** 編碼轉換。
2. 內部操作前：**connection → 內部操作字符集** (依欄位 > 表 > 庫 > server 級聯確定)。
3. 結果返回：**內部操作字符集 → results** 編碼轉換。

兩大經典亂碼場景複盤

場景一：庫表 UTF-8，連接未設，插入中文 → 查詢設連接 UTF-8 → 亂碼

• 插入時：latin1 → latin1 → utf8，每漢字 3 字節 → 6 字節落盤。
• 查詢時：utf8 → utf8 原封返回 6 字節 → 亂碼。

場景二：庫表 Latin1，連接設 UTF-8，插入中文 → 永久損壞

• 插入時：utf8 → utf8 → latin1，超出 Latin1 範圍字符 (如中文) 強制轉 0x3F (?)，**資料永久遺失**。

檢測工具箱

SHOW CHARACTER SET;
SHOW COLLATION;
SHOW VARIABLES LIKE 'character%';
SHOW VARIABLES LIKE 'collation%';
SELECT HEX(col), LENGTH(col), CHAR_LENGTH(col), CHARSET(col), COLLATION(col) FROM tbl;

• HEX 看實際位元組，LENGTH 位元組長，CHAR_LENGTH 字符長，比值 = 平均字節/字符。
• CHARSET()/COLLATION() 確認欄位實際屬性。

最佳實踐清單

1. **顯式指定**：建庫/建表/連接全部寫明 utf8mb4，不信賴預設。
2. **統一 utf8mb4**：庫表 + 連接同為 utf8mb4，支援 Emoji，避免補充字符截斷。
3. **驅動層自動化**：C API mysql_options(MYSQL_SET_CHARSET_NAME, "utf8mb4")；PHP 每請求 SET NAMES utf8mb4；長連接重連後必重發。
4. my.cnf default-character-set **僅影響命令列客戶端**，應用層無效。
5. SQL 函數在內部字符集執行，不受連接編碼干擾。
6. 字串字面值加介紹符 _utf8mb4'中文' 強制編碼，避免隱式轉換驚喜。

結語

字符集問題本質是**編碼不一致的多次轉換導致資訊損失**。建立「顯式配置、全鏈路 utf8mb4、驅動層自動化、HEX 驗證」標準化流程，可從架構層面根治亂碼。