字符编码与中文乱码速查

1六个必须分清的名词

最容易出错的一点是把「字符集」和「编码」当成一回事。字符集回答「有哪些字符、每个编号是多少」，编码回答「这些编号在文件里怎么存成字节」。同一个字符集可以有多种编码方式。

记忆抓手：Unicode 负责「编号」，UTF-8 负责「存字节」。中文里说「转成 UTF-8」，严格讲是「按 UTF-8 编码存」；而 GBK 既是编号表也是存储方式，所以能直接说「这个文件是 GBK」。

2五类乱码现象与成因

乱码的样子不同，成因和可修复性也完全不同。识别出属于哪一类，就知道该怎么处理——尤其是后两类，基本已经无法完整还原。

判断技巧：看到拉丁字母和符号混杂的乱码，通常是「UTF-8 被当单字节编码读」；看到成片的汉字但明显不是正常词句，通常是「UTF-8 被当 GBK 读」。两种都能救回来。

3乱码排查的固定顺序

乱码问题的难处不在技术，而在于环节多——文件、网络传输、数据库、程序内存，每一层都可能发生一次编码转换。按下面的顺序查，基本不会漏。

第一步：确认源编码

先弄清数据「本来」是什么编码，看导出工具的设置、看原始文件的声明，不要靠猜。猜错编码，后面的修复只会越修越乱

第二步：确认读取端

看读取方按什么编码解码——网页看 meta charset 与响应头，程序看打开文件时的参数，数据库看连接串

第三步：两端对齐

两边一致就不会乱码。这是唯一正确的长期方案，任何「用另一个错误去抵消前一个错误」的做法都会在某个环节再次崩掉

第四步：抢救已有数据

如果存的已经是乱码，做法是「按错误编码取回原始字节，再按正确编码重新解码」。例如 UTF-8 内容被存成了 ISO-8859-1，就用 ISO-8859-1 读出来再按 UTF-8 重新解析

网页场景

依次检查：文件实际编码 → meta charset → 响应头 Content-Type 里的 charset → 数据库字段字符集，四处一致才不会乱

数据库场景

连接串 characterEncoding、表字符集、字段字符集三处都要统一。MySQL 建议全程用 utf8mb4（utf8 三字节版本存不下 emoji）

4BOM：什么时候该加，什么时候不能加

BOM（字节顺序标记）是文件开头的一小段字节。UTF-8 的 BOM 是 EF BB BF 三个字节，作用相当于「本文件是 UTF-8」的显式声明。它有两个完全相反的适用场景。

不能加：网页与代码文件

BOM 会被当成正文内容，导致页面顶部出现多余空白、PHP 无法再发送响应头（因为已经输出了内容），某些解析器还会把它当成第一个字符而导致语法错误

应该加：给 Excel 打开的 CSV

Excel 打开 UTF-8 的 CSV 默认按本地编码解释，中文会乱码。加上 BOM 后 Excel 能正确识别为 UTF-8——这是「CSV 中文乱码」最常见的解法

辨析

「CSV 乱码」有两种：一种是内容真的坏了（可修复），另一种是内容没错、只是 Excel 解码方式不对（加 BOM 或改用「导入数据」功能指定编码即可）

其他场景

JSON 规范不推荐加 BOM；XML 解析器允许 BOM；纯文本文件按需处理，交接给 Windows 系统时可保留

5实用结论：默认一切都是 UTF-8

除了必须对接遗留系统（老政务平台、老版 ERP、部分银行接口）的情况，现代开发没有理由不用 UTF-8。下面是几处「容易忘记显式声明」的地方，漏掉任何一处都可能冒出一个乱码。

HTTP 响应头

Content-Type: text/html; charset=utf-8

HTML 文档

meta charset 放在 head 的最前面，且必须与文件实际编码一致

文件读写

打开文件时显式指定 encoding="utf-8"，不要依赖操作系统默认值

数据库

建库、建表、连接串三处统一 utf8mb4

数据导入导出

CSV / TXT 导出时指定编码，给 Excel 用就加 BOM

邮件

MIME 头里的 charset 参数，缺失会导致中文主题乱码