接手一个从 GBK 迁到 UTF-8 的老项目，最让人上火的往往不是迁移本身，而是那些"以为已经改完"的角落：数据库里躺着一排问号，配置文件第一行多了个看不见的字符，前端明明限制了 20 个字，用户却能塞进"半"个表情。这些问题追到最后，几乎都会撞到同一堵墙上——Unicode、码点、编码单元这三层概念没有分清。
这篇是我在几个项目里反复踩坑之后整理出来的 Unicode 入门笔记。重点讲清两件事：Unicode 到底用什么维度去组织这十几万个字符，以及这些分类在写代码、配数据库、改老工程时分别对应哪些具体动作。看完之后，你至少能自己判断一段乱码出在哪一层、该往哪儿修，而不是靠搜索引擎撞运气。
1. 乱码的表象之下：字符、码点、编码三层模型必须先分清
绝大多数"编码问题"最后都能归到一句话上：有人把三个不同层次的编号当成了同一个东西。只要这三层没分开，后面看什么规范都觉得绕。
1.1 一个字符从键盘到屏幕，中间换了三次身份
你在输入框里敲下一个"中"字，它在大脑里是一个概念，在内存里是一串数字，在硬盘上又是另一串数字。这三者之间的对应关系，就是 Unicode 这套体系要解决的问题。
- 抽象字符（Abstract Character）：人类认知里的那个"中"。它没有编号，只有含义。Unicode 标准里把这个层级叫"字符"，是信息的最小语义单位。
- 码点（Code Point）：给抽象字符分配的整数编号，写成
U+XXXX的形式。"中"对应的码点是U+4E2D，12973 这个十进制数字。码点是纯整数，跟存成几个字节毫无关系。 - 编码单元（Code Unit）/字节序列：真正写进内存或文件的东西。同一个码点
U+4E2D，UTF-8 写成 3 个字节E4 B8 AD，UTF-16BE 写成 2 个字节4E 2D，GBK 写成 2 个字节D6 D0。
我习惯用寄快递打比方：抽象字符是"收件人张三"，码点是"全国统一身份证号"，编码方案则是"用什么交通工具把这个人送过去"——同一个身份证号，坐飞机和坐高铁的行李形态完全不同，但人还是那个人。
理解了这一层，很多现象就顺了：String.length()返回的为什么不是"字数"？因为它数的是编码单元，不是码点。数据库字段VARCHAR(10)为什么装不下 10 个中文？因为在某些字符集里"10"指的是字节数。这些错位的根源，全在"层"没对齐。
1.2 "同一个字不一样"：GBK 时代留下的历史包袱
上世纪八十年代，各家都在自己造字符集：中国大陆的 GB2312、GBK、GB18030，台湾地区的 Big5，日本的 Shift-JIS，韩国的 EUC-KR，西欧的 ISO-8859-1。每个字符集只覆盖自己那块地盘，编号互相冲突。D6 D0在 GBK 里是"中"，在别的字符集里可能是完全不相干的符号。这就是那个经典现象的技术原因：同一串字节，换一个字符集去解读，就长出另一副面孔。
Unicode 做的事情，是把这些各自为政的编号体系收拢到一个统一地址空间里，给每个字符发一个唯一的码点，不管这个字符来自哪种文字。所以严格来说，Unicode 是"字符集 + 编码方案 + 一堆配套算法（归一化、排序、大小写、断行）"的合集，而不是单纯一张表。
顺带说一句，Unicode 和 ISO/IEC 10646 是两套并行推进的标准，字符内容和码点分配基本保持一致，只是措辞和发布节奏不同。你在文档里看到 UCS-2、UCS-4 这类说法，那是 ISO 那边的口径；UTF-16、UTF-32 是 Unicode 这边的口径。做业务代码时不用纠结，但读老文档时知道它们是同一件事的不同名字，能少绕很多路。
2. 码点空间是怎么划分的：17 个平面与它们的边界
Unicode 的地址空间不是从 0 一路排到无穷，而是被切成了 17 个等长的段，每段 65536 个码点，总共 1,114,112 个可用位置。这个数字很多人背过，但很少有文章讲清楚为什么要这么切。
2.1 从 BMP 到扩展平面：编号范围的切分逻辑
早期的 Unicode 设计者觉得 16 位足够装下全世界所有文字，于是第一段U+0000到U+FFFF被定为基本多文种平面（BMP）。后来中日韩的汉字实在太多，加上各种历史文字、数学符号、表情符号不断涌进来，16 位不够用了，才追加了 16 个辅助平面。
| 平面 | 码点范围 | 名称与主要用途 |
|---|---|---|
| 0 | U+0000 – U+FFFF | BMP，基本多文种平面。拉丁、希腊、西里尔、中日韩常用汉字、阿拉伯文等日常文字都在这里 |
| 1 | U+10000 – U+1FFFF | SMP，补充多文种平面。历史文字、音乐符号、数学字母、表情符号 |
| 2 | U+20000 – U+2FFFF | SIP，补充表意文字平面。CJK 扩展 B 及之后的汉字 |
| 3 | U+30000 – U+3FFFF | TIP，第三表意文字平面。较新版本的 CJK 扩展区 |
| 4 | U+40000 – U+4FFFF | SSP，补充特殊用途平面。已分配的字符极少 |
| 5–13 | U+50000 – U+DFFFF | 尚未分配，留给未来 |
| 14 | U+E0000 – U+EFFFF | 特殊用途，如标签字符、补充变体选择符 |
| 15 | U+F0000 – U+FFFFD | 私有使用区 A |
| 16 | U+100000 – U+10FFFD | 私有使用区 B |
这张表看着枯燥，但有两个地方很实用。第一，SMP 里躺着大量表情符号，U+1F600到U+1F64F这一片是表情区，理解它们为什么在 UTF-16 里要占 4 个字节，就得先知道它们不在 BMP。第二，SIP 和 TIP 承载的是生僻汉字，如果你的系统里有姓名、古籍、地名类数据，这些平面是绕不开的——很多老系统只支持 BMP，一遇到扩展区汉字就直接丢字或写问号。
2.2 代理区、非字符、私有使用区：地址空间里的三类特殊地带
平面划分是粗粒度，再往下看，还有几块"特殊用途地带"，它们不装普通文字，但每一块都能在实战里坑人。
代理区U+D800–U+DFFF。这 2048 个码点在 Unicode 里永久保留，永远不分配给任何字符，通用类别是Cs（Surrogate）。它们的唯一用途是让 UTF-16 表达超出 BMP 的字符：一个高位代理（D800–DBFF）配一个低位代理（DC00–DFFF），拼成一个补充平面字符。反过来说，如果你在 Java 或 JS 里看到一个孤零零的\uD83D后面没跟着低位代理，那基本可以断定是字符串被截断了，这串数据是坏的。这个判据我在排查线上问题时用得非常多。
非字符（Noncharacter）。一共 66 个位置：U+FDD0到U+FDEF这 32 个，加上每个平面最末尾的两个码点U+xFFFE和U+xFFFF（17 个平面共 34 个）。它们永久保留、不用于任何字符，标准允许你把它们用在内部协议里做标记，但不建议对外交换。我见过一些加密和校正算法故意用U+FFFF做哨兵，就是因为知道它永远不会被真实文本占用。
私有使用区（PUA）。BMP 里U+E000到U+F8FF这 6400 个位置，加上平面 15、16 两大片，都属于私有使用区。这里的码点不定义含义，谁用谁自己约定。字体图标方案大量依赖它——把图标字形塞进 PUA 码点，然后通过字体文件渲染出来。好处是不会跟正常文字冲突，坏处是换一台没装字体的机器就全变成方框，而且复制出去的文字在别人那儿毫无意义。现在更推荐用 SVG 或图标组件替代，但维护老项目时你得知道这一层。
2.3 码块（Block）才是查表时真正用的"行政区划"
平面是"省"，码块（Block）才是"县"。Unicode 把码点空间按用途和文字系统细分成几百个块，每块有名字和范围，比如Basic Latin（U+0000–U+007F）、CJK Unified Ideographs（U+4E00–U+9FFF）、Hangul Syllables（U+AC00–U+D7A3）、Emoticons（U+1F600–U+1F64F）。
这里有个很容易混淆的点：码块和字符类别是两套独立的分类维度。一个码块里可以混着字母、标点、符号；同一种字母也可能横跨好几个码块。做字符筛选时用类别，做区间判断时用块。我在做敏感词过滤和字形回退（font fallback）时，基本都是靠块范围做快速判断，因为块边界是连续的，比逐个查类别快得多。
3. 字符的横向分类：General Category 与那些容易忽略的属性
如果说平面和码块是"住在哪儿"，那 General Category 就是"什么身份"。写正则、做校验、处理文本长度的时候，真正起作用的是后者。
3.1 字母、标记、数字、标点、符号、分隔符：30 个类别的骨架
Unicode 给每个码点定义了通用类别，一级大类七个字母，二级细分到 30 个具体值。常用的那些值得记住：
| 类别 | 含义 | 典型例子 |
|---|---|---|
| Lu / Ll / Lt | 大写字母 / 小写字母 / 词首大写字母 | A、a、Dž |
| Lo | 其他字母（无大小写之分） | 汉字、日文假名、韩文音节 |
| Lm | 修饰字母 | ʻ（夏威夷语 ʻokina 常被写成撇号，实际是字母） |
| Mn / Mc / Me | 非间距标记 / 间距组合标记 / 包围标记 | ́ ́（组合尖音符）、部分东亚声调符号 |
| Nd / Nl / No | 十进制数字 / 字母数字 / 其他数字 | 0、Ⅻ、² |
| Pc / Pd / Ps / Pe | 连接符 / 破折号 / 左括号 / 右括号 | _ 、-、（、） |
| Sm / Sc / Sk / So | 数学符号 / 货币符号 / 修饰符号 / 其他符号 | +、¥、^、© |
| Zs / Zl / Zp | 空格分隔符 / 行分隔符 / 段分隔符 | 普通空格、全角空格、不换行空格 |
| Cc / Cf / Cs / Co / Cn | 控制符 / 格式符 / 代理码点 / 私有使用 / 未分配 | \n、零宽连接符、U+D800、PUA |
这张表在实战里的价值，比看起来大得多。举几个我真实遇到过的场景：
第一个是用户名校验。很多人写^[a-zA-Z0-9_]+$，结果海外用户用带变音符号的名字注册不了；改成\p{L}\p{N}_之后，汉字、阿拉伯文、带音标的拉丁字母全都能过，而且顺手把全角数字也挡掉了——全角数字０（U+FF10）的类别是Nd，一样算数字，如果你不希望它通过，就得额外加范围限制。
第二个是"空格"的判断。用户在输入框里粘了一段文本，trim()之后长度不为零，但看起来是空的。原因大概率是里头混了U+00A0（不换行空格）、U+2007（数字空格）或U+3000（全角空格），这些都不在trim()默认处理的范围内。用\p{Z}匹配一遍，问题立刻现形。
第三个是货币和金额。$是Sc（货币符号），但€在一些老字体里会被当成普通符号渲染，做金额正则的时候按\p{Sc}抓比手写符号列表靠谱得多，因为它跟着 Unicode 版本更新，新加入的货币符号自动覆盖。
需要注意的是，类别判断依赖 Unicode 版本。同一个码点在旧版本里可能是Cn（未分配），新版本里就变成Lo了。如果你在做长期运行的数据清洗，最好把 Unicode 版本号一起记下来，否则同一批数据在不同年份跑出不同结果是常有的事。
3.2 组合标记与归一化：为什么 é 有两种写法
"é"这个字符有两种完全等价的表示方式：
- 预组合形式：
U+00E9，一个码点搞定。 - 分解形式：
U+0065（拉丁小写 e）+U+0301（组合尖音符），两个码点。
两种写法在渲染上看起来一模一样，但字节层面完全不同。这就导致了三类经典事故：数据库唯一索引拦不住"重复"数据（因为字节不同）、字符串相等判断返回 false（因为码点序列不同）、按长度限制输入时计算结果不一致。
解决办法是归一化（Normalization），四种形式各有用途：
| 形式 | 全称 | 效果 | 适用场景 |
|---|---|---|---|
| NFC | 规范等价合成 | 尽量合并成预组合形式 | 数据存储、比较前的标准动作 |
| NFD | 规范等价分解 | 尽量拆成基字符 + 标记 | 需要单独处理音标的场景 |
| NFKC | 兼容等价合成 | 额外做兼容映射，如全角转半角、罗马数字转字母 | 搜索匹配、模糊比较 |
| NFKD | 兼容等价分解 | 兼容映射 + 分解 | 文本分析、索引构建 |
有一个真实的坑值得单独说：macOS 的文件系统在存储文件名时倾向使用 NFD，而 Linux 和 Windows 倾向 NFC。于是从 Mac 打包传到 Linux 的文件，用ls看着名字一样，脚本按文件名匹配却死活找不到。这类问题的排查套路是：先hexdump看看文件名的字节，比对一下码点序列，然后统一在入口处做一次 NFC 归一化。
还有一个更隐蔽的：NFKC 为了兼容会做激进映射，比如把全角字母Ａ映射成半角A，把上标数字²映射成普通数字2。做搜索时这是好事，用户输什么都匹配得上；但做密码校验时这是坏事，两串不同密码可能被归一化成同一个值。所以我的习惯是——存储原文不归一化，比较时归一化，密码这类场景一律禁止归一化处理。
3.3 控制符与格式符：看不见却能引发生产事故
格式符（Cf）这一类，是我认为最需要单独拎出来讲的。它们的共同特点是：占位置、有语义、但屏幕上什么都看不见。
U+200B零宽空格，用于允许断行的位置，不产生空白。U+200C零宽非连接符，阻止相邻字符连写。U+200D零宽连接符，把多个字符粘合成一个字形，表情符号的"一家四口"就是靠它串起来的。U+200E/U+200F左右书写方向标记，混排阿拉伯文和中文时用得上。U+FEFF零宽不换行空格，也是字节序标记（BOM）的真身。U+00AD软连字符，只在断行时显示为连字符。
这些字符被带进业务数据的途径特别多：从网页复制、从 PDF 提取、从 Office 文档粘贴、第三方接口返回。造成的后果包括但不限于——用户昵称显示为空白、搜索关键词匹配不上、JSON 解析首字段失败、CSV 导入首列变成乱码、短信模板字数统计对不上。
处理思路其实很简单，做一次"不可见字符清洗"：把所有Cf类别的字符（保留必要的U+200D）过滤掉，把各种花样空格统一替换成普通空格。这个清洗动作我一般会放在数据入口，也就是接口接收参数的第一步，越靠前越好，因为一旦这些字符进了数据库，后面每个查询都得防。
4. 编码方案的分类：UTF-8、UTF-16、UTF-32 的取舍逻辑
码点是"概念上的编号"，UTF 系列才是"怎么把它变成字节"。三者没有优劣之分，只有适配场景的不同。
4.1 UTF-8 的字节构造与自同步特性
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+4E2D的二进制是0100 1110 0010 1101，落进第三档，按 4-6-6 切开得0100、111000、101101。填进模板：
- 首字节：
1110+0100=1110 0100=E4 - 第二字节：
10+111000=10 111000=B8 - 第三字节：
10+101101=10 101101=AD
得到E4 B8 AD，跟前面说的一致。这个手算过程看着繁琐，但算过两三次之后，你看到乱码字节序列时的直觉会完全不一样——比如页面上出现是这种字符，你会立刻意识到它是 UTF-8 三字节被当成单字节字符集逐字节解释的结果。
UTF-8 真正的工程优势在于自同步：任何一个字节的高位模式都能立刻判断它是首字节还是后续字节（10开头一定是后续字节），而且一个字符的字节序列不会是另一个字符字节序列的前缀。这意味着即使数据流中间被截断，从任意位置往后扫最多三个字节就能重新找到字符边界。这也是为什么网络传输、日志文件、命令行工具普遍偏好它——丢几个字节不会导致整段文本全毁。
4.2 UTF-16 的代理对计算与字节序问题
UTF-16 用 16 位作为一个编码单元。BMP 内的字符直接一个单元，补充平面的字符用两个单元，也就是代理对。计算方式固定：
码点 = 0x1F602（笑哭表情） 减去 0x10000 → 0xF602 高位代理 = 0xD800 + (0xF602 >> 10) = 0xD800 + 0x3D = 0xD83D 低位代理 = 0xDC00 + (0xF602 & 0x3FF) = 0xDC00 + 0x202 = 0xDE02所以这个表情在 UTF-16 里是D8 3D DE 02（大端）或3D D8 02 DE（小端）。>> 10和& 0x3FF这两个操作不是随便定的：0xD800–0xDBFF和0xDC00–0xDFFF各 1024 个位置，加起来正好 2^20 = 1,048,576 个组合，刚好够覆盖补充平面的空间。这种"把剩余空间精确塞满"的设计，在协议设计里是很典型的做法，理解了之后你会发现很多看起来莫名其妙的位运算，背后都是这个思路。
字节序是 UTF-16 独有的麻烦。同一个 UTF-16 字符串，大端和小端存储的字节顺序相反，所以标准提供了 BOM（FE FF表示大端，FF FE表示小端）来标记。UTF-8 本身没有字节序问题，但有些 Windows 工具会在文件开头加上EF BB BF的 UTF-8 BOM，这就纯粹是历史习惯了。
4.3 选型对照：什么场景该用哪一种
| 方案 | 每字符字节数 | 优势 | 代价 | 典型场景 |
|---|---|---|---|---|
| UTF-8 | 1–4（ASCII 区 1 字节） | 兼容 ASCII、自同步、无字节序问题 | 索引定位需要扫描，随机访问慢 | 文件存储、网络传输、网页、数据库默认配置 |
| UTF-16 | 2 或 4 | BMP 内等长，索引相对简单 | 有字节序问题，ASCII 区浪费一倍空间 | 部分语言运行时内部表示、Windows API |
| UTF-32 | 固定 4 | 一个码点一个单元，随机访问最快 | 空间浪费严重，传输效率低 | 内部算法中间态、需要频繁随机访问的场景 |
我的实际选择逻辑很朴素：对外一律 UTF-8，对内看语言运行时。文件、接口、数据库、日志全部 UTF-8；Java 的String内部是 UTF-16，Python 3 的str内部按内容动态切换宽度，这些是运行时的事，不用你去干预，但你必须知道它存在——因为所有"长度不对""截断乱码"的问题都从这里长出来。
5. 把分类落到工程里：Java、数据库、嵌入式与接口的编码链路
规范看得再熟，最后还是要落到具体动作。这一节挑几个我实际改过、印象最深的场景。
5.1 Java 里 char 与码点的错位
Java 的char是 16 位，正好是一个 UTF-16 编码单元，不是码点。这个区别带来一连串后果：
String s = "\uD83D\uDE02"; // 笑哭表情 System.out.println(s.length()); // 2，不是 1 System.out.println(s.codePointCount(0, s.length())); // 1所以做长度校验、截取、字符遍历时，凡是用length()、charAt()、substring()的地方都是潜在雷区。substring(0, 1)会切出半个代理对，这个孤立代理在序列化成 UTF-8 时会被替换成U+FFFD（替换字符），页面上就显示成一个问号方块。
正确的姿势是：长度限制用codePointCount，遍历用codePoints()流，截断前先确认落点不在代理对中间。我在做昵称截断的时候习惯写个小工具方法——先按码点数量截到目标长度，再检查末尾字符是否是高位代理，如果是就再退一位。
另一个容易忽视的点是"ß".toUpperCase()结果是"SS"，长度变了；土耳其语的i大写转换依赖地区设置。涉及用户可见的文本转换，建议显式传Locale.ROOT，避免服务器地区设置变化导致结果漂移。
编码转换上也有一条铁律：读文件、读网络流时永远显式指定字符集，别用那些依赖平台默认编码的便捷类。
// 危险写法，结果取决于运行环境的默认字符集 new FileReader("data.txt"); // 明确写法 new InputStreamReader(new FileInputStream("data.txt"), StandardCharsets.UTF_8);后一种写法在实际项目里能省掉大量"本地正常、上线乱码"的扯皮。
5.2 数据库与连接层：utf8 与 utf8mb4 只差一个字节吗
MySQL 里那个经典问题值得再强调一遍：老版本的utf8名字听着是 UTF-8，实际上最多只支持 3 个字节，也就是只能覆盖 BMP，装不下表情符号和扩展区汉字。utf8mb4才是真正完整的实现。如果你的业务里有任何用户自由输入的字段（昵称、评论、聊天），用utf8就一定会在某天遇到"数据过长"或写入失败。
迁移的基本动作分三步走：
- 改表：
ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;。这一步会重建表，大表一定要挑低峰期，提前评估锁表时间。 - 改连接：连接串上显式声明字符集，或者初始化时执行
SET NAMES utf8mb4;。连接层的字符集如果没跟上，表改了也一样乱码，因为转换发生在客户端和服务端握手阶段。 - 改排序规则：排序规则影响大小写敏感性、重音敏感性。
utf8mb4_general_ci快但对某些语言排序不准，utf8mb4_unicode_ci更标准但略慢，utf8mb4_0900_ai_ci是较新版本的默认值。选哪个取决于你的业务是否需要严格的语言学排序——用户表按昵称排序、商品按名称排序这种需求，排序规则选错了会出现"应该挨着的结果离得很远"。
字段长度的计算也要跟着调。VARCHAR(10)在utf8mb4下指的是 10 个字符，不是 10 个字节，所以原本按字节算的容量评估表要重算一遍。转换完成后，一定要用一段包含生僻汉字、表情符号、组合字符的测试数据做一次端到端验证，不要只看"没有报错"就收工。
5.3 老工程迁移：从 GBK 到 UTF-8 的实际动作
嵌入式和老编译工具链里的编码迁移，坑点跟 Web 项目完全不同，因为字符串常量是被编译器直接编进二进制文件的。以 Keil MDK 这类工具链为例，大致要处理这么几件事：
- 源文件编码统一。把
.c/.h文件本身的编码从 GBK 批量转成 UTF-8。这一步最好按目录分批做，转之前先用版本控制打一个完整快照，转完立刻提交一次，方便出问题时逐个文件比对。批量转换后一定要检查是否有文件本来就不是 GBK（比如某个文件其实已经是 UTF-8 但没有 BOM），误转会直接毁掉中文注释。 - 编辑器编码设置。在 IDE 里把默认编码改成 UTF-8，否则你打开文件看到的是乱码，随手一保存就真把文件写坏了。这是最容易造成不可逆损失的一步。
- 编译器字符集选项。一些工具链提供多字节字符处理相关的开关，作用是告诉编译器以什么方式解释源文件里的字符串字面量。不同版本、不同编译器（armcc 与 armclang）选项名会有差异，具体以手头的手册为准，别照抄别人的博客。核心是让"源文件编码"和"编译器执行字符集"这两个设置一致。
- 串口与上位机对齐。设备端改了 UTF-8，PC 端调试助手还是按 GBK 收，照样乱码。通信协议里如果没约定编码，最好在协议文档里补上，或者干脆全部限定为 ASCII 字段，中文走单独的命令。
迁移过程中我的一个经验是：不要在字符串常量的字节长度上做假设。原来 GBK 下一个汉字 2 字节，转成 UTF-8 变成 3 字节，所有按字节分配缓冲区的地方都可能溢出。用sizeof或者字符数来算的地方基本安全，写死数字的地方全得翻一遍。
5.4 接口与前端的编码声明
Web 这一侧的问题通常集中在"声明"和"实际"不一致。
页面的编码由三层决定：HTTP 响应头Content-Type: text/html; charset=utf-8、HTML 里的<meta charset="utf-8">、以及文件本身的字节编码。三者的优先级是响应头最高，但有些服务器配置不当会把头里的字符集覆盖成默认值，导致页面里的 meta 声明形同虚设。排查这类问题的办法是打开开发者工具看实际响应头，别只看源码。
AJAX 请求这一块，用fetch提交 JSON 时默认就是 UTF-8，一般不用额外配置；用XMLHttpRequest手动设置contentType时，要跟服务端约定一致，否则可能出现服务端拿到的是 UTF-8 字节但按其他字符集解析的情况。表单提交则受页面编码影响，如果页面声明和实际不符，中文参数在服务端会直接变成乱码。
还有两个小细节值得记住：encodeURIComponent产生的百分号编码是基于 UTF-8 的，一个表情符号会被编成 12 个字符的%XX序列，所以用它算"URL 长度"时不能直接对应字符数；另外 URL 里的字符集虽然理论上由页面决定，但现代浏览器基本都按 UTF-8 处理，需要兼容老环境时才需要考虑其他情况。
6. 查文档之外的经验：几个高频踩坑点
规范文档里写得很清楚的东西，在真实环境里往往会以完全不同的面貌出现。这一节记录几个我自己反复撞上、也帮别人排查过的问题。
6.1 零宽字符与 BOM 造成的"诡异 Bug"
场景一：配置文件第一行读不出来。用户用记事本另存为 UTF-8，Windows 记事本默认加 BOM，于是文件开头多了EF BB BF。Java 或者某些解析库按 UTF-8 读取时，第一个键名会变成\uFEFFkey，跟代码里写的key永远匹配不上。看日志完全看不出问题，因为\uFEFF不显示。
排查方式很直接：把文件头三个字节打出来看看。修复方式有两种——读取时用能自动剥离 BOM 的方式，或者直接要求所有人用不带 BOM 的 UTF-8 编码保存。长期方案是加一条提交前检查，在流水线里扫描文件头，发现 BOM 就报错。这个检查成本极低，能省掉大量"我这明明没问题"的反复沟通。
场景二：CSV 导出中文乱码。反过来，把含中文的 CSV 导出给用户用 Excel 打开，如果不加 BOM，Excel 在某些版本下会按本地编码解释，中文全乱。这时候加 BOM 反而是正解。所以"带不带 BOM"没有统一答案，取决于消费方是谁——给程序读的不带，给 Excel 读的带。
场景三：字符串长度校验莫名失败。从网页表单复制一段文字粘进后台，前端校验通过，后端校验提示超长。原因是复制过来的内容里夹带了零宽字符，虽然看不见，但确实占长度。处理方式是在校验前先做不可见字符清洗，而不是放宽长度限制。
6.2 韩文音节与 CJK 字符的可复制对照表
做多语言测试时，手边准备一些"能直接复制"的字符很有用。下面这 20 个韩文音节都取自Hangul Syllables码块（U+AC00–U+D7A3），每个都是"初声 + 中声"的结构，终声为空，可以直接复制去测试输入框、数据库字段和字体渲染。
| 韩文 | 码点 | 初声 + 中声 |
|---|---|---|
| 가 | U+AC00 | ㄱ + ㅏ |
| 나 | U+B098 | ㄴ + ㅏ |
| 다 | U+B2E4 | ㄷ + ㅏ |
| 라 | U+B77C | ㄹ + ㅏ |
| 마 | U+B9C8 | ㅁ + ㅏ |
| 바 | U+BC14 | ㅂ + ㅏ |
| 사 | U+C0AC | ㅅ + ㅏ |
| 아 | U+C544 | ㅇ + ㅏ |
| 자 | U+C790 | ㅈ + ㅏ |
| 차 | U+CC28 | ㅊ + ㅏ |
| 카 | U+CE74 | ㅋ + ㅏ |
| 타 | U+D0C0 | ㅌ + ㅏ |
| 파 | U+D30C | ㅍ + ㅏ |
| 하 | U+D558 | ㅎ + ㅏ |
| 거 | U+AC70 | ㄱ + ㅓ |
| 고 | U+ACE0 | ㄱ + ㅗ |
| 구 | U+AD6C | ㄱ + ㅜ |
| 기 | U+AE30 | ㄱ + ㅣ |
| 노 | U+B178 | ㄴ + ㅗ |
| 도 | U+B3C4 | ㄷ + ㅗ |
这张表不是随便列的，它背后有一条可验证的公式。现代韩文音节是机械排列的：码点 =0xAC00+ (初声序号 × 21 + 中声序号) × 28 + 终声序号。
拿"거"验算：ㄱ 的初声序号是 0，ㅓ 的中声序号是 4，没有终声所以是 0，于是0xAC00 + (0×21 + 4)×28 = 0xAC00 + 112 = 0xAC70，跟表里一致。再验"기"：ㅣ 的中声序号是 20，0xAC00 + 20×28 = 0xAC00 + 560 = 0xAE30，也对。
这个公式的实用价值在于：你可以用代码生成或校验韩文，而不需要维护一张 11172 个字符的对照表。做国际化测试数据生成、字符集覆盖测试的时候，这种"按规则枚举"的方式比手工攒样本可靠得多。
同一思路也适用于 CJK。常用汉字区U+4E00–U+9FFF有两万多个位置，扩展 A 区U+3400–U+4DBF、扩展 B 区U+20000起的大片区域装着生僻字。测试字符集是否完整，最省事的做法是准备一组"分层样本"：常用汉字、扩展 A 的生僻字、扩展 B 的罕见字各取几个，加上表情符号和组合字符，一起塞进同一条记录里。如果这条记录能完整地写进去、读出来、导出来，字符集链路基本就是通的。
6.3 长度、截断与大小写转换的常见误判
最后集中说几个"看起来对、实际错"的写法，这些都是我在代码评审里反复看到的。
误判一：把length()当字数。前面讲过，Java 的length()数的是 UTF-16 编码单元，Python 3 的len()数的是码点，JS 的length又是 UTF-16 单元。三个语言三种口径。跨语言传递长度限制时，必须明确约定是按码点还是按编码单元，否则前端限制 20、后端按 20 个码点校验，中间就会错位。
误判二：直接substring截断。这会产生孤立代理，渲染成问号。安全做法是先检查边界。JS 里有Array.from(str)或扩展运算符可以按码点切分，Java 里有codePoints()，用这些再拼回去就不会切坏。
误判三：以为码点相同就是同一个字符。U+2160（罗马数字 Ⅰ）和U+0049（拉丁大写 I）在视觉上极其相似，NFKC 归一化会把前者映射成后者。这在安全场景里叫同形异义字攻击——用看起来一样的字符冒充用户名。做敏感场景（账号、域名、金额）时，建议在归一化之后再做一次"允许字符集白名单"校验，光靠肉眼和长度检查挡不住。
误判四：用码点顺序当排序顺序。码点顺序跟拼音顺序、笔画顺序、字母顺序都不是一回事。中文要按拼音排，就得用支持拼音的排序规则或专门的排序库；做多语言混排更要用 Unicode 排序算法，它定义了一套带权重层次的比较规则，能处理重音、大小写、标点忽略这些细节。自己写比较函数的结果通常是在测试数据上看起来对，真实数据一上来就露馅。
误判五：忽略归一化就做去重。用户用两种方式输入了同一个名字，字节不同，去重失效。存储时保留原样、做索引和比较时统一归一化成 NFC，是我目前觉得最稳的组合。
一路写下来会发现，Unicode 这套东西的难点从来不在"背下多少个码点"，而在于时刻清楚自己此刻处理的是哪一层——是抽象字符、码点，还是编码单元。想清楚这一层，剩下的规范细节都可以现查。下一篇我会接着把 UTF-8 的字节层面拆开，聊聊变长编码在索引、截断和流式解析里到底带来了哪些具体的工程约束。
