Normalizer 怎样规范化为 NFC

把文本规范化为 NFC，可调用 Normalizer.normalize(text, Normalizer.Form.NFC)。比较两份输入时，两边都转换成同一种规范形，再比较得到的字符串；只处理其中一边，约定仍然不完整。

我更愿意把它封装成一个明确的“比较键”函数：原文用于展示，键用于需要规范等价的比较。这是本文的设计取舍，下面的小项目为原创演示，未声称已在本机运行。

Java API 依据：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/text/Normalizer.html。Unicode 规范依据：https://www.unicode.org/reports/tr15/。API 页面使用 Java 25 文档，本文并不要求升级到该版本才可调用 Normalizer。

项目目标：让名称比较遵守同一文本约定

假设一份联系人名单同时接受键盘输入和文件导入。名称 café 可能包含单个 é，也可能由 e 和组合重音构成。字符串比较关注字符序列，字体显示接近并不能建立相等关系。本项目只让规范等价的两种表示拥有一致比较键，不改变原始展示值。

NFC 采用规范分解和规范组合。它并不承诺每个可见字符都压成一个码点；没有相应预组合字符时，组合标记仍可能存在。也不要把 NFC 当成删除重音、拼写纠错或编码解码。

环境准备：一个文件即可说明问题

准备已安装且受项目支持的 JDK，把下面代码保存为 NfcNameDemo.java。所需依赖只有 java.text.Normalizer 和 java.util.Objects，无需引入文本工具包。文件名与 public 类名保持一致；使用 UTF-8 保存源文件，重音字符用 Unicode 转义表达，避免复制时难以区分字符序列。

核心代码：建立 NFC 比较键

import java.text.Normalizer;
import java.util.Objects;

public class NfcNameDemo {
    static String comparisonKey(String text) {
        // 缺失值由调用方处理，不把 null 偷换成空串。
        return Normalizer.normalize(
            Objects.requireNonNull(text, "名称不能为空"),
            Normalizer.Form.NFC
        );
    }

    public static void main(String[] args) {
        // 两种写法显示接近，但 UTF-16 序列不同。
        String composed = "caf\u00E9";
        String decomposed = "cafe\u0301";
        String leftKey = comparisonKey(composed);
        String rightKey = comparisonKey(decomposed);
        System.out.println("原文相等：" + composed.equals(decomposed));
        System.out.println("比较键相等：" + leftKey.equals(rightKey));
        System.out.println("比较键是 NFC：" +
            Normalizer.isNormalized(rightKey, Normalizer.Form.NFC));
        // 再次规范化不应改变已经规范化的比较键。
        System.out.println("重复转换一致：" +
            rightKey.equals(comparisonKey(rightKey)));
    }
}

comparisonKey 接受完整的逻辑名称，返回规范化字符串。这里明确拒绝 null；空串则仍然是合法字符串。真实表单是否允许空名称，是另一项业务校验。不要在函数内部同时偷偷 trim 或转小写，否则读者无法区分哪项规则导致了键变化。

本地运行：观察相等性与规范形

在源文件目录执行以下命令。命令只作为读者操作说明，本文没有执行并截取终端输出。

# 编译原创示例源文件。
javac -encoding UTF-8 NfcNameDemo.java
# 运行示例，读取四项布尔判断。
java NfcNameDemo

按代码和规范语义，四项判断依次应为 false、true、true、true。第一项直接比较不同的原始序列；第二项比较两份 NFC 键；第三项检查键是否处于 NFC；第四项说明重复规范化应保持一致。若实际输出不同，先确认运行的是当前类文件，以及输入转义没有在复制时被改写。

isNormalized 只是判定，不会替你转换原字符串。这个小函数直接 normalize 即可，不需要为了“优化”每次先判定再转换；是否值得增加检测分支应以真实负载为依据。

集成应用：保存原文和比较键

集成时可保存 originalName 和 nfcKey 两个字段。originalName 保留用户提交的原文，nfcKey 由 comparisonKey 生成；查询输入 queryText 也调用同一函数得到 queryKey。名称是否重复由 nfcKey 与 queryKey 的比较及业务规则共同决定。

修改名称时必须同步更新键。已有数据若过去没有该约定，应先计算并处理键碰撞，再决定是否建立唯一约束；规范等价名称可能属于不同业务记录，不能直接删除其中一条。数据库排序规则也可能扩大相等范围，因此应用层键规则与数据库唯一性语义需要单独协调。

完整名称拼接完成后再规范化。不能因为各片段已经是 NFC，就认定拼接结果仍是 NFC：边界处的基础字符与组合标记可能产生新的组合关系。保留原文后，未来调整业务匹配规则也更容易回溯。

验收与常见疑问

验收关注三件事：规范等价输入得到相同键；展示字段保留原文；写入和查询使用一致约定。对于不属于规范等价的输入，不应为了让测试通过而不断添加替换规则。

NFC 会统一全角和半角吗？

不能这样期待。宽度等兼容差异通常属于另一类规范化问题，NFKC 会处理兼容分解，但也会消除某些有意义的区别。当前项目只需要 NFC，不应无条件替换为 NFKC。

NFC 能让大小写或相似字母相等吗？

不能把它用作通用模糊匹配。大小写规则、语言相关比较以及视觉相似字符识别需要各自定义；NFC 也不负责证明账号名称安全或清除危险内容。

规范化会修复乱码吗？

不会。若字节已经按错误编码解码成错误字符，应先解决输入解码问题，再对正确得到的文本应用规范形约定。

是不是所有文本都应该覆盖为 NFC？

本文的选择是保存原文、另外建立比较键。需要保持原始字节、签名材料或用户原始输入的场合，应遵循对应协议约定，不能随意覆盖。对这个名称比较小项目，明确边界比扩大转换范围更有价值。