MySQL 中文亂碼完整解決方案：字符集轉換原理與實戰配置

MySQL 中文亂碼本質是「編碼不一致」導致的解碼錯誤。本文從字符集轉換流程、關鍵系統變數、常見亂碼場景、修復步驟四個維度系統講解，助你徹底搞定編碼問題。

一、字符集轉換全流程

一次 SQL 執行涉及五次轉換：

1. Client → connection：客戶端編碼（character_set_client）轉為連接編碼（character_set_connection）。
2. Connection → storage：連接編碼轉為資料庫/表/欄位儲存編碼（character_set_database / 表 / 欄位）。
3. Storage → results：讀取時，儲存編碼轉為結果集編碼（character_set_results）。
4. Results → Client：結果集編碼經網路傳至客戶端，客戶端以自身編碼解碼顯示。

任何一環不匹配皆會產生亂碼。

二、關鍵系統變數

三、快速診斷指令

SHOW VARIABLES LIKE 'character_set_%';
SHOW VARIABLES LIKE 'collation_%';

四、三大通用解決方案

方案 A：統一使用 utf8mb4（現代標準，推薦）

1. 修改 my.cnf/my.ini：

[client]
default-character-set = utf8mb4

[mysql]
default-character-set = utf8mb4

[mysqld]
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
init_connect = 'SET NAMES utf8mb4'

2. 重啟 MySQL 服務。
3. 建庫建表顯式指定：CREATE DATABASE db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
4. 應用程式連線字串加入 charset=utf8mb4（JDBC/PDO/ORM 皆支援）。

方案 B：統一使用 latin1 做「透明傳輸」（舊系統救急）

利用 latin1 單位元組覆蓋 0x00-0xFF 特性，不做任何轉換：

SET NAMES latin1;  -- 等同設定 client/connection/results 皆為 latin1

• 資料表/欄位亦設為 latin1。
• 實際儲存的位元組保持原樣（如 UTF-8 位元組序列），讀取時再由應用層解碼。
• 缺點：無法在 SQL 層做字串操作（排序、LIKE、長度計算皆錯誤）。

方案 C：修正現有錯誤資料（雙重編碼修復）

若資料已寫入錯誤編碼（如 UTF-8 資料被當 latin1 存入），需「還原寫入路徑」再「按正確路徑重寫」：

-- 1. 建立暫存表，欄位設為 latin1
CREATE TABLE tmp_tbl (col VARCHAR(255) CHARACTER SET latin1) ENGINE=InnoDB;

-- 2. 以 latin1 讀出原資料（不轉碼）
INSERT INTO tmp_tbl SELECT col FROM orig_tbl;

-- 3. 將暫存表欄位改為正確編碼（MySQL 會自動按 latin1→utf8mb4 轉換）
ALTER TABLE tmp_tbl MODIFY col VARCHAR(255) CHARACTER SET utf8mb4;

-- 4. 覆蓋回原表
UPDATE orig_tbl o JOIN tmp_tbl t ON o.id=t.id SET o.col=t.col;

五、常見坑點提醒

• utf8 vs utf8mb4：MySQL utf8 僅支援 3 位元組字符（BMP），Emoji 需 utf8mb4。
• 連線池/驅動預設編碼：JDBC 需 characterEncoding=utf8，PHP PDO 需 charset=utf8mb4，Python PyMySQL 需 charset='utf8mb4'。
• Windows cmd 編碼：預設 CP936 (GBK)，執行 chcp 65001 切換 UTF-8 後再連線測試。
• 備份/還原：mysqldump --default-character-set=utf8mb4 導出，導入時同樣指定字符集。