MySQL 4.1 編碼亂碼根因分析與最佳實踐配置指南

為什麼 MySQL 4.1 編碼問題頻發？

MySQL 4.1 引入了多層級字符集支持（服務器、數據庫、表、列），但眾多 PHP 應用（如 WordPress）未區分版本差異，且 latin1 作為默認字符集掩蓋了中文環境下的潛在問題。主要成因有四：

1. MySQL 4.1 字符集架構大幅變更，舊應用未適配。
2. 生產環境仍大量運行 MySQL 3.x，開發測試與線上不一致。
3. PHP 程序籠統要求「MySQL 3.23 以上」，忽略 4.1 獨特配置需求。
4. latin1 默認編碼在單字節西文環境下無感，卻導致多字節中文存儲與讀取不一致。

MySQL 4.1 字符集配置層級與繼承鏈

字符集可分別在四個層級指定，優先級由高到低：

1. 列級別：ALTER TABLE t MODIFY c VARCHAR(10) CHARSET utf8
2. 表級別：CREATE TABLE t (...) DEFAULT CHARSET utf8
3. 數據庫級別：CREATE DATABASE db DEFAULT CHARSET utf8
4. 服務器級別：編譯時指定 → my.ini default-character-set → 啟動參數 --default-character-set

若低層級未顯式指定，則向上繼承。理解此繼承鏈是排查亂碼的關鍵。

連接層編碼：最關鍵的 SET NAMES

客戶端與服務器交互時，必須聲明三個連接變量：

• character_set_client：客戶端發送數據編碼
• character_set_connection：服務器接收後轉換目標編碼
• character_set_results：服務器返回結果編碼

簡寫命令：SET NAMES 'utf8' 等同於同時設置以上三者為 UTF-8。此語句必須在建立連接後、執行任何查詢前立即執行。

PHP 應用最佳實踐配置清單

1. my.cnf / my.ini 服務端配置

[mysqld]
default-character-set = utf8
character-set-server = utf8
collation-server = utf8_general_ci
init_connect = 'SET NAMES utf8'

2. PHP 連接代碼規範

$mysqli = new mysqli('localhost', 'user', 'pass', 'db');
$mysqli->set_charset('utf8'); // 推薦 mysqli 面向對象方式
// 或 PDO
$pdo = new PDO('mysql:host=localhost;dbname=db;charset=utf8', 'user', 'pass');

3. 數據庫/表創建時顯式指定

CREATE DATABASE mydb DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE TABLE mytable (
    id INT PRIMARY KEY,
    name VARCHAR(50)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

常見亂碼現象與排查步驟

總結

MySQL 4.1 編碼問題本質是「配置不一致」導致的編碼轉換錯誤。解決核心在於：服務端默認 UTF-8、連接層強制 SET NAMES utf8、建表顯式指定 CHARSET、應用層統一 UTF-8。建立標準化部署清單，可徹底杜絕亂碼困擾。