1. 乱码的本质：字符编码基础概念
说实话，我做了十几年UI和前端，遇到最多的诡异问题就是乱码。明明代码看着没问题，一跑起来满屏都是「锟斤拷」或者「口口口」。你想想看，用户看到这种界面，第一反应就是——这软件太业余了。
乱码的本质是什么？说白了就一句话：编码方式不匹配。你用一个规则写进去，用另一个规则读出来，结果自然对不上。
今天咱们就把这个根儿刨清楚。从最基础的ASCII开始，一路讲到Unicode、UTF-8、GBK。搞懂了这些，你以后排查乱码问题，心里就有底了。
1.1 计算机怎么存字符？——从二进制说起
计算机只认识0和1。你想让它显示一个「A」，就得给这个「A」编个号。比如编号65，存成二进制就是01000001。读取的时候，看到01000001，就知道这是「A」。
这个「编号规则」，就是字符编码。
核心概念：字符编码 = 字符 ↔ 二进制数字 的映射表。
写文件时，字符→二进制；读文件时，二进制→字符。两边用同一张表，就没事。用不同的表，就乱码。
1.2 ASCII——老祖宗
ASCII（American Standard Code for Information Interchange）是最早的编码标准。1960年代的东西了。
它用7个比特表示一个字符，一共128个。包括：
- 大小写英文字母（A-Z, a-z）
- 数字（0-9）
- 标点符号（! @ # $ % 等等）
- 控制字符（换行、回车、退格等）
举个例子：
字符 'A' → 十进制 65 → 二进制 01000001
字符 'a' → 十进制 97 → 二进制 01100001
字符 '0' → 十进制 48 → 二进制 00110000
字符 '\n'（换行）→ 十进制 10 → 二进制 00001010ASCII的问题很明显——它只覆盖了英文。中文、日文、阿拉伯文……统统没有。所以后来各国都搞了自己的编码。
我个人的小习惯：排查乱码时，先看乱码里有没有正常的ASCII字符。如果英文字母和数字都正常，只有中文乱码，那基本就是中文字符编码的问题。如果连英文都乱，那可能是二进制传输层面出错了。
1.3 中文编码的战国时代——GB2312、GBK、GB18030
中国要处理中文，ASCII肯定不够用。一个汉字怎么也得两个字节吧？于是就有了GB系列编码。
| 编码 | 发布时间 | 字符数 | 特点 |
|---|---|---|---|
| GB2312 | 1980 | 6763个汉字 | 覆盖常用简体中文，不含繁体 |
| GBK | 1995 | 21886个汉字 | 兼容GB2312，增加了繁体字和生僻字 |
| GB18030 | 2000 | 70000+字符 | 兼容GBK，支持全部中日韩统一表意文字 |
GBK是Windows中文系统最常用的编码。很多老项目、政府系统、银行系统，到现在还在用GBK。
我曾经踩过的坑：有一次接手一个老项目，数据库里存的都是GBK编码的文本。前端页面用的却是UTF-8。结果所有中文都显示成乱码。排查了半天，最后发现是数据库连接配置里少了一句 characterEncoding=GBK。就这一行代码，折腾了我一整个下午。
1.4 大一统的梦想——Unicode
各国都有自己的编码，互相不兼容。你发一封邮件，对方用不同的编码打开，就是一堆乱码。这显然不行。
于是Unicode诞生了。它的目标很简单：给全世界所有字符一个唯一的编号。
Unicode本身只是一个字符集（Character Set），它规定了每个字符的编号（码点，Code Point）。比如：
字符 'A' → U+0041
字符 '中' → U+4E2D
字符 '😊' → U+1F60A但Unicode没有规定怎么存储这些编号。你不能直接用4个字节存所有字符吧？那英文文本会膨胀4倍，太浪费了。
所以，我们需要一种「存储方案」——这就是UTF-8、UTF-16、UTF-32这些编码方式。
1.5 UTF-8——当前的事实标准
UTF-8是目前最流行的编码方式。它的设计非常巧妙：
- 变长编码：一个字符用1到4个字节表示
- 兼容ASCII：ASCII字符（U+0000~U+007F）用1个字节，和ASCII完全一样
- 自同步：每个字节的高位标记了它是单字节字符还是多字节字符的一部分
UTF-8的编码规则：
| Unicode范围（十六进制） | UTF-8编码（二进制） | 字节数 |
|---|---|---|
| U+0000 ~ U+007F | 0xxxxxxx | 1 |
| U+0080 ~ U+07FF | 110xxxxx 10xxxxxx | 2 |
| U+0800 ~ U+FFFF | 1110xxxx 10xxxxxx 10xxxxxx | 3 |
| U+10000 ~ U+10FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx | 4 |
举个例子，汉字「中」的Unicode码点是U+4E2D，落在U+0800~U+FFFF区间，所以用3个字节表示：
U+4E2D = 二进制 0100 1110 0010 1101
UTF-8编码：
1110 0100 (0xE4)
10 111000 (0xB8)
10 101101 (0xAD)
→ 十六进制：E4 B8 AD我建议你记住这个：UTF-8编码的汉字，第一个字节通常在0xE4到0xE9之间。排查乱码时，用十六进制查看器打开文件，如果看到大量E4、E5、E6开头的字节，基本可以确定是UTF-8编码的中文。
1.6 为什么会出现乱码？——一张图说清楚
乱码的根本原因就一个：写入和读取用了不同的编码表。
下面这张图展示了最常见的乱码场景：
1.7 常见的乱码现象
不同的编码不匹配，会产生不同的乱码「风格」。我总结了几种最常见的：
| 乱码现象 | 原因 | 典型特征 |
|---|---|---|
| 锟斤拷锟斤拷 | UTF-8文本被当作GBK读取 | 大量重复的「锟斤拷」 |
| 浣犲ソ涓栫晫 | UTF-8文本被当作GBK读取（另一种情况） | 看起来像繁体但又不是 |
| ä½ å¥½ | UTF-8文本被当作Latin-1（ISO-8859-1）读取 | 大量带变音符号的字母 |
| 口口口口 | Unicode字符在当前编码中不存在对应 | 方框或问号 |
| ????? | 字符超出当前编码范围 | 问号代替 |
注意：「锟斤拷」这个乱码特别经典。它源于UTF-8的替换字符（U+FFFD，编码为EF BF BD）被当作GBK解码时，EF BF BD对应GBK的「锟」「斤」「拷」三个字。如果连续出现多个替换字符，就会看到「锟斤拷锟斤拷锟斤拷」的无限循环。我第一次见到这个的时候，还以为是程序bug，后来才知道是编码问题。
1.8 怎么判断当前文件是什么编码？
排查乱码的第一步，就是搞清楚文件原本是什么编码。我常用的方法：
- 看文件头：UTF-8文件有时会带BOM（Byte Order Mark），即
EF BB BF。有BOM的基本是UTF-8。 - 用工具检测：Linux下用
file命令，Python里用chardet库。 - 看内容特征：如果文件里英文字母正常、中文乱码，大概率是编码问题。如果连英文都乱，可能是二进制传输损坏。
- 看上下文：网页的
<meta charset>、数据库的character_set配置、HTTP响应头的Content-Type，都是线索。
我个人的排查流程：遇到乱码，先问三个问题——
- 数据从哪里来？（文件？数据库？网络请求？）
- 数据用什么编码写入的？（问上游，或者看文档）
- 当前用什么编码读取的？（检查配置、代码、工具设置）
这三个问题问完，80%的乱码问题都能定位。
1.9 小结
这一章我们讲了乱码的根源——编码方式不匹配。从ASCII到Unicode，从GBK到UTF-8，每种编码都有自己的适用范围和历史背景。
记住一句话：编码的世界里，没有对错，只有匹配和不匹配。
你只要确保写入和读取用的是同一张编码表，乱码就不会出现。但现实往往没那么简单——文件可能来自不同系统、数据库配置可能被忽略、HTTP头可能没设置……这些坑，我们后面一章一章地填。