PHP Normalizer 的规范分解与兼容分解有什么区别

PHP Normalizer 的规范分解 NFD 对应 Normalizer::FORM_D，处理规范等价表示；兼容分解 NFKD 对应 Normalizer::FORM_KD，还会处理兼容等价字符。因此 NFKD 可能将全角字母、带圈数字等转成普通字符，代价是丢失部分表现差异。它不是“更严格所以总是更好”的替代品。

官方地址：https://www.php.net/manual/en/class.normalizer.php

先确定允许合并哪些字符差异

选择规范化形式，本质上是在选择应用如何看待字符差异。以带重音的字母为例，预组字符与基础字母加组合标记可以表示规范等价文本；而全角 A 与普通 A 的关系涉及兼容等价，不能在所有内容场景里都直接当作无关紧要。

例如检索系统想让部分排版形式更容易匹配，兼容分解可作为设计选项；需要原样展示、保存作品文字或区分特定符号时，则不能只保留这种转换后的文本。先定义业务允许忽略什么，再选常量。

用 FORM_D 与 FORM_KD 明确指定形式

Normalizer 属于 intl。调用 normalize 时显式传入形式，避免遗漏第二参数后实际采用默认 FORM_C。下面用同一字符串比较两种分解，示例未在本机执行。

示例中预组的 é 在分解形式下表达为 e 加组合锐音符；全角 A 和带圈数字 ③ 在 NFD 中保留其兼容区别，NFKD 则分别转为普通 A 与数字 3。这是按字符映射说明的预期，不是附带的实测日志。实际程序可查看十六进制，避免只靠字体外观判断。

注意重音标记并没有因为“分解”就被删除。NFD 和 NFKD 都不等同于去重音、转拼音或大小写折叠；如果搜索规则还有这些需求，应明确另外的处理步骤与适用范围。

把原文和比较键分开保存

一个清晰的实现方式，是将用户原文保留在展示字段，将规范化结果作为专门的比较键或检索输入。这样可以在匹配时采用约定规则，同时避免把用户输入的表现形式永久覆盖掉。

假设资料标题包含全角标识或带圈编号，业务决定检索时可以忽略这类差异，可以生成兼容分解的检索副本。但搜索命中后，仍展示原题名；不要将检索副本反向覆盖原文，再期待能准确恢复原来的字符形态。

是否需要一个独立数据库字段，取决于检索方式和数据量。这里推荐的是职责分离，不意味着所有项目都必须建立额外索引表。即使只在内存中比较，也应保存原始输入并明确所选形式。

识别不可用兼容分解替代的任务

NFKD 不能保证所有视觉相似字符都变成相同字符串，不能据此宣称解决全部同形字符问题。它也不是输入编码修复器，无法把任意非 UTF-8 数据自动识别成正确语言。输入来源不确定时，应先按协议确认编码。

涉及账户标识、签名或唯一约束时，更不能临时加一个转换就认为规则统一。若原本可区分的输入被处理为同一个键，应用必须明确冲突如何处理。规范化形式需要成为接口约定的一部分，而不是某个入口私下追加的“清洗”。

FORM_C 和 FORM_KC 还包含组合阶段，分别属于 NFC、NFKC。本文讨论分解，不能因为有兼容处理需求就把 KD 与 KC 当作同一个输出形式。

统一入口与查询的处理契约

写入与查询应使用相同的比较规则。若存储比较键用 NFKD，查询却只做 NFD，一些输入仍可能匹配不到。建议把规范化逻辑集中到一个明确函数，并记录选用的形式与失败处理方式。

已有数据要调整形式时，先评估转换后键的碰撞情况，并保留原文。不要在不知道冲突数量时批量覆盖旧值。normalize 返回 false 时也应单独处理，不能把失败当作空文本继续参与比较。

NFD 会删除重音吗？

不会。分解可能把重音表示成组合标记，删除标记属于另一项操作。

NFKD 后还能还原原来的全角或带圈写法吗？

不能仅凭转换结果保证还原。需要保留原文来满足原样展示需求。

直接不传 form 可以得到 NFD 吗？

不能，normalize 的默认形式是 FORM_C。要分解应显式指定 FORM_D 或 FORM_KD。

参考：PHP Normalizer 类说明、normalize 参数与返回值、Unicode 规范化形式标准附录。