用户昵称带个 emoji 就插入数据库失败、报 Incorrect string value,我数据库明明设的是 utf8 字符集,我对着 MySQL 的"假 utf8"排查了大半天的复盘
那是我做的一个用户系统。一切正常,直到有用户在昵称里加了个 emoji(比如 😀)。保存的瞬间,接口就报错了:java.sql.SQLException: Incorrect string value: '\xF0\x9F\x98\x80' for column 'nickname'。我一脸困惑:我的数据库字符集明明设的是 utf8 啊!UTF-8 不是号称能编码世界上所有字符吗?怎么连一个小小的 emoji 都存不下?我反复确认了表的字符集就是 utf8、连接也是 utf8。排查了大半天,我才得知一个让我大跌眼镜的真相:MySQL 里的 utf8,根本不是真正的、完整的 UTF-8——它是个"残废版"。这篇就把这场"假 utf8 存不下 emoji"的事故,从头复盘一遍。
故障现场:utf8 却存不下 emoji
先看现场。明明设了 utf8,emoji 却插不进去:
-- 我的表: 字符集设的是 utf8
CREATE TABLE users (
id INT PRIMARY KEY,
nickname VARCHAR(50)
) CHARACTER SET utf8; -- ← 我以为这就够了
-- 插入带 emoji 的昵称:
INSERT INTO users VALUES (1, '小明😀');
-- ✗ 报错:
-- ERROR 1366 (HY000): Incorrect string value: '\xF0\x9F\x98\x80'
-- for column 'nickname' at row 1
-- 为什么? MySQL 的 "utf8" 是个历史遗留的"假 UTF-8":
-- - 真正的 UTF-8: 是变长编码, 一个字符用 1~4 个字节。
-- * 基本字符(英文、常用汉字): 1~3 字节。
-- * emoji、部分生僻字、某些特殊符号: 需要 4 个字节!
-- - 但 MySQL 的 "utf8"(全称 utf8mb3): 最多只支持【3 个字节】!
-- * mb3 = max bytes 3, 它根本存不下需要 4 字节的字符(如 emoji)。
-- * 这是 MySQL 早期的历史错误: 当年实现 utf8 时只做了 3 字节,
-- 后来为了向后兼容, "utf8" 这个名字就一直是这个"残废版"。
-- - 而真正完整的 UTF-8, 在 MySQL 里叫 utf8mb4(max bytes 4):
-- * 它支持 1~4 字节, 才是真正的、完整的 UTF-8, 能存 emoji。
-- 现象拼图:
-- - emoji '😀' 的 UTF-8 编码是 F0 9F 98 80, 占【4 个字节】。
-- - 我的列是 utf8(=utf8mb3), 最多 3 字节, 装不下 4 字节的 emoji。
-- - 插入时 MySQL 发现"这个字符超过3字节、我存不了" → 报 Incorrect string value。
-- - ★ 根因: MySQL 的 "utf8" 名不副实, 它只是 utf8mb3(残废版),
-- 真正的 UTF-8 是 utf8mb4。我被这个误导性的名字坑了。
看到 emoji 的编码是 4 个字节、而 MySQL 的 utf8 最多只支持 3 字节时,我又好气又好笑。问题的根源,是 MySQL 里的 utf8 名不副实——它的全称是 utf8mb3(max bytes 3),最多只支持 3 个字节,根本不是真正完整的 UTF-8。而真正的 UTF-8 是变长编码:基本字符(英文、常用汉字)用 1~3 字节,但 emoji、部分生僻字、某些特殊符号需要 4 个字节。emoji 😀 的 UTF-8 编码是 F0 9F 98 80、占 4 字节,而我的列是 utf8(=utf8mb3)最多 3 字节、装不下,插入时 MySQL 发现存不了就报 Incorrect string value。这是 MySQL 早期的历史错误:当年实现 utf8 时只做了 3 字节,后来为了向后兼容,"utf8"这个名字就一直是这个"残废版";真正完整的 UTF-8 在 MySQL 里叫 utf8mb4(max bytes 4),支持 1~4 字节、能存 emoji。我就是被这个误导性的名字坑了。
第一件事:搞懂 utf8mb3 和 utf8mb4 的区别
要解决它,得先彻底搞懂 MySQL 的字符集,以及 UTF-8 编码的本质。
MySQL 字符集: utf8(mb3) vs utf8mb4
# 一、UTF-8 是变长编码: 一个字符 1~4 字节
# - ASCII(英文、数字): 1 字节
# - 大部分常用字符(含常用汉字): 2~3 字节
# - emoji、部分生僻汉字(如𠮷)、部分特殊符号: 4 字节
# → 完整的 UTF-8 必须支持到 4 字节。
# 二、MySQL 的两个"utf8":
# - utf8 / utf8mb3: 最多 3 字节! 存不下 4 字节字符(emoji等)。
# 这是历史遗留的"残废版", 但名字偏偏就叫 "utf8"(误导!)。
# - utf8mb4: 最多 4 字节, 才是【真正完整的 UTF-8】。能存一切, 包括 emoji。
# 三、所以结论很简单:
# - 永远用 utf8mb4, 别用 utf8(=utf8mb3)!
# - 现在新建库表, 字符集一律选 utf8mb4。
# - MySQL 8.0 起, 默认字符集已经改成了 utf8mb4(终于纠正了)。
# 但很多老库、老配置、或手动设了 utf8 的, 仍是 mb3, 要小心。
# 四、字符集 + 排序规则(collation):
# - 字符集(charset): 用什么编码存(utf8mb4)。
# - 排序规则(collation): 怎么比较/排序字符(影响 = 比较、ORDER BY、大小写)。
# * utf8mb4_general_ci: 老的, 快但不够准。
# * utf8mb4_unicode_ci: 更准的 Unicode 排序。
# * utf8mb4_0900_ai_ci: MySQL8 默认, 基于Unicode 9.0, 推荐。
# - 设字符集时, 通常一起设排序规则。
# 核心: UTF-8是1~4字节变长编码, emoji需4字节; MySQL的utf8其实是utf8mb3(最多3字节)存不下emoji,
# utf8mb4才是真正完整的UTF-8; 永远用utf8mb4; MySQL8默认已是utf8mb4但老库要检查。
想透 UTF-8 编码和 MySQL 字符集,这个坑就清楚了。一、UTF-8 是变长编码:ASCII 1 字节、大部分常用字符 2~3 字节,而 emoji、部分生僻汉字(如𠮷)、特殊符号需要 4 字节;完整的 UTF-8 必须支持到 4 字节。二、MySQL 的两个"utf8":utf8/utf8mb3 最多 3 字节(存不下 4 字节字符,历史遗留的残废版,名字却叫 utf8);utf8mb4 最多 4 字节,才是真正完整的 UTF-8、能存一切。三、结论很简单:永远用 utf8mb4,别用 utf8;新建库表字符集一律选 utf8mb4;MySQL 8.0 起默认字符集已改成 utf8mb4(终于纠正),但很多老库/老配置仍是 mb3 要小心。四、字符集 + 排序规则(collation):字符集是用什么编码存(utf8mb4),排序规则是怎么比较/排序(utf8mb4_0900_ai_ci 是 MySQL8 默认、推荐),设字符集时通常一起设排序规则。
第二件事:正解——全链路都改成 utf8mb4
搞懂了原理,正解就清晰了:把数据库、表、列、连接、客户端全链路都改成 utf8mb4,任何一环漏了都可能出问题。
-- ====== 正解一: 新建库表一律用 utf8mb4 ======
CREATE DATABASE mydb
CHARACTER SET utf8mb4
COLLATE utf8mb4_0900_ai_ci; -- MySQL8 推荐的排序规则
CREATE TABLE users (
id INT PRIMARY KEY,
nickname VARCHAR(50)
) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
-- ====== 正解二: 已有的库/表/列, 改成 utf8mb4 ======
-- 改库(只影响之后新建的表):
ALTER DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
-- 改表(会改表里所有列, 注意大表操作耗时/锁):
ALTER TABLE users CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
-- 改单列:
ALTER TABLE users MODIFY nickname VARCHAR(50)
CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
-- ====== 正解三(关键!): 连接字符集也要是 utf8mb4 ======
-- 光改表不够! "客户端 ↔ 服务器"的连接, 也必须用 utf8mb4 传输,
-- 否则 emoji 在传输环节就被"转换坏了"。检查并设置这几个变量:
SHOW VARIABLES LIKE 'character_set%';
SET NAMES utf8mb4; -- 一次性设置连接相关的字符集为 utf8mb4
各语言/框架的连接也要配 utf8mb4(这是最容易漏的一环):
# ====== 各语言/框架连接配置 utf8mb4 ======
# JDBC URL(Java):
# jdbc:mysql://host:3306/mydb?useUnicode=true&characterEncoding=utf8mb4
# (较新驱动: characterEncoding=UTF-8 + 连接默认即可, 但确认服务端是mb4)
# Python (PyMySQL / mysqlclient):
# pymysql.connect(..., charset='utf8mb4')
# Node.js (mysql2):
# createConnection({ ..., charset: 'utf8mb4' })
# Go (go-sql-driver):
# dsn: "user:pass@tcp(host)/db?charset=utf8mb4"
# my.cnf (MySQL 服务端默认, 一劳永逸):
# [mysqld]
# character-set-server=utf8mb4
# collation-server=utf8mb4_0900_ai_ci
# [client]
# default-character-set=utf8mb4
# ★ 完整链路(任何一环是mb3/非mb4都可能出问题):
# 客户端字符集 → 连接字符集 → 数据库 → 表 → 列, 全部 utf8mb4!
# (常见漏点: 表改了, 但连接还是utf8; 或库改了, 但老表没改。)
# ====== 验证: 插入 emoji 看能不能成功 + 读出来对不对 ======
# INSERT INTO users VALUES (2, '测试😀🎉'); → 应成功
# SELECT nickname FROM users WHERE id=2; → 应正确显示 emoji
# 核心: 全链路改 utf8mb4 —— 库/表/列(CONVERT TO)+ 连接(SET NAMES/驱动charset)
# + 服务端my.cnf; 任何一环漏了都可能出问题; 改完插emoji验证读写都正确。
修复的核心,是"把从客户端到列的整条链路,全部统一成 utf8mb4,一环都不能漏"。正解一:新建库表一律用 utf8mb4(配 utf8mb4_0900_ai_ci 排序规则)。正解二:已有的库/表/列改成 utf8mb4——改库(ALTER DATABASE,只影响之后新建的表)、改表(ALTER TABLE ... CONVERT TO,会改所有列,大表注意耗时/锁)、改单列(MODIFY)。正解三(关键!):连接字符集也要是 utf8mb4——光改表不够!客户端↔服务器的连接也必须用 utf8mb4 传输,否则 emoji 在传输环节就被转换坏了;SET NAMES utf8mb4,各语言驱动也要配 charset=utf8mb4。完整链路是:客户端字符集 → 连接字符集 → 数据库 → 表 → 列,全部 utf8mb4;任何一环是 mb3/非 mb4 都可能出问题(常见漏点:表改了但连接还是 utf8、或库改了但老表没改)。最后改完插 emoji 验证读写都正确。归根结底:全链路改 utf8mb4(库/表/列 + 连接 + 服务端 my.cnf),一环不漏,改完验证。
第三件事:utf8mb4 的几个注意点
改 utf8mb4 虽好,但有几个细节坑,我也一并梳理了。
utf8mb4 的注意点
# 1. 索引长度限制(老版本MySQL的坑)
# - 索引键有最大字节数限制。utf8(mb3)下 1字符=3字节, utf8mb4=4字节。
# - 老版本(5.6及更早) InnoDB 索引前缀默认上限 767 字节:
# * utf8: VARCHAR(255) → 255*3=765 < 767, 能建索引。
# * utf8mb4: VARCHAR(255) → 255*4=1020 > 767, 建索引可能报错!
# - 解法: 开启 innodb_large_prefix(5.7+默认开, 上限3072字节);
# 或把建索引的列长度改短(如 VARCHAR(191), 191*4=764<767)。
# - MySQL 5.7+ / 8.0 基本无此问题, 但迁移老库要注意。
# 2. 存储空间略增
# - utf8mb4 每字符最多4字节(vs mb3的3字节)。
# - 但实际: 英文/数字仍1字节, 常用汉字仍3字节, 只有emoji等才4字节。
# - 所以实际存储增长很小, 别因噎废食(为省那点空间用mb3, 不值)。
# 3. 改表 CONVERT TO 是重操作
# - 大表 ALTER ... CONVERT TO 会重建表、耗时、可能锁表。
# - 生产大表: 低峰期操作, 或用 pt-online-schema-change/gh-ost 在线改。
# 4. 别只改一半
# - 最常见的坑: 改了表/列, 忘了改连接(SET NAMES)→ 还是存不下/乱码。
# - 或: 默认字符集改了, 但已存在的旧表没改 → 旧表还是mb3。
# - 一定全链路检查: SHOW CREATE TABLE 看每张表、SHOW VARIABLES看连接。
# 核心: utf8mb4注意 老版本索引长度限制(VARCHAR(191)或开large_prefix)、存储略增(可忽略)、
# 大表CONVERT是重操作(低峰期/在线改)、别只改一半(连接和旧表都要改)。
改 utf8mb4 虽是正解,但有几个细节要注意。一、索引长度限制(老版本坑)——索引键有最大字节数限制,utf8mb4 每字符 4 字节,老版本(5.6 及更早)InnoDB 索引前缀上限 767 字节,utf8mb4 VARCHAR(255) = 1020 > 767 建索引可能报错;解法是开 innodb_large_prefix(5.7+ 默认开)或把列改短(VARCHAR(191));MySQL 5.7+/8.0 基本无此问题但迁移老库要注意。二、存储空间略增——但英文/数字仍 1 字节、常用汉字仍 3 字节,只有 emoji 才 4 字节,实际增长很小,别为省空间用 mb3。三、改表 CONVERT TO 是重操作——大表会重建表、耗时、可能锁表,生产大表低峰期操作或用 pt-online-schema-change/gh-ost 在线改。四、别只改一半——最常见的坑是改了表忘了改连接、或默认改了但旧表没改;一定全链路检查(SHOW CREATE TABLE 看每张表、SHOW VARIABLES 看连接)。下面这张图,是这次 utf8 存不下 emoji 的成因与解法:
第四件事:utf8 vs utf8mb4 对比速查
这次踩坑后,我把两者的区别整理成一张表,以后建库表一眼就知道选哪个。
| 维度 | utf8(=utf8mb3) | utf8mb4 |
|---|---|---|
| 最大字节/字符 | 3 字节 | 4 字节 |
| 能存 emoji 吗 | ✗ 不能 | ✓ 能 |
| 能存 4 字节生僻字吗 | ✗ 不能(如 𠮷) | ✓ 能 |
| 是真正的 UTF-8 吗 | ✗ 残废版 | ✓ 是 |
| 存储(英文/常用汉字) | 1~3 字节 | 1~3 字节(一样) |
| MySQL8 默认 | 否 | ✓ 是 |
| 推荐用吗 | ✗ 别用 | ✓ 永远用它 |
这张表,把 utf8 和 utf8mb4 的区别钉死了:结论就一句——永远用 utf8mb4,别用 utf8。它给我的最大启发,其实是关于"命名"的:MySQL 把一个"残废的、只支持 3 字节的编码"命名为 utf8,把"真正完整的 UTF-8"命名为 utf8mb4——这是一个糟糕到能坑死人的命名。因为"utf8"这个名字,会让任何一个有常识的程序员,理所当然地以为它就是标准的、完整的 UTF-8(谁能想到它是残废版?);这种"名字和实际行为不符"的命名,本身就是一个巨大的陷阱。它让我领悟到一个关于命名、也关于使用工具的道理:"名字"是我们理解一个事物的第一入口,我们会下意识地根据名字去推断它的行为;而当一个名字"名不副实"时(utf8 不是完整 UTF-8、Arrays.asList 不是 ArrayList),它就会把我们的直觉引向错误的方向。所以,这件事给我的实用警示是:对于那些"名字听起来理所当然"的东西,尤其是底层的、关键的配置(字符集、编码、时区),不能只凭名字想当然,而要真正搞清楚它的确切含义和行为边界;有时候,一个看似无害的名字背后,藏着一个能让你排查半天的坑。
第五件事:字符编码的其他常见坑
字符集只是字符编码这个大主题里的一个坑,它还有几个常见陷阱,我一并梳理了。
| 坑 | 现象 | 对策 |
|---|---|---|
| MySQL utf8 存不下emoji | Incorrect string value(本文) | 用 utf8mb4 |
| 连接字符集不一致 | 存进去/读出来乱码 | 连接也设 utf8mb4 |
| 文件读写编码不指定 | 不同平台默认编码不同,乱码 | 显式指定 UTF-8 |
| URL/HTTP 编码 | 中文参数乱码 | URLEncode + 统一 UTF-8 |
| BOM 头 | 文件开头多出隐藏字符 | 用 UTF-8 无 BOM |
| 字符串长度按字节算 | 截断中文/emoji成乱码 | 按字符(码点)算,注意emoji是多码点 |
这张表,把字符编码的"坑系列"列了出来。它们的共同根源,是一个常被忽略的事实:"文本"在计算机里,从来不是直接存储的,而是要先用某种"编码"转换成字节;而"用什么编码存、用什么编码读"必须一致,任何一个环节的编码不一致,就会产生乱码或错误。它给我的最大启发是:"字符编码"是一个被几乎所有程序员"每天都在用、却很少真正理解"的基础概念;我们平时写 "你好"、读个文件、调个接口,背后都有"字符 ↔ 字节"的编码转换在默默发生,只是大部分时候平台默认配置恰好一致,我们没出事、也就没在意。可一旦遇到跨平台、跨系统、特殊字符(emoji)、或像 MySQL utf8 这种"名不副实的配置"时,这个被忽略的基础就会反噬。这让我对"编码"多了一份敬畏,也总结出一条实用原则:在整个系统里,统一、显式地使用 UTF-8(数据库 utf8mb4、文件 UTF-8、接口 UTF-8、代码文件 UTF-8),并在每一个"字符 ↔ 字节"转换的边界处,都明确指定编码、绝不依赖平台默认。"全链路统一 UTF-8、处处显式指定"——这是避开绝大多数编码坑的、最朴素也最有效的纪律。
第六件事:建库表/处理文本时,我现在的习惯
现在每当我建数据库、处理文本,我都会按这张图把字符编码这一关把好:
这张图的精髓,是"建库和处理文本时,把字符编码全链路统一成 UTF-8/utf8mb4"。数据库侧:字符集一律 utf8mb4、配套排序规则、连接也设 utf8mb4、服务端 my.cnf 也设。老库要特别检查每张表(SHOW CREATE TABLE),旧表 CONVERT TO utf8mb4(别漏)。文本侧:文件读写、接口都显式指定 UTF-8。最后用 emoji 和生僻字验证读写都正确(这次的坑正是因为测试时没用 emoji 测过)。这套习惯,让我处理编码时,从"用默认的 utf8 想当然"变成了"全链路统一 utf8mb4 并验证"——核心始终是:MySQL 用 utf8mb4(不是 utf8),全链路统一 UTF-8,用特殊字符验证。
我立下的几条规矩
这场"假 utf8 存不下 emoji"的事故,换来了我做数据库/文本处理时,刻进骨子里的几条铁律:
- MySQL 永远用 utf8mb4,别用 utf8。utf8 是残废的 utf8mb3、最多 3 字节,存不下 emoji。
- utf8mb4 才是真正完整的 UTF-8。支持 1~4 字节,能存 emoji 和 4 字节生僻字。
- 全链路都要 utf8mb4。库/表/列 + 连接 + 服务端,任何一环漏了都可能出问题。
- 连接字符集最容易漏。光改表不够,SET NAMES utf8mb4 / 驱动 charset 也要配。
- 老库迁移注意索引长度。老版本 utf8mb4 VARCHAR(255) 可能超索引前缀上限,用 191 或开 large_prefix。
- 别被名字误导。utf8 名不副实;关键配置要搞清确切含义,别凭名字想当然。
- 测试要用 emoji/生僻字。别只测普通字符,要测 4 字节字符验证编码全链路。
附:一套排查并修复字符集的完整 SQL
口说无凭。下面给一套可直接用的 SQL:从排查现状,到全链路修复,到验证,一步步走:
-- ============ 第一步: 排查现状, 找出哪些不是 utf8mb4 ============
-- 1. 看连接相关的字符集变量(常见漏点!)
SHOW VARIABLES LIKE 'character_set%';
-- 重点看: character_set_client / connection / results 是不是 utf8mb4
-- 2. 看每个库的默认字符集
SELECT SCHEMA_NAME, DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME
FROM information_schema.SCHEMATA;
-- 3. 看每张表的字符集(找出还是 utf8/utf8mb3 的表)
SELECT TABLE_NAME, TABLE_COLLATION
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'mydb' AND TABLE_COLLATION NOT LIKE 'utf8mb4%';
-- 4. 看每个列的字符集(列也可能单独设了 utf8mb3!)
SELECT TABLE_NAME, COLUMN_NAME, CHARACTER_SET_NAME, COLLATION_NAME
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'mydb'
AND CHARACTER_SET_NAME IS NOT NULL
AND CHARACTER_SET_NAME != 'utf8mb4';
-- ============ 第二步: 全链路修复 ============
-- 5. 改库默认(影响之后新建的表)
ALTER DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
-- 6. 改每张存量表(把 information_schema 查出的表逐个改)
ALTER TABLE users CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
-- (大表生产环境: 用 pt-online-schema-change 或 gh-ost 在线改, 避免锁表)
-- 7. 连接层: 应用的数据库连接配置加 charset=utf8mb4(见前面各语言示例)
-- 服务端 my.cnf 设 character-set-server=utf8mb4(一劳永逸)
-- ============ 第三步: 验证修复成功 ============
-- 8. 插入 emoji 和 4字节生僻字, 验证能存
INSERT INTO users (id, nickname) VALUES (999, '测试😀🎉𠮷');
-- 9. 读出来, 验证不乱码、emoji完整
SELECT id, nickname, LENGTH(nickname) AS bytes, CHAR_LENGTH(nickname) AS chars
FROM users WHERE id = 999;
-- LENGTH(字节数) 和 CHAR_LENGTH(字符数) 不同, 说明有多字节字符, 且能正确区分。
-- 10. 清理测试数据
DELETE FROM users WHERE id = 999;
-- 核心: 排查(查变量/库/表/列哪些非utf8mb4)→ 修复(改库/表CONVERT/连接/服务端)→
-- 验证(插emoji和生僻字, 读出来不乱码); 用 information_schema 系统地找出所有漏网的。这套 SQL,把"排查并修复字符集"这件事,从"凭感觉东改一处西改一处",变成了"系统化的三步走"。它的精妙,在于第一步用 information_schema 系统地、无遗漏地查出"到底哪些库、哪些表、哪些列、哪些连接变量还不是 utf8mb4"——这正好解决了本文反复强调的那个最大的坑:"别只改一半"。因为字符集问题最难缠的地方,就在于它"分散在多个层次"(连接、库、表、列),你改了表却可能漏了连接、改了库却可能漏了某张旧表、甚至某个列被单独设成了 utf8mb3;而只要有一处漏了,emoji 就还是存不下。这套 SQL 用 information_schema 把所有这些"藏在各个角落的、还没改的地方"一网打尽地查出来,确保不漏。这,正是我想用这套 SQL,留给每个 DBA 和后端开发的最后一课:对于"分散在系统多处、容易改漏"的配置型问题,排查的关键不是"凭记忆挨个想哪里要改",而是找到一个能"系统性地、穷尽式地"列出所有相关配置的方法(对数据库来说,就是 information_schema 这个元数据宝库)。因为"靠记忆和经验去找"总会漏,而"用元数据系统地查"才能保证完整;尤其是对这种"漏一处就前功尽弃"的全链路配置,"系统化、穷尽式"的排查,远比"东改一处西改一处"可靠。善用系统提供的"元数据/自省能力"(information_schema、配置 dump、各种 SHOW 命令),把"我以为都改了"变成"我查过了,确实都改了"——这,是我从这场"假 utf8"事故里,带走的、关于"如何彻底解决配置型问题"的、最实用的方法。
写在最后
回头看,这场由 MySQL "假 utf8" 引发的、存不下 emoji 的事故,真正教给我的,远不止"用 utf8mb4 别用 utf8"这一个知识点。它让我对"不要轻信名字、要理解本质"有了一次刻骨铭心的体会。我栽跟头,完全是因为我"太相信名字了":我看到 utf8 这个名字,理所当然地、不假思索地认为它就是我所知道的那个"标准 UTF-8"——毕竟,还有什么比 "utf8" 更明确地表示 "UTF-8" 呢?可现实给了我一记响亮的耳光:这个叫 utf8 的东西,偏偏不是完整的 UTF-8。这让我领悟到一个朴素却深刻的道理:名字,是别人对一个事物的"命名和承诺",但它不等于那个事物的"真实行为";而我们在使用任何东西时,真正应该依据的,是它"实际是什么、实际怎么行为",而不是它"叫什么名字"。大多数时候,名字和实际是相符的,这种"相信名字"的习惯帮我们省了很多事;但恰恰是那少数"名不副实"的情况(utf8 不是完整 UTF-8、Arrays.asList 不是 ArrayList、NaN 是个 number……),最容易让"相信名字"的我们,猝不及防地栽进去。所以,这件事给我的最大警示是:对于那些底层的、关键的、一旦错了影响很大的东西,不能停留在"它叫什么、我以为它是什么",而要花一点时间去搞清楚"它确切是什么、它的真实行为和边界在哪";那一点点"较真"的功夫,常常能帮你避开一个能熬掉你半天的坑。不轻信名字、深究本质——这,是我用一次"假 utf8"的事故,换来的、关于数据库、也关于"名字与本质"的、最朴素也最深刻的领悟。如果这篇复盘,能让你回去就检查一下自己数据库的字符集、把 utf8 都换成 utf8mb4,那我对着那个存不下的 emoji 熬的这大半天,就值了。
—— 别看了 · 2026