MySQL 字符集 GBK、GB2312、UTF8 區別與中文亂碼徹底解決

字符集族系關係

GB2312 (6763漢字) ⊂ GBK (21000+漢字+日韓) ⊂ GB18030 (國家標準，含少數民族字)
UTF-8 (Unicode 實現) ⊃ 世界所有字符

編碼方式對比

MySQL 字符集層級優先級

Server (character-set-server)
    ↓ 默認
Database (CREATE DATABASE ... CHARSET=...)
    ↓ 默認
Table (CREATE TABLE ... CHARSET=...)
    ↓ 默認
Column (COLUMN ... CHARSET=...)
    ↓ 最高優先級
Connection (SET NAMES / character_set_client/connection/results)

亂碼根因與解決三步曲

步驟 1：統一連接層編碼

-- 方案 A：SQL 執行前
SET NAMES gbk;  -- 或 utf8 / utf8mb4

-- 方案 B：JDBC URL
jdbc:mysql://host:3306/db?useUnicode=true&characterEncoding=UTF-8

-- 方案 C：配置文件 [client] 區
default-character-set = utf8mb4

步驟 2：統一存儲層編碼

-- 新建庫表指定
CREATE DATABASE db_name CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE TABLE t(...) CHARSET=utf8mb4;

-- 現有表轉換
ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

步驟 3：統一展示層編碼

-- HTML

-- HTTP Header
Content-Type: text/html; charset=utf-8
-- JSP
<%@ page contentType="text/html;charset=UTF-8" %>

為什麼命令行不設置也能「正常」顯示？

客戶端編碼 = 連接編碼 = 結果編碼 = 終端編碼（如 GBK），寫入經 GBK→Latin1→UTF8 錯誤鏈路存儲，讀出走反向錯誤鏈路「剛好」還原。**實際存儲已是亂碼**，換客戶端即暴露。

轉碼鏈路：必經 Unicode

GBK/GB2312 → Unicode → UTF-8
UTF-8 → Unicode → GBK/GB2312

MySQL 內部以 Unicode 為中介，跨字符集操作自動轉換。

避坑清單

• ❌ SET NAMES utf8 卻用 utf8mb4 表存 Emoji → 截斷報錯
• ❌ mysqldump 無 --default-character-set 導出亂碼
• ❌ 連接池未設置 characterEncoding，首次獲取連接亂碼
• ✅ 新項目**統一 utf8mb4**，全鏈路一致
• ✅ 遷移舊庫用 pt-online-schema-change 零停機轉碼