UTF-8 和 GBK 有什么区别？中文乱码的根源

一句话结论：UTF-8 和 GBK 都是把汉字变成字节的规则，但规则不同。同一段字节用错规则去读，就会出现乱码——乱码本身不是数据丢了，而是翻译错了。

编码到底是什么

计算机只认识字节（0–255）。文字要存成字节，就需要一套「字符 ↔ 字节」的映射表，这张表就是字符编码。

• ASCII：只有 128 个字符，英文和符号，1 字节
• GBK：中国人做的汉字编码，汉字固定 2 字节，收录约 2 万个汉字
• UTF-8：全球通用，英文 1 字节、汉字 3 字节，能表示所有 Unicode 字符

直观对比

「中文」两个字：

编码	字节（十六进制）
UTF-8	E4 B8 AD E6 96 87（6 字节）
GBK	D6 D0 CE C4（4 字节）

GBK 更省空间，UTF-8 更通用。现在新系统一律用 UTF-8，GBK 主要出现在老系统和 Windows 中文环境里。

乱码是怎么产生的

假设文件实际用 GBK 保存（D6 D0 CE C4），但编辑器按 UTF-8 去读：

1. 它把 D6 D0 当成一个 UTF-8 序列解析
2. 解码失败或解出错误字符
3. 你看到「��」或「ÖÐÎÄ」这样的乱码

反过来也一样。所以乱码的关键信息是：字节没错，读法错了。

怎么判断是哪种

三个办法，从快到慢：

1. 看乱码长相：GBK 被当 UTF-8 读，常出现 � 或大量问号；UTF-8 被当 GBK 读，常见「文件」这类拉丁字母组合
2. 看文件来源：Windows 记事本、老版 Excel 导出的 CSV 大概率是 GBK；网页、现代编辑器默认 UTF-8
3. 直接试：用 GBK/UTF-8 互转工具两种方向各转一次，看哪个结果是正常中文

怎么修

• 文本文件：用编辑器另存为 UTF-8（不要选「带 BOM」）
• Excel 打开的 CSV 乱码：Excel 默认按 GBK 读 CSV，把文件转成「UTF-8 带 BOM」就能正常打开
• 网页：确认 <meta charset="utf-8"> 和服务器返回的 Content-Type 一致
• 数据库：建库、建表、连接三处都要是 utf8mb4，缺一处就会乱

常见坑

• 改了 header 没改文件本身：声明成 UTF-8 但文件还是 GBK，照样乱码
• BOM 头：UTF-8 BOM（EF BB BF）会让 JSON 解析、Shell 脚本出错，能用不带 BOM 就不用
• emoji 存不进去：MySQL 的 utf8 实际只有 3 字节，存 emoji 要用 utf8mb4