Go unicode/norm 如何判断字符串规范化：NFC、组合字符与字节长度差异

用户昵称看起来一样，数据库里的唯一校验却把它们当成两条记录，排查时常会发现：一份文本把字母和组合音标分开存，另一份使用了预组合字符。Go 的 string 只保证保存 UTF-8 字节，不会自动把等价字符整理成同一种二进制形式。需要稳定比较时，可以用 golang.org/x/text/unicode/norm 先判断 NFC，再按需规范化。

把外部文本统一到 NFC 后再比较或建立索引；先用 norm.NFC.IsNormalString 判断是否已经规范化，只有返回 false 时才调用 norm.NFC.String，并把“字节数”和“字符数”分开记录。

为什么肉眼相同的字符串会比较失败

以带重音的拉丁字母为例，é 可以直接写成 U+00E9，也可以写成 e 加 U+0301 组合重音。两种序列在 Unicode 规范中具有 canonical equivalence，但 UTF-8 字节序列不同，所以 Go 的 == 比较不会替你做规范化。

package main

import (
    "fmt"
    "unicode/utf8"

    "golang.org/x/text/unicode/norm"
)

func main() {
    composed := "é"
    decomposed := "e\u0301"

    fmt.Println(composed == decomposed)
    fmt.Println(norm.NFC.IsNormalString(composed))
    fmt.Println(norm.NFC.IsNormalString(decomposed))
    fmt.Println(len(decomposed), utf8.RuneCountInString(decomposed))
}

这里第一个结果是 false，并不表示用户输入“错了”，只说明两个字符串的二进制表示不同。decomposed 的 len 是 3：字母 e 占 1 个字节，组合重音占 2 个字节；它的 rune 数是 2。

先判断 NFC，再决定是否改写输入

教程和数据清洗代码最容易犯的错，是每次无条件重建字符串。更稳妥的做法是把判断和修复分成两步：已经是 NFC 的文本直接沿用；不是 NFC 时调用 norm.NFC.String 得到规范化结果。

func normalizeNFC(s string) (string, bool) {
    if norm.NFC.IsNormalString(s) {
        return s, false
    }
    return norm.NFC.String(s), true
}

返回值里的布尔量表示是否发生过改写。导入任务可以据此统计脏数据来源，审计日志也能区分“原文已规范化”和“服务端修复后入库”。判断通过后再比较：

left, leftChanged := normalizeNFC(inputA)
right, rightChanged := normalizeNFC(inputB)
same := left == right
fmt.Println(leftChanged, rightChanged, same)

成功状态不是“字节数变小”，而是两边都满足 norm.NFC.IsNormalString，并且规范化后的字符串比较结果符合业务预期。

字节数、rune 数和用户看到的字符不是一回事

规范化会改变编码形式，不能把长度变化当成错误。len 返回字节数，utf8.RuneCountInString 返回 rune 数。emoji、组合音标和某些脚本还可能由多个 code point 组成一个用户感知的字素簇；如果产品限制的是“用户看到的字符数”，还需要引入专门的字素簇分割规则。

不要把 NFC 和 NFKC 当成同一个开关

NFC 保留规范等价的字符区别；NFKC 还会处理 compatibility equivalence，例如某些全角、兼容字符或排版形式。Unicode UAX #15 明确提醒，NFKC/NFKD 可能抹掉有语义的格式区别。因此登录名、搜索键、文件名等场景即使需要规范化，也应先定义业务规则，不能看到“更统一”就直接换成 NFKC。

一个实用边界是：正文输入、昵称或跨系统字段先约定 NFC；需要大小写不敏感、宽度折叠或标识符比较时，再把大小写折叠、兼容规范化和安全策略作为独立决策记录。别让一个叫 normalize 的函数偷偷完成所有转换。

上线前用一组等价输入做反向验证

测试至少覆盖预组合字符、组合字符、纯 ASCII 和无效 UTF-8。对于无效 UTF-8，utf8.RuneCountInString 会按替换 rune 计数，但 NFC 规范化不应被当成输入合法性校验；接口仍应先明确是否接受无效字节。

func TestNormalizeNFC(t *testing.T) {
    cases := []struct {
        name string
        in   string
        want string
    }{
        {"composed", "é", "é"},
        {"decomposed", "e\u0301", "é"},
        {"ascii", "Go", "Go"},
    }

    for _, tc := range cases {
        got, _ := normalizeNFC(tc.in)
        if got != tc.want || !norm.NFC.IsNormalString(got) {
            t.Fatalf("%s: got %q", tc.name, got)
        }
    }
}

验收重点是规范化后的值和 NFC 状态，而不是某个输入恰好有几字节。存储层若有唯一索引，也要在写入前统一规则，否则“先查后插”仍可能因为表示不同而漏掉重复。

相关问题

NFC 会把大小写统一吗？

不会。NFC 只处理 Unicode 的规范等价，大小写折叠应使用独立的业务或文本比较策略。

规范化后 len 一定变小吗？

不一定。它可能变小、保持不变，具体取决于输入的编码表示；不要用长度变化判断成功。

为什么字符串看起来一样仍然不该直接按 rune 数去重？

rune 数只描述 code point 数量，不能消除规范等价带来的不同字节序列。需要去重时先按约定的 NFC 规则得到比较键。

把 NFC 当作输入边界的一条明确规则，判断、转换、比较和长度检查各自承担单一职责，后续排查会比在数据库层临时补丁更容易。