前言

MySQL 中文亂碼是經典議題。本文從字元集轉換流程、關鍵變數、實測步驟三個層面，系統性說明亂碼成因與解決之道。

一、字元集轉換五階段

MySQL 為 Client-Server 架構，每次操作經歷：

1. Client 端編碼：如 cmd 預設 GBK、Notepad++ 預設 UTF-8。
2. character_set_client：Client 送出請求前轉換為此字元集。
3. character_set_connection：傳輸過程中轉換為連線字元集。
4. 儲存層字元集：依優先序 character_set_server → character_set_database → 表 → 欄位繼承。
5. character_set_results：查詢結果轉換為此字元集回傳 Client。

Client 端顯示工具需支援對應編碼（如 SecureCRT 可手動切換 UTF-8/GBK）。

二、關鍵變數與繼承關係

character_set_server 
  ⇒ character_set_database 
    ⇒ table charset 
      ⇒ column charset

• 安裝精靈選擇 UTF-8 時，上述變數多預設為 UTF-8。
• 非安裝版（免安裝包）需手動修改 my.ini 指定 character_set_server。
• 其他變數：character_set_filesystem（檔案系統轉換，預設 binary）、character_set_system（永遠 UTF-8，存系統元資料）、character_set_dir（字元集定義檔目錄）。

三、常見編碼轉換相容性

• 同質轉換無損：GBK→GBK、UTF-8→UTF-8、Latin1→Latin1。
• 多位元→單位元（Latin1）無損：GBK→Latin1、UTF-8→Latin1。Latin1 覆蓋 0x00-0xFF，可完整保存任意位元組序列。
• Latin1→多位元可能損壞：Latin1→GBK（特殊中文）、Latin1→UTF-8（位元組長度變化）。

實務啟示：若欄位字元集為 Latin1，實際儲存內容可能是任意編碼；若為 UTF-8/GBK，則應對應該編碼，否則資料已損壞無法還原。

四、實測驗證流程（以 cmd GBK 環境為例）

1. 設定三個連線變數為 Latin1：SET NAMES latin1;（等同設定 client/connection/results）。
2. 建立資料庫/表/欄位皆指定 Latin1。
3. 在 GBK 的 cmd 下 INSERT 中文，SELECT 顯示正常。
4. 原理：GBK 位元組序列 → Latin1 儲存（無損） → Latin1 讀出 → GBK cmd 正確解碼顯示。

五、生產環境建議

• 全鏈路統一 UTF-8（SET NAMES utf8mb4、資料庫/表/欄位 utf8mb4、連線字串 charset=utf8mb4）。
• 避免混用編碼；若歷史資料為 Latin1 儲存 GBK/UTF-8，讀取時需對應解碼。
• 參考測試文章：常用字元集轉換測試對照。