MySQL 編碼問題經驗總結：前端編碼決定存儲編碼，iconv 跨編碼讀寫實戰

核心鐵律

**你寫入時用什麼編碼，讀出來就是什麼編碼。** MySQL 4.1+ **不會** 自動轉換你的資料編碼，只會按連線字元集解析、按欄位字元集存儲。

場景驗證

常見坑：phpMyAdmin 導入亂碼

• phpMyAdmin 介面為 UTF-8 編碼 → 導入檔案按 UTF-8 解析 → 存入資料庫為 UTF-8。
• 你的應用為 GB2312 讀取 → **亂碼**。

解決三板斧

1. 讀取前執行 SET NAMES GB2312 (或 SET CHARACTER SET GBK) 強制連線字元集。
2. 讀取後 iconv('UTF-8', 'GB2312', $str) 轉碼顯示。
3. **根治**：自己寫 GB2312 編碼的 PHP 匯入腳本，不用 phpMyAdmin。

跨編碼讀寫最佳實踐

// 統一專案編碼為 UTF-8 (含 PHP 檔案、HTML 頁面、資料庫連線)
// 若必須對接 GB2312 系統：
// 寫入
$sql = "INSERT INTO t(c) VALUES ('" . iconv('UTF-8', 'GB2312//IGNORE', $str) . "')";
// 讀取
$str = iconv('GB2312', 'UTF-8//IGNORE', $row['c']);

• //IGNORE 忽略無法轉換字元，避免報錯中斷。
• 資料庫欄位建議 CHARSET=utf8mb4 統一存儲，應用層負責轉碼。

總結

1. **前端編碼 = 存儲編碼** (若連線字元集匹配)。
2. **統一專案 UTF-8** 是唯一長久之計。
3. 跨系統整合時，**邊界處做 iconv 轉碼**，資料庫內部保持單一編碼。
4. 不要指望 MySQL 幫你自動轉碼，它只忠實執行「按連線字元集解析 → 按欄位字元集存儲」。