你可能见过这样的文字：锟斤拷、ä½ å¥½ 或 □□□。这就是乱码——由字符编码不匹配导致的文本错乱。本文解释乱码产生的原因，Unicode 和 UTF-8 如何从根源上解决问题，以及 HTML 实体如何为 Web 提供一个安全的逃生通道。你将获得一个清晰的心智模型和一个完整的示例，将所有这些串联起来。
根本原因：编码不匹配
乱码的核心很简单：文本的字节是用编码 A 写入的，但用编码 B 读取的。由于不同的编码将不同的字符映射到相同的字节序列，读取器会错误地解释这些字节。
例如，汉字 中 的编码：
- GBK 编码：
0xD6 0xD0 - UTF-8 编码：
0xE4 0xB8 0xAD
如果以 GBK 保存的文件被当作 UTF-8 打开，字节 0xD6 0xD0 会被解码为其他内容——通常会产生类似 ÖÐ 或 锟斤拷 的乱码，具体取决于场景。
Unicode 解决方案：统一编号系统
Unicode 为每个字符分配一个唯一的码点（例如，中 的 U+4E2D），将字符的身份与其字节表示解耦。然后 UTF-8（以及其他编码如 UTF-16）定义了如何将这些码点存储为字节。
| 编码 | 中 (U+4E2D) 的字节 |
说明 |
|---|---|---|
| UTF-8 | E4 B8 AD | 变长，兼容 ASCII，Web 主流 |
| UTF-16 | 4E 2D (或 2D 4E) | 每个码点 2 或 4 字节；Windows/JavaScript 使用 |
| GBK | D6 D0 | 遗留中文编码，每个汉字 2 字节 |
| ASCII | 不支持 | 仅 128 个字符 |
关键见解：Unicode + UTF-8 在字节层面消除了乱码——只要两端都同意使用 UTF-8。但是，在编码支持受限的环境（如 HTML）中，文本如何安全传输呢？
HTML 实体：Web 的转义机制
HTML 实体（例如 &、中）允许你仅使用 ASCII 安全字符表示任何 Unicode 字符。这在以下场景中至关重要：
- 在 HTML 中嵌入用户生成的文本（防止 XSS 和编码损坏）
- 包含可能无法在遗留传输通道（如电子邮件、旧数据库）中存活的字符
- 使不可见或歧义字符显式化
有两种形式：
- 命名实体：
&表示&，<表示< - 数字实体：
中（十六进制）或中（十进制）表示中
我们的配套工具 HTML 实体编码/解码器 可以让你在纯文本和 HTML 实体之间即时转换。
完整示例：从 GBK 到 UTF-8 再到 HTML 实体
让我们追踪一个真实场景：你收到了一个从遗留系统导出的 CSV 文件，以 GBK 保存。你在 UTF-8 编辑器中打开它，看到了 锟斤拷。以下是修复方法。
步骤 1：识别原始编码
检查文件的元数据，或在 Linux 上使用 file 命令：
$ file -bi data.csv
text/plain; charset=iso-8859-1 # 经常误检测
更好的方法：使用 chardet 或 iconv 检测 GBK。
步骤 2：重新编码为 UTF-8
使用 iconv 进行转换：
$ iconv -f GBK -t UTF-8 data.csv > data_utf8.csv
现在中文字符能正确显示了。
步骤 3：为 HTML 转义（如果需要）
如果这些数据要嵌入到网页中，请将特殊字符转换为 HTML 实体，以避免 XSS 和编码问题。使用我们的 HTML 实体工具，粘贴 中 得到 中 或 中。
Python 端到端示例：
import codecs
# 模拟以 UTF-8 读取 GBK 文件（乱码）
with open('data.csv', 'rb') as f:
raw = f.read()
# 错误：以 UTF-8 解码
garbled = raw.decode('utf-8', errors='replace')
print(garbled) # 锟斤拷...
# 正确：以 GBK 解码，然后编码为 UTF-8
correct = raw.decode('gbk').encode('utf-8')
print(correct.decode('utf-8')) # 你好世界
# 对于 HTML 输出，转义实体
import html
safe = html.escape(correct.decode('utf-8'))
print(safe) # 你好世界
常见陷阱
- 假设处处 UTF-8：遗留系统（Windows ANSI、旧数据库）可能使用 GBK、Shift-JIS 或 Latin-1。务必验证。
- 使用
.length截断字符串：在 JavaScript 中，'👨👩👧👦'.length是 11（UTF-16 码元），而不是 1（字素簇）。按长度截断可能会破坏 emoji 或组合字符。 - BOM（字节顺序标记）：带 BOM 的 UTF-8（
EF BB BF）可能会混淆解析器。优先使用无 BOM 的 UTF-8。 - 数据库字符集：MySQL 的
utf8实际上是utf8mb3（最多 3 字节）。使用utf8mb4以支持 emoji 和稀有字符。 - HTML 实体双重编码：如果你再次编码
&，它会变成&amp;。只编码一次。
常见问题
什么是乱码？
乱码是由于使用错误的字符编码解码字节而导致的文本错乱。经典的中文例子是 锟斤拷，当 GBK 编码的文本被当作 UTF-8 读取时，替换字符（U+FFFD）被重新编码并再次读取时就会出现。
什么时候应该使用 HTML 实体而不是 UTF-8？
在以下情况使用 HTML 实体：
- 需要在 HTML/XML 中嵌入文本并避免 XSS 或解析错误。
- 传输通道（如电子邮件、某些数据库）不可靠地支持 UTF-8。
- 希望使不可见字符（如零宽空格）显式化。
否则，UTF-8 更高效且可读性更好。
如何修复应用程序中的乱码？
- 识别原始编码（询问数据源，或使用检测库如
chardet）。 - 使用该编码解码，然后重新编码为 UTF-8。
- 对于 Web 输出，对用户生成的内容应用 HTML 实体编码。
Unicode、UTF-8 和 HTML 实体有什么区别？
- Unicode 是字符集：字符到码点（数字）的映射。
- UTF-8 是编码：将这些码点存储为字节的方式。
- HTML 实体 是文本级别的转义机制：使用 ASCII 安全序列（如
中）表示码点。
为什么 '👨👩👧👦'.length 在 JavaScript 中返回 11？
因为 JavaScript 字符串是 UTF-16 码元。家庭 emoji 由 4 个 emoji 通过零宽连接符（ZWJ）连接而成，加上变体选择器——总共 11 个码元。要计算可见的字素，请使用 Intl.Segmenter 或像 grapheme-splitter 这样的库。
总结
乱码是编码不匹配的症状。解决方案是统一使用 Unicode（UTF-8），并使用 HTML 实体作为 Web 的逃生通道。记住黄金法则：永不猜测编码，始终显式声明，优先使用无 BOM 的 UTF-8。有了这个基础，你可以从项目中彻底消除乱码。
试试我们的 HTML 实体编码/解码器，看看字符如何转换为实体。