某个周三下午，测试同事在群里扔了一张截图：数据接口测试里明明提交的是“收货地址：xx路xx号”，结果打开数据库一看，整条记录变成了“收货地址：？？？？？？？？”。我当时的第一个反应是表字符集没设对，结果查了一圈，库是utf8，连接串也带着characterEncoding=utf8，同库其他的表中文完全正常。真正定位到根因花了将近两个小时——问题卡在连接层和存储层之间的“翻译”上，而且那段时间差导致后续排查绕了不少弯路。
做数据接口测试和系统开发的同行，多多少少都会撞上这种“终端正常、接口正常、数据库乱码”的怪事。这篇文章把我踩过的坑、完整的定位链路、以及最后的预防方案都整理出来，希望能帮你把排查时间从两小时压缩到十几分钟。
1. 先分清乱码是“丢了字”还是“读错了”：三种形态和判断方法
遇到乱码，第一步不是改配置，而是先看它长什么样。同样是乱码，形态不同，根因完全不同，甚至直接决定数据还能不能救回来。
1.1 三种乱码形态的对照
我把工作中最常见的乱码形态分成三类，用一张表说清楚。
| 乱码形态 | 通常长什么样 | 本质原因 | 数据能否恢复 |
|---|---|---|---|
| 问号型 | ?或？？？ | 字符在编码转换时无法被目标字符集表达，被替换成占位符 | 基本不可逆，原字节已丢失 |
| 豆腐块型 | 口口口 | 数据字节还在，只是当前字体或终端不认这个字形 | 可逆，切换字体或客户端编码即可 |
| 错位型 | 锟斤拷、烫烫烫 | 字节被错误的字符集解码，再经过后续编码操作被破坏 | 部分可逆，取决于错乱链路 |
很多人一看乱码就跑去改数据库字符集，这是不对的。豆腐块型乱码你去改库表字符集，改完发现还是豆腐块，因为字节本身就是好的，问题在显示层。错位型乱码你去改连接串，可能越改越乱，因为并不是存储字符集不支持，而是两边解码规则对不上。只有问号型乱码才是真正的“字符集装不下”信号，这时候才需要动存储和连接配置。
1.2 为什么“问号乱码”一定要优先修源头
键盘上的问号对应ASCII码0x3F，它是一个极其普通的字符。如果数据库里存的是0x3F，那说明原来的中文字节已经被吃掉了——不是“丢了一部分”，而是编码转换时目标字符集里根本没有这个字形，于是系统用占位符替代。
这个过程是不可逆的，你可以把它想象成传真机上有一页纸，中间一行被涂改液盖住了，你无论如何都没法从一片白色里还原出原来的字。
判断方法很简单，用十六进制函数看一眼真实字节。比如在MySQL里执行：
SELECT nickname, HEX(nickname) FROM user WHERE id = 1;如果nickname显示“张三”，正常的UTF-8字节应该是E5BCA0E4B889。如果HEX返回的是3F3F3F，说明表里存的就是三个英文问号，数据在写入数据库之前就已经丢了。如果HEX返回的是正常的UTF-8字节，但客户端显示乱码，那问题不在存储层，而在查询结果的显示环节。
1.3 接口测试中最常见的两种“问号乱码”路径
结合“终端写入中文，数据库显示？？？”这个标题场景，我想特别说明一下：这里的终端，可以是接口测试工具、命令行客户端，也可以是一个网页前端。不管入口是什么，最终我看到的问题基本固定在两条路径上。
第一条路径，应用层在收到请求后，用错误的编码解析了请求参数。例如HTTP请求体明明是UTF-8字节，但服务端却按ISO-8859-1去解码，于是中文字符直接变成问号，后面再往数据库写，写的自然就是问号。
第二条路径，应用层收到的参数是好的，SQL语句也是正常的，但数据库连接层或表字段的字符集不支持中文。MySQL在把字符写入表的时候，发现目标字符集没有对应字形，于是静默替换成?。
这两条路径需要完全不同的处理方式。所以真正动手之前，一定要先判断是“入口就丢了”还是“存储时丢的”。
2. 一次现场排查复盘：从“数据库没问题”到“锁定连接串”的全过程
有一次排查让我印象很深，因为问题表象非常迷惑：其他表都正常，只有一张表写入中文变问号，而且是偶尔变、偶尔正常。我把当时的排查过程完整复现一下，这套思路在大多数乱码场景下都能复用。
2.1 第一步：绕过应用，直连数据库测试
当时我第一个动作是排除数据库本身的问题。用图形化数据库客户端直连MySQL，手动执行：
SET NAMES utf8mb4; INSERT INTO user_profile(nickname) VALUES ('测试中文'); SELECT nickname FROM user_profile WHERE id = LAST_INSERT_ID();结果插入成功，查询结果也是正常中文。这就说明数据库实例、库、表的存储能力本身没问题，问题出现在“应用服务到数据库”这一段，范围瞬间缩小了一半。
这里有个容易被忽略的点：SET NAMES utf8mb4这句很重要。它把当前连接的三个人物——character_set_client、character_set_connection、character_set_results全部设置为utf8mb4。如果不加这一句，同一个客户端工具也可能因为默认连接字符集不对，造成“误判数据库有问题”的情况。
2.2 第二步：看应用层收到的原始字节
数据库没问题，那就去应用层看。我在接口入口临时加了一段日志，把请求参数“测试中文”打印成十六进制字节。在Java环境里的写法大致是这样：
byte[] raw = param.getBytes(StandardCharsets.UTF_8); for (byte b : raw) { System.out.printf("%02X ", b); }正常打印出来是E6 B5 8B E8 AF 95 E4 B8 AD E6 96 87，说明请求参数在入口处没有变成问号，应用接收到的中文是完整的UTF-8字节。
2.3 第三步：检查拼出来的SQL和连接配置
入口参数没问题，那继续往下走，看拼好的SQL和最终连接数据库的配置。当时我把日志里打印的SQL拿到数据库客户端手动执行，也是正常的。于是把目光锁定在数据库连接串上。
连接串是这样的：
jdbc:mysql://127.0.0.1:3306/user_db?useUnicode=true&characterEncoding=UTF-8看起来没问题，characterEncoding=UTF-8也在。这让我很困惑，配置都对，为什么写入还是问号？
2.4 第四步：发现建表历史的“时间差”
后来仔细对比了正常的表和出问题的表，最终用一条SQL找到了答案：
SHOW CREATE TABLE user_profile;问题表的定义里赫然写着DEFAULT CHARSET=latin1。
这个瞬间所有现象都对上了。连接串里的characterEncoding=UTF-8只让连接层执行了SET NAMES utf8，也就是连接层的字符集确实是utf8。但问题是，当MySQL要把一个UTF-8字符写入latin1字段时，它必须做一次“目标不可达”的转换——中文在latin1里根本没有对应字形，于是只能替换成?。其他表都是后来用utf8mb4建的，所以表现正常，只有这一张早年间手工建立的latin1表出了问题。
2.5 修复与验证
最终修复就一句SQL：
ALTER TABLE user_profile CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;执行完以后，同一个数据接口再提交中文，数据库里的值立刻就正常了。
这次的教训是：乱码排查不要习惯性怀疑全部配置，要具体到“哪一张表、哪一条连接、哪一个接口”三个维度上。一个系统中90%的表都正常，突然某张表乱码，优先看这张表的定义和创建时间，比全局调参数要快得多。
3. MySQL字符集链路拆解：客户端、连接、存储三层的翻译接力
要彻底理解乱码问题，光会改SQL还不够，得把MySQL的字符集机制搞清楚。它不是“表设成utf8就万事大吉”这么简单，而是多个变量在协同工作。
3.1 一条INSERT语句在MySQL内部经历的“翻译”过程
当一条带中文的INSERT语句到达MySQL后，它的字符集要经过三层处理：
第一层是character_set_client。MySQL把客户端发来的字节流按照这个变量去识别，相当于“先听清你用什么语言说话”。
第二层是character_set_connection。MySQL把SQL文本转换成这个变量的字符集，在这个层面完成语句的解析和判断。
第三层是存储层的字段字符集。真正要把数据写进表的时候，MySQL会再把connection字符集转成字段字符集。如果字段是utf8mb4，中文正常存；如果字段是latin1，中文没有对应字形，非严格模式下就会被替换成?。
查询返回结果时还会经过character_set_results。也就是说，你看到查询结果乱码，不一定是存储有问题，也可能是返回结果的字符集配置不对。
这一整套链路，我习惯把它叫作“翻译接力”。任何一个环节的译者不认识中文字，整条链路就会断掉。
3.2 查看和检查的关键变量
工作中查看字符集变量，最常用的一条SQL是：
SHOW VARIABLES LIKE 'character_set_%';执行结果会列出所有相关变量。我见过很多人说“我查过了没问题”，其实只是看了character_set_server和表的CHARACTER SET，恰恰忽略了连接变量。而连接变量会随着不同客户端、不同连接串动态变化，所以你必须在出问题的那条连接上查看，而不是随便找个窗口看全局。
除了字符集变量，还有必要看一下SQL模式：
SELECT @@sql_mode;如果当前连接不是严格模式，MySQL遇到无法表达的字符会静默替换成?，数据写入不会报错。如果是严格模式，直接报Incorrect string value错误。很多老项目为了兼容历史数据，把sql_mode调成了非严格模式，这就是为什么“问号入库”会发生得悄无声息。
3.3 一个最容易混淆的细节：utf8和utf8mb4
MySQL里的utf8其实是个“历史包袱”，它最多只能存3字节的字符，准确叫法是utf8mb3。日常汉字没问题，但遇到emoji或者某些生僻字，比如4字节的扩展汉字，utf8就彻底装不下。
utf8mb4才是真正的“完整版utf8”，支持所有Unicode字符。这也是为什么现在的建库建表规范一律推荐utf8mb4。
这里要特别提醒一个配套关系：如果应用连接的字符集设置成utf8，而表是utf8mb4，大部分汉字也能正常存取，因为从utf8到utf8mb4是向下兼容的。但如果反过来，连接层是utf8mb4，表是老的utf8，遇到生僻字和emoji还是会出问题。所以最稳妥的做法是所有层面统一utf8mb4。
3.4 不同类型应用的连接参数参考
把常用的连接配置列一下，方便直接对照检查：
Java JDBC：
jdbc:mysql://127.0.0.1:3306/user_db?useUnicode=true&characterEncoding=UTF-8&serverTimezone=GMT%2B8Python SQLAlchemy：
mysql+pymysql://user:pass@127.0.0.1:3306/user_db?charset=utf8mb4PHP PDO：
mysql:host=127.0.0.1;dbname=user_db;charset=utf8mb4这里有一个坑：老版本的JDBC驱动并不认识utf8mb4这个东西，你直接写characterEncoding=utf8mb4反而会报错，得写characterEncoding=utf8或者UTF-8。新版本驱动则建议直接写UTF-8。所以连接串的写法必须和驱动版本配套，不能无脑照抄网上的配置。
4. 修复优先级：改连接串、改表字符集、改代码，到底先动哪个
定位到问题之后，修复也有讲究。我的习惯是优先级从低风险到高风险来安排：先改连接层，再改存储层，最后才动代码层。
4.1 第一选择：修正连接配置
如果项目允许重启应用，优先改连接串。很多乱码问题仅仅出在连接层没有正确设置字符集，更新连接串以后，应用发出的所有语句就带上了正确的字符集信息。
这个方案的优点是风险很低，基本不影响已有数据，改完重启即生效。但如果问题已经不是连接层，而是表本身就用了latin1，那么光改连接串不够，因为数据最终还是要存进那张latin1表里。
4.2 修改库表字符集的正确姿势
如果确认是库或表的字符集不匹配，那就要动手改存储层。修改之前，先想清楚历史数据是不是还在意：如果表里已经积压了大量业务数据，改字符集可能导致已有数据出现二次乱码；如果历史数据反正已经不可救了，那直接转换就行，新数据能正常写入才是重点。
转换全表字符集的语句是：
ALTER TABLE user_profile CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;这条语句会重写整张表，把表定义和所有字符型列一并转换。数据量大的时候会长时间执行，可能造成锁表，所以务必选在低峰期操作，并且先做备份。
如果只想改某一列，可以用：
ALTER TABLE user_profile MODIFY nickname VARCHAR(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;但这里要提醒：如果列里已经存在非法字节或者0x3F问号，转换过程中也可能遇到阻碍。任何转换操作前，备份都是必须的第一动作。
4.3 代码层的兜底与统一
最后才是考虑改代码。这属于长期治理，不是应急手段。实践中我会关注四个点：
第一，请求入口统一设置编码。很多Web框架都提供了字符集过滤器，把请求体和响应体强制为UTF-8，这个一定要在框架配置里显式开启。
第二，应用内部不要反复做字符串编码转换。强类型语言里，字符串对象内部就是Unicode，不需要你手动把String转成byte[]再转回String。反复转换只会增加出错率。
第三，日志输出尽量用Unicode转义或十六进制。普通字符串在控制台里可能已经被终端编码污染了，你看到的是“正常中文”，不代表业务处理过程中它一直是正常中文。只有十六进制是铁证。
第四，数据库连接串放进统一的配置管理。不同环境、不同服务各自为政地粘贴一份连接配置，迟早会出现“测试环境正常、生产环境乱码”这类怪异问题。
5. 已经写成问号的旧数据，还能不能救回来
很多人在排查完乱码之后，会问一句“那库里已经有的问号还能救吗”。我的回答是：先分型再动手，不要盲目跑数据修复脚本。
5.1 用HEX判断数据存活状态
查询一下列的十六进制，信息非常直观：
SELECT nickname, HEX(nickname) FROM user_profile WHERE id IN (1,2,3);如果显示的一串都是3F 3F 3F，那就是标准的“被替换型丢字”。原字节已经没了，换成多少条SQL都救不回来。
但如果HEX结果是一串看似“乱码”的字节，比如D6 D0 CE C4这种，那反而有救。因为它不是被替换，而是被错误的字符集解读后原样存了进去，字节本身还完整地躺在那里，只是解码规则不对。
5.2 两种常见的字节反转思路
先看第一种情况，客户端用GBK发送了“中文”两个字，但连接和字段都被设置成了latin1，那么表里存的其实就是GBK原始字节D6 D0 CE C4。恢复的思路是先把列按二进制取出来，再用GBK解码：
SELECT CONVERT(CAST(nickname AS BINARY) USING gbk) FROM user_profile;如果查询结果恢复成了正确中文，就可以用UPDATE把转换结果写回去。
再看第二种情况，UTF-8字节被当成latin1存储，恢复思路类似，区别只是最后用utf8mb4解码：
SELECT CONVERT(CAST(nickname AS BINARY) USING utf8mb4) FROM user_profile;这两种反转方法都建立在“字节没丢”的前提下，操作前一定要做样本验证。
5.3 我的数据抢救流程
遇到需要抢救数据的场景，我的固定流程是这样的：
- 整表备份，导出SQL文件，单独保存。
- 取3到5条样本数据，跑反转查询，肉眼确认结果完全符合预期。
- 在测试库里完整演练一遍UPDATE语句，确认不会把原本正常的字符二次搞乱。
- 生产库上分批更新，大表务必先在低峰期小批量试跑。
- 更新后重新执行HEX查询，确认新写入的字节是合法UTF-8编码。
还有一点经常被忽略：如果表里的数据是混合型的，一部分是GBK误存，一部分已经是真正的问号，那么反转脚本会把原本的“真问号”再错解一次。所以样本验证绝对不能省，宁可慢一点，也不能赌一把。
6. 团队级预防：建表模板、测试断言与日常巡检
修好一次只能解决当下，真正的目标是不让这个问题反复出现。我建议团队至少做三件事，成本都不高，但收益长期可见。
6.1 统一建库建表模板
把下面这段作为所有新建库表的唯一标准写法，贴到操作手册里：
CREATE DATABASE app_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE TABLE user_profile ( id BIGINT PRIMARY KEY AUTO_INCREMENT, nickname VARCHAR(64) NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;同时立一条规矩：所有环境，测试、预发、生产，必须使用同一套DDL脚本，不允许任何人手工建表。我遇到的不少乱码问题，最后都追溯到“某个人手工建了一张表，顺手选了默认的latin1”，这种问题靠技术手段很难完全防住，只能靠流程堵住。
6.2 在接口测试用例里加“中文往返断言”
这是最有效的自动化预防手段。具体做法是，在数据接口测试用例里专门加一条用例：
- 提交的数据必须包含中文，最好还要包含emoji和生僻字。
- 提交后立刻查询数据库，断言库里保存的值和提交值完全一致。
- 接口返回正常不代表库正常，因为中间还有一层存储转换。
这个用例一旦跑起来，任何一次连接串调整、表结构变更、框架升级，只要动了字符集链路，测试立刻就会亮红灯，而不是等业务人员发现页面上全是问号。
6.3 加一个字符集巡检脚本
最后是一件一劳永逸的事：写一个定期巡检脚本，扫描库里是否存在字符集不规范的表：
SELECT TABLE_SCHEMA, TABLE_NAME, TABLE_COLLATION FROM information_schema.TABLES WHERE TABLE_COLLATION NOT LIKE 'utf8mb4%' AND TABLE_SCHEMA NOT IN ('information_schema','mysql','performance_schema','sys');跑出来的结果，就是所有可能暗藏乱码风险的表。配合前面说的中文往返断言，一个是事后兜底，一个是事前预警，两层一起工作，字符集问题基本能被拦在发布之前。
处理乱码这些年，我最大的体会是：乱码不可怕，可怕的是不知道乱码是在哪一步丢的。先把HEX查询、character_set系列变量、SHOW CREATE TABLE这几件工具用熟，再按“数据库直连验证、接口入参验证、连接配置验证、表定义验证”的顺序逐层排查，多数问题一个小时以内就能定位。
最后分享一个小技巧：在本地准备一个排查乱码的SQL模板，包含字符集变量查看、HEX查询、建表语句查看三件套。下次再有测试同事来喊“数据库里全是问号”，先让他把这三条SQL的执行结果发过来，让证据说话，排查效率会高很多。
