PHP Normalizer 怎样先判断字符串是否已经规范化

PHP 判断一个 UTF-8 字符串是否已经处于指定的 Unicode 规范化形式，可以直接使用 Normalizer::isNormalized()。它的第二个参数决定检查的是 NFC、NFD、NFKC 还是 NFKD；如果检查结果为 false，再用同一个形式调用 Normalizer::normalize()。这样可以把“是否需要转换”与“转换成哪一种形式”绑定在同一套规则里。

本文只讨论 PHP intl 扩展提供的 Normalizer API，不把视觉上相同、字节相同和规范化相同混为一谈。PHP 官方地址：https://www.php.net/manual/en/class.normalizer.php。

先区分视觉相同与规范化相同

Unicode 字符有时可以用一个预组合码点表示，也可以用基础字符加组合标记表示。用户看到的字形可能一样，底层字节却不同；这种差异会影响字符串比较、搜索键和持久化数据的一致性。

Normalizer 的目标不是把所有字符都变成某种“更漂亮”的形式，而是按 Unicode 定义的规则转换到应用选择的形式。PHP 手册列出了 NFC、NFD、NFKC 和 NFKD：C 形式包含规范分解后再组合，D 形式保留规范分解，KC/KD 还会处理兼容分解。应用要先确定自己的数据契约，再检查输入。

用 isNormalized 判断指定形式

Normalizer::isNormalized(string $string, int $form = Normalizer::FORM_C): bool 会检查字符串是否已经处于给定形式。省略第二个参数时，默认使用 Normalizer::FORM_C，也就是 NFC。若代码的存储契约不是 NFC，就应该显式传入形式，避免默认值掩盖业务意图。

返回值是布尔值：true 表示已经符合指定形式，false 表示尚未符合或发生错误。这里的 false 不是“可以无条件继续写入”的信号；后续仍然要调用 normalize，检查其返回结果。

如果运行环境没有启用 intl，代码无法使用 Normalizer 类。部署时应把 intl 作为 PHP 运行环境的一部分处理，而不是在请求中临时猜测扩展是否存在。文章中的代码用于说明 API 关系，不代表已经在本机执行。

只在未规范化时调用 normalize

Normalizer::normalize() 接收同样的字符串与形式，成功时返回规范化后的字符串，发生错误时返回 false。最稳妥的写法是复用检查阶段的 $form：检查 NFC 就转换 NFC，检查 NFKC 就转换 NFKC，避免两个阶段使用不同形式。

这段代码把失败显式抛出，调用方可以记录输入来源并返回可理解的错误。若业务允许丢弃异常字符，也要在更外层写出明确策略，不要把 false 强制转换成空字符串，否则会把转换失败伪装成合法空值。

四种形式怎样选择

默认选择 NFC 适合需要保持规范等价、同时希望文本保持较常见组合形式的场景；NFD 更接近拆分后的规范表示。NFKC 和 NFKD 会纳入兼容等价关系，可能改变某些字符的表示语义，因此不能因为“更统一”就无条件采用。

表格描述的是选择方向，不是对任何业务数据的自动推荐。尤其是账号名、法律文本、展示原文等场景，应先确认兼容折叠是否会丢失业务区分。

把检查放在输入边界而不是散落在查询里

如果同一字段在写入、查找和去重时使用不同形式，数据库里仍可能出现视觉相同但字节不同的键。更容易维护的做法是在输入边界确定规范化策略：先用 isNormalized 判断，再按同一形式转换，最后让后续存储和搜索复用这个结果。

不要用 strlen()、字节串比较或正则表达式代替规范化判断。它们可以回答长度、字节或模式问题，却不能回答“是否已处于指定 Unicode 规范化形式”。也不要把检查形式写成 NFC、转换形式写成 NFKC；这会让 true/false 的含义和最终数据契约错位。

常见问题

isNormalized() 的第二个参数可以省略吗？

可以，省略时使用 Normalizer::FORM_C。如果应用契约明确就是 NFC，省略也能工作；公共函数更建议显式传递或集中定义形式，让读者知道默认值不是偶然选择。

isNormalized() 返回 false 就一定是字符串损坏吗？

不一定。它可能表示输入不在指定形式，也可能表示发生错误。应按同一形式调用 normalize，并检查其 false 返回值，再决定记录、拒绝或返回错误。

为什么不直接每次都 normalize？

直接转换可以简化代码，但会让“已符合形式”的路径也经过转换。先判断能明确数据契约和分支语义；是否值得省略预判，应由实际调用成本、代码复杂度和错误处理要求决定，而不是把两种写法宣称为绝对优劣。

最终可以把规则收敛为一句话：先确定规范化形式，用 Normalizer::isNormalized() 检查该形式；只有结果为 false 时才调用 Normalizer::normalize()，并把转换失败作为失败处理。检查、转换、存储和搜索使用同一形式，才不会出现流程内部自相矛盾。