Unicode 编码入门：从 \uXXXX 到字符集的完整图景
什么是 Unicode？
先说一个几乎每个程序员都遇到过的场景：你打开一个文本文件，屏幕上一片”锟斤拷”、“烫烫烫”或者满屏的问号方块。你以为是文件坏了，实际上，90% 的乱码问题根源都在字符编码上。
Unicode 就是来解决这个问题的。它是一个字符集——给全世界每一种书写系统里的每一个字符分配一个唯一的编号，这个编号叫码点（Code Point）。比如，“A”的码点是 U+0041，“你”的码点是 U+4F60，“好”是 U+597D，而😀（emoji）的码点是 U+1F600。
说白了，Unicode 就像全世界的字符身份证系统——每个字符一出生就领到一个永久编号，不管你在哪个国家、用什么操作系统，这个编号都不会变。
不过话说回来，Unicode 本身只定义了”编号”和”编号对应的字形长什么样”，并不规定这些编号在计算机里怎么存储。真正的存储规则由 UTF-8、UTF-16、UTF-32 这三种编码方案来负责。字符集和编码方案是两件不同的事，但很多人把它们混为一谈。
我第一次认真研究 Unicode 是在排一个前端国际化 bug——后端返回的 JSON 里，中文变成了 你好 这样的转义序列。当时我盯着控制台看了十分钟，心里只有一个念头：这到底是什么鬼。后来才明白，你 就是码点 U+4F60 的另一种写法而已。
码点、平面和代理对
码点空间有多大？
Unicode 的码点范围是 U+0000 到 U+10FFFF，一共可以容纳 1,114,112 个字符——大约 111 万个。截至 2025 年，Unicode 15.1 版本已经分配了大约 15 万个字符，还剩大量空间留给未来的书写系统。
这个空间被分成 17 个平面（Plane），每个平面容纳 65,536 个码点（2^16）。最常用的是第 0 号平面，即基本多文种平面（BMP，Basic Multilingual Plane），涵盖了拉丁字母、汉字、日韩文字、标点符号等日常使用的绝大部分字符。我们写成 U+XXXX 格式的字符，绝大多数都住在这个平面里。
但 emoji、古埃及象形文字、罕用汉字这些”非常规角色”住在 1 到 16 号平面，统称增补平面。关键问题是：UTF-16 用 2 个字节表示一个 BMP 字符，那超出 BMP 的字符怎么办？答案是代理对（Surrogate Pair）——用两个特殊的 16 位单元拼出一个码点。我之前在解析包含 emoji 的用户昵称时吃过一次亏——把代理对的两个单元各算成一个”字符”，结果字符串长度统计全乱了。
组合字符：一个”字符”不等于一个码点
更微妙的一点是，Unicode 支持组合字符（Combining Characters）——一个字可以拆成基础字符和附加的变音符。举个例子，“é” 既可以用单个码点 U+00E9 表示，也可以用 “e” (U+0065) 加锐音符 (U+0301) 拼出来。看起来完全一样，但底层是完全不同的码点序列。
这个特性导致了一个常见的麻烦：两个看起来一模一样的字符串，用 === 比较却是 false。我们后面讲规范化形式的时候会详细说。
三种编码方案：UTF-8、UTF-16、UTF-32
记住一句话：码点是”身份证号”，编码方案是”运输方式”。同一个字符，用不同的编码方案在硬盘和网络里存储的字节序列完全不同。
UTF-8：变长编码的绝对统治者
UTF-8 是目前互联网上使用最广的编码，占所有网页的 98% 以上。它的设计非常聪明——变长编码，不同字符用不同数量的字节：
| 码点范围 | UTF-8 字节数 | 编码模板 |
|---|---|---|
| U+0000 ~ U+007F | 1 字节 | 0xxxxxxx |
| U+0080 ~ U+07FF | 2 字节 | 110xxxxx 10xxxxxx |
| U+0800 ~ U+FFFF | 3 字节 | 1110xxxx 10xxxxxx 10xxxxxx |
| U+10000 ~ U+10FFFF | 4 字节 | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx |
以汉字”你”（U+4F60）为例：
U+4F60 二进制：0100 1111 0110 0000
填入 3 字节模板：1110xxxx 10xxxxxx 10xxxxxx
编码结果：11100100 10111101 10100000
即：E4 BD A0（三个字节）
而 ASCII 字符”A”只需要 1 个字节，与纯 ASCII 编码完全兼容。我把它比作一辆自适应集装箱卡车——拉 ASCII 字符时轻装上阵（1 字节），遇到中文自动扩容到 3 字节，碰到 emoji 再扩到 4 字节。每个字节的前导位明确告诉了解码器：“我是开头字节”还是”我是后续字节”，解码过程不需要查字典，硬件可以直接并行处理。
UTF-16：Windows 系的默认选择
UTF-16 也是变长编码，只是”起步价”更高——BMP 内的字符统一用 2 个字节，超出 BMP 的用代理对，也就是 4 个字节。Java 的 String 内部存储、Windows 内核的宽字符 API，用的都是 UTF-16。
说实话，UTF-16 就是一个历史折中方案。Unicode 刚设计出来的时候，大家都以为 65,536 个码点足够用，UTF-16（那时候叫 UCS-2）就是定长 2 字节，简单高效。后来发现不够——光中日韩统一表意文字就好几万——只好引入代理对机制，把 UCS-2 升级成变长的 UTF-16。这个打补丁的过程，是如今很多跨平台字符串处理 bug 的根本原因。
UTF-32：简单粗暴，空间换时间
UTF-32 是对早期设计的回归——定长 4 字节，一个码点就是 4 个字节。遍历字符串时你不需要关心任何变长逻辑，第 N 个字符就是第 N * 4 个字节处开始读。但代价是空间占用直接翻了 2 到 4 倍。
三种编码对比
| UTF-8 | UTF-16 | UTF-32 | |
|---|---|---|---|
| 编码方式 | 变长（1-4 字节） | 变长（2 或 4 字节） | 定长（4 字节） |
| ASCII 兼容 | 完全兼容 | 否 | 否 |
| 空间效率（英文为主） | 优秀 | 一般（每个字符 2 字节） | 差（每个字符 4 字节） |
| 空间效率（中文为主） | 良好（每个汉字 3 字节） | 良好（每个汉字 2 字节） | 差 |
| 遍历复杂度 | 需要解析变长头 | 需要判断代理对 | O(1) 直接跳转 |
| 主要应用场景 | Web、Linux、数据库 | Windows、Java、JavaScript | 内存处理、ICU 库内 |
BOM：字节序的麻烦
跨平台开发时，经常遇到奇怪的 出现在文件开头。那是BOM（Byte Order Mark，字节序标记）——U+FEFF 这个零宽不换行空格被”征用”来标注字节序。
UTF-16 和 UTF-32 的字节在内存里怎么排列？高字节在前（Big Endian）还是低字节在前（Little Endian）？BOM 就是回答这个问题的。读文件时先看前两个字节：FE FF 表示 UTF-16 BE，FF FE 表示 UTF-16 LE。如果你看到一个文件以 EF BB BF 开头，那它多半是带 BOM 的 UTF-8 文件——Windows 记事本特别喜欢加这玩意。
我之前写一个跨平台日志解析器，在 Linux 上用 Python 读 Windows 生成的日志文件，readline() 出来的第一行字符串前面总是多了个看不见的东西，正则死活匹配不上。排查了两个小时，最后发现就是 BOM 捣的鬼。open(filename, encoding='utf-8-sig') 一句话就解决了，但找个问题的过程真的是一言难尽。
Unicode 规范化：为什么”看起来一样”不等于”相等”？
前面提到组合字符的问题——同一个字形可以用预组合字符（precomposed）和分解组合字符（decomposed）两种方式表示。这个问题在实际开发中远比想象的要常见。
Unicode 定义了四种规范化形式：
| 规范化形式 | 含义 |
|---|---|
| NFC | 先分解再组合，尽可能用预组合字符（“紧凑”形式） |
| NFD | 全部分解为基础字符+变音符（“展开”形式） |
| NFKC | 在 NFC 基础上做兼容性替换（如全角转半角） |
| NFKD | 在 NFD 基础上做兼容性替换 |
大多数 Web 场景推荐用 NFC，特别是 HTML 和 CSS。像 macOS 的文件系统用的是 NFD，所以你用 Finder 创建的文件名”é”和用终端创建的可能底层编码不同，虽然看起来完全一样。这就是为什么做文件名比较时不能直接用字符串相等，要先统一规范化。
实际应用场景
1. 前端：JavaScript 中的 Unicode 陷阱
在 JavaScript 里，字符串的 .length 返回的是 UTF-16 编码单元的个数，不是实际字符数：
"你好".length; // 2（2个UTF-16单元，正好也是2个字符）
"😀".length; // 2（emoji用了代理对，2个UTF-16单元但只有1个字符）
想拿到真正的字符数？用 [...str].length 或者 Array.from(str).length——它们走的是迭代器，能正确处理代理对。这个坑我敢说至少一半的前端开发者第一次遇到 emoji 输入框字数统计 bug 时都懵过。
2. 后端：数据库字符集配置
MySQL 里有一个很隐蔽的坑：utf8 和 utf8mb4 不是同一个东西。MySQL 的 utf8 是一个阉割版——它只支持最多 3 字节的 UTF-8 字符，emoji 和部分罕用汉字（4 字节）存进去会被截断或报错。utf8mb4 才是完整的 UTF-8 实现。如果你要存用户昵称（可能含 emoji），建表时务必选 utf8mb4。
3. Python 常见的编解码错误
# 中文编码成 UTF-8 字节
"你好".encode("utf-8") # b'\xe4\xbd\xa0\xe5\xa5\xbd'
# 错误示范：用 Latin-1 解码 UTF-8 字节
b'\xe4\xbd\xa0'.decode("latin-1") # 'ä½\xa0'——乱码就是这样产生的
# 正确做法
b'\xe4\xbd\xa0'.decode("utf-8") # '你'
乱码的诞生过程可以概括为：用编码 A 把字符串变成字节，然后用编码 B 去解读这些字节。A 和 B 不一致，出来的就是天书。我在一次数据迁移中就亲手制造过”双重编码”的灾难——UTF-8 字节被当 Latin-1 存进数据库，后又从数据库读出来再当成 UTF-8 编码一遍，结果汉字彻底变成了不可恢复的乱码。修复那次数据花了整整一上午。
4. URL 和 HTML 转义
\uXXXX 是 Unicode 码点的转义形式，在 JSON、JavaScript 和 CSS 中广泛使用：
{"greeting": "你好"} // 等价于 {"greeting": "你好"}
HTML 里则是 &#xXXXX; 或 &#十进制; 的形式。这些转义机制让 Unicode 字符可以安全地出现在那些原本不支持非 ASCII 字符的上下文中。
5. GBK 与 UTF-8 的互转
在国内开发环境里，GBK（国标扩展）仍然很多见——特别是 Windows 中文版和一些老旧系统。GBK 和 UTF-8 之间没有简单的换算公式，必须通过 Unicode 码点作为”中间人”来转。流程是：GBK 字节 -> 解码为 Unicode 字符串 -> 编码为 UTF-8 字节。反之亦然。
常见误区
误区一：Unicode 和 UTF-8 是同一个东西
这大概是最普遍的误解了。Unicode 是字符集（规定了哪个编号对应哪个字符），UTF-8 是编码方案（规定了编号怎么存成字节）。就像电话号码系统——Unicode 是所有人的号码簿，UTF-8 是你拨号时实际按下的那一串数字编码规则。两者分工不同，但缺一不可。
误区二：不乱码就是编码正确
看起来不乱码，不代表编码就对了。我就见过一个文件，文本编辑器打开正常，但从浏览器上传后所有中文变成了问号。原因是文件用 GBK 保存，但 HTTP 请求头标的是 UTF-8。编辑器能正常打开是因为它自动检测了编码——用户的浏览器可不会这么好心地替你猜。
误区三：所有 emoji 都是 BMP 之外的高码点
很多常见 emoji 其实住在 BMP 里。比如 ❤（U+2764）、✓（U+2713）就在基本平面。不过现在新加入的 emoji 确实越来越多地分布在增补平面，特别是那些带肤色修饰的、合成家族表情的复杂 emoji。
Unicode vs 其他字符集
| Unicode | ASCII | GBK | Latin-1 | |
|---|---|---|---|---|
| 字符覆盖 | 全球所有文字 | 128 个（仅英文） | 中文字符集（约 2 万） | 西欧拉丁字母 |
| 编码长度 | 变长（UTF-8 1-4 字节） | 定长 1 字节 | 变长（1 或 2 字节） | 定长 1 字节 |
| 国际化支持 | 原生支持 | 不支持 | 仅东亚 | 仅西欧 |
| 互操作性 | 全球通用 | 英语世界遗留 | 中国遗留系统 | 西欧遗留系统 |
ASCII 是历史的起点——它只定义了 128 个字符，只够写英文。GBK 是中文环境的现实妥协，比 ASCII 多了两万多汉字。Latin-1 覆盖西欧语言但完全不懂东亚文字。Unicode 的设计目标就是终结这种”每个语言各搞一套编码”的混乱局面，而它确实成功做到了。
常见问题
Q: \uXXXX 和 \UXXXXXXXX 有什么区别？
\uXXXX 表示 BMP 内的 4 位十六进制码点，\UXXXXXXXX 表示完整的 8 位十六进制码点（用于增补平面）。Python 里两种写法都支持，JavaScript 里用 \u{XXXXXX} 表示增补平面字符。格式不同但最终指向的都是同一个 Unicode 码点。
Q: 怎么判断一个文本文件的编码？
靠”猜”——纯文本文件本身不存储编码信息（除非带 BOM）。工具用的是启发式检测：分析字节分布模式，看看它们符合哪种编码的规则。比如连续出现 1110xxxx 10xxxxxx 10xxxxxx 的三字节序列，大概率是 UTF-8 编码的中文。大多数代码编辑器（VS Code、Sublime）和 chardet 这个 Python 库都实现了这类检测算法。但启发式检测不是 100% 准确，短文本尤其容易误判。
Q: UTF-8 编码的中文为什么是 3 字节而不是 2 字节？
因为 BMP 中的中文码点都在 U+0800 ~ U+FFFF 这个区间内（除了一小部分在更低的范围），对应 UTF-8 的三字节模板。反直觉的一点是，GBK 存中文只需要 2 字节，UTF-8 需要 3 字节，所以纯中文文档用 UTF-8 存储反而比 GBK 稍微胖一些。但这点空间差距在如今的存储成本面前，跟 UTF-8 的跨平台兼容性比起来，根本不值一提。
Q: 什么是”锟斤拷”乱码？
“锟斤拷”是中文开发者圈子里一个著名的梗。它的诞生过程是这样的：UTF-8 字节被错误地用 GBK 解码，出来的结果中包含了某些在 Unicode 中也有对应字形的”巧合字符”，反复转码后最终形成了”锟斤拷”、“烫烫烫”这类固定乱码组合。看到这几个字基本可以确诊是 UTF-8 到 GBK 的误解码问题——它几乎成了一个诊断信号。
Q: Unicode 几乎容纳了全世界所有字符，那为什么还会出现乱码？
Unicode 本身不会导致乱码。乱码的根源永远是编码和解码时使用不一致的字符集。只要发送方和接收方约定好用同一种编码（而且两方都正确遵循了这个约定），就不会乱。现实问题是系统中各种组件各管各的——数据库、应用服务器、前端框架、操作系统，每个环节都可能”自作主张”转换编码。链路越长，出问题的概率越大。