乱码的本质：字节被按错误的规则解读
计算机里只有字节。所谓字符编码，就是字节序列 ↔ 字符的对照表。乱码通常不是数据丢失，而是同一串字节被另一套规则解释：用 UTF-8 写出的「中」，被当成 GBK 读，就会显示成别的字。
三个必须分清的概念
| 概念 | 是什么 | 常见误解 |
|---|---|---|
| 字符集（Unicode） | 给每个字符分配一个编号（码位） | 它本身不是编码方式 |
| 编码（UTF-8 / UTF-16） | 把码位变成字节的规则 | 「存成 Unicode」的说法并不准确 |
| 字节序与 BOM | 多字节单元的先后顺序 | UTF-8 不需要 BOM |
UTF-8 为什么成为默认
- 兼容 ASCII：英文仍占 1 字节，老系统可以直接读；
- 变长节省空间：常用汉字 3 字节，生僻字 4 字节；
- 无字节序问题：不需要 BOM，跨平台表现一致。
常见乱码形态与原因
| 现象 | 典型原因 |
|---|---|
| 「中文」变成「涓枃」一类字符 | UTF-8 字节被按 GBK 解读 |
| 出现「锟斤拷」 | UTF-8 按 GBK 解读后又转回 UTF-8，反复转码 |
| 出现「?」或「」 | 目标编码无法表示该字符，被替换字符取代 |
| URL 中的中文变成 %E4%B8%AD | 这是正常的百分号编码，不是乱码 |
四步排查
- 确认源头编码：文件或接口声明的是哪种编码；
- 确认读取端编码：编辑器、数据库、终端的字符集设置；
- 检查连接层：数据库连接串的 charset、HTTP 响应头的 Content-Type charset；
- 全程统一 UTF-8，并在每个边界显式声明，不要依赖默认值。
三种常见错误做法
- 反复转码「试试看」：每转一次都可能丢字符，应先确认原编码再一次性转换；
- 给脚本用的文件带 BOM：BOM 会被当成内容的一部分，导致解析失败；
- 数据库用 utf8 而非 utf8mb4：MySQL 的 utf8 只支持 3 字节，emoji 与部分汉字会入库失败。
常见问题
UTF-8 一定优于 GBK 吗？对新系统几乎是，但处理遗留 GBK 数据时不要贸然全量转换，先备份再逐库验证。Base64 能解决乱码吗？不能。它只是把字节转成可打印字符，编码问题依然存在；它的用途是让二进制安全穿过只支持文本的通道。
一个快速自检方法
把可疑文本按 UTF-8 编码后查看十六进制字节：常用汉字通常是以 E 开头的三字节序列（例如「中」= E4 B8 AD）。若看到大量 C0、80 开头的连续字节，多半是被错误转码过的产物。确认源编码后，按「源编码 → UTF-8」一次性转换即可，切勿反复转码。
动手试试：Base64 编解码（观察文本与字节之间的对应关系）
乱码定位的固定套路
乱码的种类有限，按下面的顺序排查通常几分钟就能定位。
- 先看乱码形态：成串的问号通常表示字符在转换过程中被替换，说明某一环不支持目标字符集；形如“锟斤拷”的固定组合是错误转换后再次转换的典型结果；单个字符变成多个奇怪符号则常见于编码与解码方式互不匹配。
- 确认链路每一环的编码声明：数据库连接、应用读取、模版渲染与响应头，每一环都应显式声明使用同一种编码，不能依赖默认值。
- 检查是否发生两次转换：同一段字节被按不同编码解释两次，就会产生看似无法还原的结果。发现这种模式时应回到最上游的字节检查。
- 用十六进制对比：把出问题的文本与预期文本的字节序列打印出来对比，能直接看出是多字节被拆开还是被重复编码，比猜测更快。
- 修复要覆盖全部入口：只修页面显示，导入、导出与接口仍会再次产生乱码，应统一在系统边界处规范编码。
根治方式是在数据入口就统一编码并校验合法性，而不是在展示层做兜底修复。后者只能掩盖问题，且会让脏数据持续沉淀。