MySQL 4.1 字元集亂碼終極解決方案：GBK/UTF-8 混存正確顯示

核心問題

MySQL 4.1 引入字元集支援，但預設連線字元集與資料表字元集不一致會導致：

• 中文存入正常，查詢顯示亂碼
• 排序比對錯誤
• 應用層需額外處理

最佳實踐：資料表層面指定字元集

CREATE TABLE t (
    id INT PRIMARY KEY,
    name CHAR(50) CHARACTER SET gbk,  -- 文字欄位明確指定 GBK
    note TEXT CHARACTER SET utf8      -- 也可混用 UTF-8
) DEFAULT CHARACTER SET gbk;

既有資料表轉換字元集

-- 兩步走：先轉 BINARY 再轉目標字元集（避免資料損壞）
ALTER TABLE t MODIFY col_name BINARY(100);
ALTER TABLE t MODIFY col_name CHAR(100) CHARACTER SET gbk;

關鍵：查詢前設定連線字元集

不需修改 my.cnf，在每次連線建立後、執行查詢前送出：

SET character_set_results = NULL;
-- 或明確指定
SET NAMES gbk;  -- 等同於設定 client/connection/results 皆為 gbk

這行指令讓 MySQL 不做字元集轉換，直接回傳儲存時的原始位元組，無論欄位是否已轉換字元集，中文都能正確顯示，且已轉換的欄位仍能正確中文排序。

為什麼不建議改 my.cnf？

[mysqld]
default-character-set=gbk

會導致未轉換字元集的舊欄位同樣被當作 GBK 解碼，產生新亂碼。連線層面動態設定最靈活、相容性最好。

應用層整合範例

PHP：

mysql_query("SET NAMES gbk", $link);
// 或 PDO
$pdo->exec("SET NAMES gbk");

Java (JDBC URL)：

jdbc:mysql://localhost/db?useUnicode=true&characterEncoding=gbk

.NET (Connector/Net)：

string connStr = "server=localhost;database=db;charset=gbk;";

驗證字元集狀態

SHOW VARIABLES LIKE 'character_set_%';
-- 關鍵變數：
-- character_set_client      客戶端發送編碼
-- character_set_connection  連線層轉換目標編碼
-- character_set_results     回傳給客戶端編碼
-- character_set_database    當前資料庫預設編碼
-- character_set_server      伺服器預設編碼

遷移到 UTF-8 建議

• 新專案直接採用 utf8mb4（支援 Emoji）
• 舊專案逐表轉換：ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
• 確保應用層、連線池、驅動程式皆支援 utf8mb4