Java Normalizer 怎样检查输入文本是否已经采用 NFC

如果数据库里看起来相同的文本比较结果不一致，先不要急着把所有字符串都改写一遍。Java 自带的 Normalizer.isNormalized 可以先回答一个更小、更明确的问题：输入是否已经采用指定的 Unicode 规范化形式。

本篇只讨论 NFC。最直接的写法是：

boolean alreadyNfc = Normalizer.isNormalized(text, Normalizer.Form.NFC);

返回 true 表示按 NFC 判断已经规范化，false 表示仍可能需要通过 Normalizer.normalize(text, Normalizer.Form.NFC) 得到规范化副本。检查本身不会修改输入，也不等同于“视觉上能不能看出来不同”。

官方地址：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/text/Normalizer.html

一、为什么肉眼相同还要检查 NFC

Unicode 允许同一个用户可见字符用不同的码点序列表达。以带重音的拉丁字母为例，它可以是一个预组合字符，也可以是基础字母加组合重音标记。字体渲染后两者可能看起来一样，但字符串的码点序列并不相同。

NFC 的目标是把字符序列整理为规范的组合形式。这里的“规范”是针对 Unicode 序列，不是把文字翻译、大小写转换或去掉重音。先做判断的好处是：已经符合 NFC 的输入可以直接复用，只有返回 false 时才创建新的规范化字符串。

二、用 isNormalized 检查输入是否已经是 NFC

isNormalized 接收一个 CharSequence 和一个 Normalizer.Form。因此 String 可以直接传入；第二个参数决定你检查的是 NFC、NFD、NFKC 还是 NFKD。下面的示例把两个看起来相近的输入放在一起比较。

import java.text.Normalizer;

public class NfcCheckDemo {
    public static void main(String[] args) {
        // 一个序列直接使用预组合字符，另一个由基础字符和组合标记组成。
        String composed = "caf\u00E9";
        String decomposed = "cafe\u0301";

        // 只检查，不改变原字符串；NFC 是本次判断的目标形式。
        boolean composedIsNfc = Normalizer.isNormalized(composed, Normalizer.Form.NFC);
        boolean decomposedIsNfc = Normalizer.isNormalized(decomposed, Normalizer.Form.NFC);

        System.out.println("composed -> " + composedIsNfc);
        System.out.println("decomposed -> " + decomposedIsNfc);
    }
}

这个实验的关键不是屏幕上显示的字形，而是传入的字符序列。第一个值通常已经是 NFC，第二个值通常不是 NFC，所以判断结果会形成一真一假。真实项目中不要把这个结果理解成“字符串合法性校验”；它只回答所选规范化形式是否成立。

三、返回 false 后再调用 normalize

检查和修正是两个动作。若业务要求写入 NFC，可以先判断，再对未规范化的值调用 normalize。这样做也方便在日志、指标或调试流程中区分“输入本来就是 NFC”和“输入被转换成了 NFC”。

import java.text.Normalizer;

public class NfcEnsureDemo {
    static String ensureNfc(CharSequence input) {
        // 调用者传入 null 时，给出清晰的参数错误，而不是让判断位置含糊失败。
        if (input == null) {
            throw new IllegalArgumentException("input must not be null");
        }

        // 已经是 NFC 的输入直接转成 String；只有 false 才执行规范化。
        if (Normalizer.isNormalized(input, Normalizer.Form.NFC)) {
            return input.toString();
        }
        return Normalizer.normalize(input, Normalizer.Form.NFC);
    }
}

这里使用 CharSequence 是为了让方法可以接收 StringBuilder 等文本序列，但返回值统一为 String，便于交给只接受不可变字符串的下游接口。规范化不是原地修改：原始对象仍由调用方管理。

四、空值、形式和异常边界

官方 API 对 src 或 form 为 null 的情况会抛出 NullPointerException。如果这是公共方法，建议在入口处用项目约定的参数检查转换成更容易定位的异常；如果只是内部代码，也至少要明确 null 不代表“尚未规范化”。

尤其要注意，NFKC/NFKD 会涉及兼容性映射，不能因为“看起来更统一”就替代 NFC。登录名、签名、协议字段、搜索键等场景需要先确定数据契约，再选择形式。

五、把判断放进实际数据流

如果文本来自表单、文件或接口，推荐在进入比较、去重或持久化边界时统一约定形式。对于只读查询，可以只调用 isNormalized 记录异常；对于必须满足数据契约的写入路径，再调用 normalize 生成待保存值。

最小决策可以记成三步：

1. 先明确业务契约是 NFC 还是另一种形式。
2. 用 Normalizer.isNormalized(input, form) 检查，不把检查当成转换。
3. 只有需要满足契约时，再用同一个 form 调用 Normalizer.normalize。

这样既能减少不必要的字符串创建，也能避免把 Unicode 规范化、大小写折叠和业务清洗混成一件事。

常见问题

isNormalized 会改变传入的 String 吗？

不会。它只返回判断结果。需要得到新值时调用 normalize，并接住它返回的字符串。

返回 true 是否代表文本只有 ASCII 字符？

不是。它代表文本符合所传入的规范化形式，包含非 ASCII 字符的文本也可能返回 true。

为什么不能直接用 normalize 后的结果和原文比较？

可以用来判断，但那会先执行转换；isNormalized 直接表达“是否已规范化”的意图，更适合把检查和修正分开。

总结

Java 检查 NFC 的入口是 Normalizer.isNormalized(text, Normalizer.Form.NFC)。它不改写输入，只返回 true 或 false；当结果为 false 且业务要求 NFC 时，再调用 Normalizer.normalize。最后别忘了区分 NFC 与 NFKC，并在公共边界明确处理 null。