字符与编码：ASCII、Unicode 与 UTF-8

文本在计算机中是一串二进制。本文整理从 ASCII 到 Unicode、再到 UTF-8/UTF-16/UTF-32 的编码演进，重点说明 UTF-8 的变长原理与"码点 vs 编码单元"的区别。

一、从字符到二进制

要让计算机处理文本，需为每个字符分配一个唯一编号（码点，Code Point），再用二进制存储。这个过程叫编码（Encoding）。字符集与具体存储编码是两件事，需区分清楚。

二、ASCII：早期单一字符集

• ASCII（American Standard Code for Information Interchange）用 7 位表示 128 个字符：大小写字母、数字、标点、控制符。
• 存储时通常占 1 字节（8 位），最高位 0。
• 如 A=65=0x41、a=97=0x61、0=48=0x30。

局限：仅覆盖英文字符，无法表示中文、日文、阿拉伯文等。

三、各国字符集与乱码的根源

各国各自定义扩展编码：

• GB2312 / GBK：中文简体，双字节。
• Big5：中文繁体。
• Shift-JIS：日文。

问题：同一字节序列在不同编码下含义不同，跨系统传输易产生乱码（mojibake）。这正是需要统一标准的原因。

四、Unicode：统一码点

Unicode 为全世界所有字符分配唯一码点，用 U+XXXX 表示，如 中 = U+4E2D。目前码点范围约 0 ~ 0x10FFFF（约 111 万），分为 17 个平面，日常字符多在基本多文种平面（BMP，U+0000 ~ U+FFFF）。

关键：Unicode 只定义"这个码点对应什么字符"，不规定如何存到字节。存储方案由 UTF（Unicode Transformation Format） 决定。

五、UTF 编码方案

UTF-32：定长

每个码点固定 4 字节。实现最简单、索引最快，但空间浪费大（英文也占 4 字节），几乎不用于存储。

UTF-16：BMP 定长 + 代理对

• BMP 内字符 2 字节；BMP 外字符用 4 字节代理对（Surrogate Pair）。
• Java、Windows、JavaScript 字符串内部用 UTF-16。
• 有字节序问题（大端/小端），需 BOM 标记。

UTF-8：变长，最流行

用 1~4 字节表示不同范围的码点，兼容 ASCII（0x00-0x7F 与 ASCII 完全一致）。

特点：

• 英文/ASCII 字符占 1 字节，Web/网络传输默认编码。
• 中文（如 中=U+4E2D）占 3 字节：11100100 10111000 10101101（即 E4 B8 AD）。
• 自同步：可通过首字节的前缀位判断它是单字节字符还是多字节序列的起始，便于定位与错误恢复。

编码示例：字符 "中"

• 码点：中 = U+4E2D = 二进制 100111000101101（15 位）。
• 落在 U+0800~U+FFFF，用 3 字节：
  • 第 1 字节 1110 + 高 4 位 0100 = 11100100
  • 第 2 字节 10 + 中 6 位 111000 = 10111000
  • 第 3 字节 10 + 低 6 位 101101 = 10101101
• 结果 E4 B8 AD，与 中 的 UTF-8 完全一致。

六、码点 vs 编码单元

• 码点（Code Point）：字符的唯一编号，与具体编码无关。
• 编码单元（Code Unit）：一种编码下的最小存储单元。
  • UTF-8 的编码单元是 1 字节。
  • UTF-16 的编码单元是 2 字节。

工程陷阱：很多语言 length() 返回的是"编码单元数"而非"字符数"。例如一个 emoji（U+1F600，代理对）在 UTF-16 下占 2 个编码单元，"😀".length 可能返回 2。处理时需注意。

七、工程实践建议

• 存储与传输统一用 UTF-8（Web 默认、兼容 ASCII、无 BOM 歧义）。
• 处理文本时区分"字符"与"编码单元"，遍历用能正确切分码点的 API。
• 编码转换错误会抛异常或产生乱码，读写时显式指定编码。

小结

• ASCII 是 7 位单字节编码；Unicode 统一所有字符的码点。
• UTF-8 是变长编码、兼容 ASCII、自同步，为事实标准；中文占 3 字节。
• 需区分码点与编码单元，避免 length 与实际字符数不符的陷阱。