MySQL 亂碼問題終極寶典：編碼轉換流程圖解、錯進錯出陷阱與資料修復實戰

MySQL 亂碼本質是「編碼/解碼不一致」。本文用流程圖解析存入/讀出三次編碼轉換，深度剖析錯進錯出失效條件，提供 Dump&Reload 與 Binary 中轉兩大標準修復方案。

一、編碼轉換全流程 (三次關鍵轉換)

存入階段

1. Client 端： 輸入法 → 字元編碼 (C1) → 二進制流
2. Server 端： 二進制流 → character_set_client (C2) 解碼
3. 引擎層： C2 → 表字元集 (C3) 轉換 → 寫入磁碟

讀出階段

1. 引擎層： 磁碟二進制 → 表字元集 (C3') 解碼
2. Server 端： C3' → character_set_client (C2') 編碼 → 二進制流
3. Client 端： 二進制流 → 終端機編碼 (C1') 顯示

二、亂碼兩大根因

1. 存/讀對應環節編碼不一致： C1≠C1' 或 C2≠C2' 或 C3≠C3'
2. 單向流程三步編碼不一致： C1≠C2≠C3 (或 C1'≠C2'≠C3')

三、無損轉換與「錯進錯出」陷阱

無損轉換條件

• 字符同時存在於源/目標字元集
• 目標字元集對不支援字符保留原始位元組 (如 latin1)

錯進錯出失效實證

-- 客戶端 UTF-8，Server 設 GBK，表 UTF-8
SET NAMES gbk;
INSERT INTO utf8_table (col) VALUES ('中文');
-- Warning: Incorrect string value: '\xE4\xB8\xAD\xE6\x96\x87'
-- 結果存入亂碼，讀出永久損壞

GBK 無法表示部分 UTF-8 字符，轉換時替換為 0x3F (?)，資料永久遺失。

latin1 例外：錯進錯出實際可行

CREATE TABLE t (c VARCHAR(50)) CHARSET=latin1;
SET NAMES latin1;
INSERT INTO t VALUES ('中文');  -- 實際寫入 UTF-8 位元組
SELECT c FROM t;  -- 終端 UTF-8 顯示正常

latin1 1:1 映射 0x00-0xFF，不處理超出範圍字符，保留原始位元組，形成「錯進錯出」假象。

四、避免亂碼鐵律：三位一體

# 客戶端/連線/表 統一字元集
[client] default-character-set = utf8mb4
[mysqld] character-set-server = utf8mb4
# 建表指定
CREATE TABLE t (...) CHARSET=utf8mb4;

五、標準修復方案一：Dump & Reload (最穩妥)

1. 用「錯進錯出」正確連線參數導出：
   mysqldump -u root -p --default-character-set=utf8 --skip-set-charset db table > data.sql
2. 建立正確字元集新表：
   CREATE TABLE new_t (...) CHARSET=utf8mb4;
3. 用正確字元集導入：
   mysql -u root -p --default-character-set=utf8mb4 db < data.sql

六、標準修復方案二：Binary 中轉 (巧妙高效)

-- 步驟1: 字串欄位 → VARBINARY (不轉碼，保留原始位元組)
ALTER TABLE t MODIFY COLUMN c VARBINARY(50);

-- 步驟2: VARBINARY → 目標字元集 (按新字元集重新解碼)
ALTER TABLE t MODIFY COLUMN c VARCHAR(50) CHARACTER SET utf8mb4;

原理：MySQL 字串→二進制不轉碼，二進制→字串按目標字元集編碼，等同於在 Server 端完成「錯出→正入」。

七、錯誤修復方案避坑