速查在线工具箱Unicode 规范化形式速查
看起来一模一样的两个字符串为什么不相等、NFC 与 NFD 差在哪、macOS 的文件名为什么在 Windows 上找不到——规范化四种形式的差别一次说清。
两个字符串在屏幕上分毫不差，代码里判断相等却返回 false；明明输入的是同一个词，搜索就是匹配不到。这类问题的根子多半是 Unicode 规范化。
同一个字符可以有多种合法的编码方式，Unicode 提供了四种规范形式来统一它们。选错了形式，字符串比较、文件名匹配、搜索索引都会出问题。
1四种规范形式
前两种只处理等价写法，后两种还会折叠兼容字符。
| 形式 | 全称 | 做什么 |
|---|---|---|
| NFC | 标准合成形式 | 把基字符与组合符合成预组合字符，日常文本首选 |
| NFD | 标准分解形式 | 把预组合字符拆成基字符加组合符，macOS 文件名传统用法 |
| NFKC | 兼容合成形式 | 先做兼容折叠再合成，全角转半角、连字拆开 |
| NFKD | 兼容分解形式 | 先做兼容折叠再分解，用于检索与模糊匹配 |
比较两个字符串前先统一规范化形式，是比逐字符比较更可靠的第一步。
2同一个字的多种写法
肉眼相同不代表码位相同，这是判断相等的最大陷阱。
| 字符 | 写法一 | 写法二 |
|---|---|---|
| é | 单码位 U+00E9 | e 加组合重音 U+0065 U+0301 |
| ① | 圈号数字 U+2460 | 兼容折叠后为 1 |
| fi | 连字 U+FB01 | 兼容折叠后为 fi |
| 全角Ａ | 全角 U+FF21 | 兼容折叠后为 A |
只做 NFC 或 NFD，全角与半角、连字与拆写不会被统一；需要跨写法匹配时用 NFKC 或 NFKD。
3实战里的几处坑
规范化不是可选步骤，而是字符串处理链路里的固定环节。
- 文件名跨系统
- macOS 存 NFD，Windows 存 NFC
- 搜索匹配
- 用户输入与索引未统一形式
- 去重与排序
- 按码位排序，等价写法落到不同位置
- 密码与校验
- 不做规范化，等价输入被判不同
- 兼容折叠的风险
- NFKC 会把全角变半角、圈号变数字
看完就能用的站内工具
全部工具总览 →关于「Unicode 规范化形式速查」的常见问题
为什么两个看起来完全一样的字符串判断不相等？
因为它们用了不同的码位序列表达同一个字形。例如带重音的字母既可以用一个预组合码位表示，也可以用一个基础字母加一个组合符表示，视觉输出相同但字节不同。比较之前先对两边做同一种规范化，再判断是否相等。
NFC 和 NFKC 该选哪个？
日常文本展示与存储优先 NFC，它只合并等价写法，不改变字符身份。NFKC 会做兼容折叠，把全角字母变半角、圈号数字变普通数字、连字拆成两个字母，适合搜索索引与模糊匹配，但不适合需要保留原貌的场景，比如用户在标题里特意用了全角字符。
macOS 上的文件名拷到 Windows 为什么会找不到？
macOS 文件名传统上使用分解形式存储，Windows 使用合成形式。同一串文字在两边字节不同，某些工具按原样比较就会匹配失败。处理跨平台文件名时，读入后先统一规范化再比较或查找，可以避免这类问题。
规范化会不会改变我原本输入的内容？
NFC 与 NFD 只在等价写法之间转换，视觉与语义都不变。NFKC 与 NFKD 会做兼容折叠，可能把全角转成半角、把特殊符号转成普通字符，视觉上会有差别。用于展示和存储时选前两种，用于比对和检索时选后两种，分开使用就不会串。
继续查：相关内容
全部速查 →内容说明：本页速查数据由本站自行整理，事实性内容以对应官方规范与文档为准，未复制第三方速查表或百科的表述。数据最后核对日期：2026-11-01。若发现错误或已更新的标准，欢迎通过页脚反馈入口告知。