解決 MySQL 客戶端輸出視窗中文亂碼：字符集診斷與動態切換實戰

在 Windows CMD 下使用 MySQL 客戶端查詢中文資料時，常見亂碼現象。根因是客戶端輸出視窗字符集（character_set_results）與作業系統預設編碼（中文 Windows 為 GBK/CP936）不匹配。本文提供診斷指令、臨時切換方案、永久配置建議，並解釋為何 utf8 在此場景下反而導致亂碼。

一、現象重現

查詢含中文欄位的表：

SELECT * FROM user_info;

輸出中文欄位顯示為亂碼（如 ???、涓婂競 等）。

二、診斷字符集現狀

SHOW VARIABLES LIKE 'char%';

典型輸出：

+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | utf8                       |
| character_set_connection | utf8                       |
| character_set_database   | utf8                       |
| character_set_filesystem | binary                     |
| character_set_results    | utf8     ← 關鍵：輸出視窗編碼 |
| character_set_server     | utf8                       |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+

結論： 伺服器端全為 utf8，但 Windows CMD 預設代碼頁為 936 (GBK)，無法正確渲染 UTF-8 位元組流，故顯示亂碼。

三、臨時解決方案（當前會話生效）

SET character_set_results = gbk;

或完整設定三件套：

SET NAMES gbk;

效果： 立即生效，重新查詢中文正常顯示。缺點：重新連線失效。

四、永久解決方案（配置檔）

修改 my.ini [mysql] 區段（客戶端工具預設）：

[mysql]
default-character-set = gbk

或在 [client] 區段設定（影響所有客戶端連接）：

[client]
default-character-set = gbk

重啟 MySQL 服務或重新開啟客戶端生效。

五、為什麼不建議在 CMD 下用 utf8？

• Windows Console 歷史架構限制，預設代碼頁 936（GBK），支援 UTF-8 需執行 chcp 65001 且字型設為 TrueType（如 Consolas、NSimSun），且仍有游標定位、選取複製等已知 Bug。
• 生產環境應用程式（Java、Python、Go）透過 JDBC/驅動連接，應在連接字串指定 characterEncoding=utf8，由驅動自動轉碼，不依賴客戶端視窗編碼。
• 若堅持在 CMD 使用 UTF-8：
  1. chcp 65001
  2. 視窗屬性 → 字型 → 選 Consolas 或 NSimSun
  3. SET NAMES utf8 或配置檔設 default-character-set=utf8

六、最佳實踐建議

七、總結

MySQL 客戶端視窗亂碼本質是「輸出編碼（character_set_results）與終端機渲染編碼不匹配」。Windows CMD 下最簡單有效的方案是將客戶端輸出設為 gbk；應用程式層面統一使用 utf8mb4 並在連接參數顯式指定編碼。切勿混淆「存儲編碼」與「傳輸/顯示編碼」兩個層面。