中文乱码是怎么产生的，还能还原吗？

3 个讲解板块 · 关联 3 款站内工具 · 内容最后核对 2026-10-08

乱码不是某个字坏了，而是同一串字节被换错了表；能不能救回来，取决于错在哪一步。

直接答案

乱码的成因只有一个：一段字节被用错误的字符集解读了。中文在 UTF-8 下通常是 3 个字节一个字，在 GBK 下是 2 个字节一个字，两边对「几个字节算一个字」的约定不同，一旦换错表，字就会被切碎成一地，读出来就是乱七八糟的汉字。

判断「还能不能救」只需要看一样东西：有没有出现替换字符 U+FFFD。它一旦出现，说明某个环节在解码失败时已经把无法识别的字节换成了占位符，原始信息当场就丢了，任何工具都变不回来，只能回到源文件重新导出。反过来说，如果乱码里没有这个字符，原始字节还在，用正确的编码重新解码一次就能恢复。

中文乱码是几乎所有人都会遇到、却很少有人弄明白的现象。它看着像「字坏了」，实际上一个字都没坏——坏的是「哪几个字节算一个字」这个约定。UTF-8 里一个常用汉字占 3 个字节，GBK 里占 2 个，同一串字节按两套约定去切，切口全部错位，于是显示出一串谁都看不懂的汉字。

想明白这一点之后，排查乱码就不再靠运气。要问的其实只有两个问题：这串字节原本是按哪个编码写出来的？中间有没有哪一步解码失败、把字节换成了占位符？第一个问题决定用什么去解，第二个问题决定还有没有救。

两种乱码看起来差不多，处理方式却完全相反，所以第一步不是反复试编码，而是分类。

一句口诀：有占位符就是丢了，没有占位符就还能解。分类做对了，后面就不会在错误的方向上白费功夫。

三种现象都有明确的操作失误来源，对照着查比盲目试编码快得多。

锟斤拷: 两个连续的占位符在 UTF-8 下是 EF BF BD EF BF BD 六个字节，被 GBK 按两字节一切，恰好落成「锟」「斤」「拷」三个字。看到它，等于看到一张「这里丢过信息」的红牌。
烫烫烫 / 屯屯屯: 出自开发期的内存填充值：未初始化的栈内存被填为 0xCC、堆内存被填为 0xCD，在中文编码下恰好看成「烫」和「屯」。它不是编码转换问题，而是程序读了没赋值的内存。
一段好一段乱: 通常出现在混排文本里：只有某个来源的那一段没走对编码。定位范围可以缩小到那一段的产出环节，而不必怀疑整条链路。

第一条最值得记住。看到「锟斤拷」就不必再花时间尝试各种编码组合了——那一步的信息已经没了，直接去找源文件。

乱码排查有一个近乎万能的三步顺序，核心原则是「只在最外层解码，中间一律按字节搬运」。

拿到最原始的字节。文件就用十六进制看一眼开头几个字节；接口数据就在收到响应体的位置打印前 16 个字节。不要先把它们转成字符串再看。
根据字节特征猜编码。以 EF BB BF 开头是带 BOM 的 UTF-8；中文在 UTF-8 下多为 E4–E9 开头，在 GBK 下多为 B0–F7 开头。
用猜出的编码解码一次，看结果是否成句。成句就说明猜对了，到此为止；不成句再试下一个候选。
确认正确编码后回头改链路：把源文件另存为该编码、把接口声明的字符集或数据库连接串改成同一编码，让全链路一致。
特别提醒：不要把乱码字符串反复复制粘贴到不同工具里「试着看」。每粘贴一次就可能被隐式转码一次，越试越乱。
写进项目规范：源码、数据库、连接、终端一律统一编码；如果用的是 MySQL，字符集选 utf8mb4 而不是老的 utf8（老 utf8 最多 3 字节，存不下 emoji）。