MySQL 4.1 字元集機制深度解析與 WordPress 亂碼終極解決方案

背景：為什麼會出現亂碼？

MySQL 4.1 引入多層級字元集設定（伺服器、資料庫、資料表、欄位），但許多 PHP 程式（如 WordPress）未區分版本差異，且預設字元集 latin1 掩蓋了中文環境下的問題。

字元集傳遞鏈路

1. 編譯/配置/啟動參數決定 character_set_server（預設 latin1，安裝常改為 utf8）。
2. 建庫預設繼承 character_set_server → character_set_database。
3. 建表繼承資料庫預設 → 表預設字元集。
4. 建欄位繼承表預設 → 實際儲存編碼。
5. 客戶端連線需指定 character_set_client（發送編碼），MySQL 先轉為 character_set_connection，再轉為資料庫預設編碼儲存（兩次轉換）。
6. 讀取時：資料庫編碼 → character_set_results 輸出給客戶端。

典型錯誤場景（WordPress + MySQL 4.1 + UTF-8）

• WP 以 UTF-8 送資料，MySQL 預設 client=latin1, connection=latin1，導致「UTF-8 被當 latin1 轉 latin1 再轉 utf8」，字元遺失變 ??。
• WP 設瀏覽編碼為 GB2312 時，資料經「GB2312 當 latin1 轉 latin1 存儲」，讀出時若設 results=latin1 反而正常顯示，但實際儲存為亂碼，遷移極其危險。

解決方案：SET NAMES 'utf8'

SET NAMES 'utf8' 等同於：

SET character_set_client = 'utf8';
SET character_set_connection = 'utf8';
SET character_set_results = 'utf8';

若客戶端送 GB2312，可設：

SET character_set_client = 'gb2312';
SET character_set_connection = 'utf8';  -- 或 gb2312
SET character_set_results = 'gb2312';

WordPress 修改建議

在 wp-includes/wp-db.php 加入：

function set_charset($charset) {
    $serverVersion = mysql_get_server_info($this->dbh);
    $version = explode('.', $serverVersion);
    if ($version[0] < 4) return;
    $result = mysql_query("SHOW CHARACTER SET LIKE 'utf8'", $this->dbh);
    if (mysql_num_rows($result) <= 0) return;
    if ($charset == 'utf-8' || $charset == 'UTF-8') $charset = 'utf8';
    @mysql_query("SET NAMES '$charset'", $this->dbh);
}

在 wp-settings.php 載入變數後呼叫：

$wpdb->set_charset(get_bloginfo('charset'));

僅連線時執行一次，避免每查詢重複設定。

總結

掌握字元集傳遞鏈路，連線建立即執行 SET NAMES，即可徹底解決 MySQL 4.1+ 環境下的中文亂碼問題。