比较失败的根源
字符串比较是逐码点（或逐编码单元）进行的，而归一化形式决定码点序列：同一个语义的文本，NFC 下是预组合字符，NFD 下是基字符加组合标记，两者码点不同、字节长度也不同，因此相等判断为假、哈希值不同、唯一索引可能允许重复录入。这类问题在多来源数据合并时高发：前端输入法、macOS 文件系统、某些库默认输出 NFD，而其他环节按 NFC 处理。解决办法是统一形式，而不是在比较时「忽略差异」。
基本信息
| 根因 | 同一语义存在多种规范等价的码点序列 |
|---|---|
| 典型来源 | macOS 文件系统偏 NFD，Web 与多数后端偏 NFC |
| 表现 | 内容肉眼一致但比较为假、去重失效、唯一约束漏判 |
| 硬性做法 | 在数据入口统一归一化为约定形式后存储与比较 |
| 常用约定 | 存储与交换用 NFC，检索侧可另建分解形式索引 |
| 补充手段 | 哈希与签名同样要先归一化，否则同一内容得到不同摘要 |
典型使用场景
- 用户注册与登录：同一用户名的两种编码形式被当成两个账号
- 文件管理：跨系统拷贝后文件名不相等，同步与去重逻辑失效
- 数据合并：多个来源的数据按名称关联时出现漏匹配
- 缓存与哈希键：同一内容生成不同键，缓存命中率下降
- 接口契约：约定请求与响应统一使用 NFC，避免对接时反复排查
比较失败与修复
比较失败与修复
python -c "import unicodedata as u; a='\u00e9'; b='e\u0301'; print(a==b, len(a), len(b))" # False 1 2
python -c "import unicodedata as u; print(u.normalize('NFC','e\u0301') == '\u00e9')" # True：统一后相等
python -c "import unicodedata as u; print(hash('e\u0301') == hash('\u00e9'))" # 通常 False：哈希依赖码点序列
# 入口统一形式：所有写入与查询都先归一化
python -c "import unicodedata as u; key=u.normalize('NFC','e\u0301'); print(key)"
# 排查现有数据：统计同形不同码点的条目
python -c "import unicodedata as u; names=['caf\u00e9','cafe\u0301']; print(len({u.normalize('NFC',n) for n in names}), len(set(names)))"操作与归一化要求
| 操作 | 是否需要统一形式 | 说明 |
|---|---|---|
| 相等比较 | 必须 | 否则同义文本判为不等 |
| 哈希与缓存键 | 必须 | 码点序列不同则摘要不同 |
| 唯一约束与去重 | 必须 | 否则同形内容可重复录入 |
| 排序 | 建议 | 排序应使用语言相关 collation，归一化只是前置 |
| 长度校验 | 必须明确口径 | 两种形式长度不同，校验前固定形式 |
| 展示 | 建议 | NFC 更常见，渲染差异更少 |
「忽略差异」的临时方案代价很高：自定义比较函数会让哈希与索引失效，查询性能与一致性都会退化。正确做法是在入口处一次性归一化，让系统内部只存在一种形式。
历史数据往往已经混入两种形式：上线归一化之前需要一次数据普查与修复，并评估唯一索引会不会因此冲突（归一化后可能出现重复值）。修复前备份、先在副本上验证冲突数量。
归一化不能替代等价性判断的全部：除规范等价外还有兼容等价（全角、连字等），以及大小写与视觉相似字符。安全与去重场景常需要组合使用归一化、兼容归一化与字符映射表。