MySQL 字元集亂碼根因分析與實戰解決方案：以 GBK/UTF-8 為例

MySQL 字元集問題的本質是「資料寫入時的位元組序列」與「讀取時的解碼方式」不匹配。本文從實戰經驗出發，闡述編碼一致性原則、PHPMyAdmin 匯入陷阱、跨編碼轉換實作。

核心鐵律：寫入編碼 = 讀取編碼 = 連線字元集 = 資料庫/表/欄位字元集

若四者一致，完全不需要 在 MySQL 層面做任何轉換，資料原樣存儲、原樣讀取。

情境 1：全站 GBK (BIG5 同理)

• PHP 檔案儲存為 GBK (ANSI)。
• 資料庫/表/欄位 CHARSET=gbk。
• 連線執行 SET NAMES gbk (或 PDO charset=gbk)。
• 結果：中文正常存取，零亂碼。

情境 2：全站 UTF-8 (推薦)

• PHP 檔案儲存為 UTF-8 無 BOM。
• 資料庫/表/欄位 CHARSET=utf8 (或 utf8mb4)。
• 連線 SET NAMES utf8。
• 結果：完美支援多國語言、Emoji (需 utf8mb4)。

情境 3：寫入 GBK、顯示 UTF-8 (或反向)

應用層必須轉碼：

// PHP 範例：寫入時 GBK→UTF-8 儲存
$utf8_str = iconv('GBK', 'UTF-8', $gbk_str);
mysqli_query($link, "SET NAMES utf8");
mysqli_query($link, "INSERT INTO t(c) VALUES ('$utf8_str')");

// 讀取時 UTF-8→GBK 顯示
mysqli_query($link, "SET NAMES utf8");
$res = mysqli_query($link, "SELECT c FROM t");
$row = mysqli_fetch_assoc($res);
echo iconv('UTF-8', 'GBK', $row['c']);

或使用 mb_convert_encoding()。

PHPMyAdmin 匯入亂碼為何頻發？

• PHPMyAdmin 介面為 UTF-8，匯入 SQL 檔時以 UTF-8 解讀。
• 若 SQL 檔實為 GBK 編碼，未轉碼直接匯入 → 位元組被誤判為 UTF-8 → 亂碼入庫。
• 後續以 GBK 連線讀取 → 再次誤解碼 → 雙重亂碼。

解決三法

1. 匯入前用 iconv -f gbk -t utf-8 轉碼 SQL 檔，再用 PHPMyAdmin 匯入。
2. 自寫 GBK 版 PHP 匯入腳本：SET NAMES gbk 後執行 SQL。
3. 匯入後在應用層 iconv('UTF-8','GBK',...) 反向修正 (治標不治本)。

MySQL 4.1+ 字元集系統變數速查

小結

字元集問題 90% 來自「連線字元集與資料實際編碼不符」。新專案強制統一 UTF-8 (utf8mb4)：檔案、資料庫、連線、HTML 標頭、HTTP Header 全鏈路 UTF-8，即可徹底杜絕亂碼。舊專案遷移請參照「MySQL 4.1 字元集升級遷移指南」。