Go x/text/width Fold 为什么不等于 Unicode NFC

如果把全角字符转换成半角、再把组合字符合成为预组字符都叫“Unicode 规范化”，很容易得到错误结论。width.Fold 和 norm.NFC 的目标不同：前者处理字符的宽度变体，后者处理规范等价。一个字符串经过其中一个转换后没有变化，并不代表另一个转换也应该有变化。

官方地址：https://pkg.go.dev/golang.org/x/text/width

规范化包地址：https://pkg.go.dev/golang.org/x/text/unicode/norm

需要消除全角、半角差异时使用 width.Fold；需要让规范等价字符串拥有统一表示时使用 norm.NFC。两者可以出现在同一条处理链上，但不能互相替代。

先看两个转换到底改了什么

官方示例中的 width.Fold.String 会把 Ａ 变成 A，把半角片假名 ｦ 变成 ヲ，还会把某些宽度变体映射到对应的规范宽度字符。它观察的是字符的宽度属性，而不是字符是否能够通过规范分解和规范组合得到另一个字符串。

另一类变化是 e 与组合重音的关系。NFC 会把可以规范组合的序列表示成预组字符，例如 e + U+0301 变成 é。这不是宽度折叠，因为输入中的字符并没有全角、半角差异。

为什么 Fold 不等于 NFC

width.Fold 的文档把它定义为“把所有 rune 映射到其规范宽度”的转换器；同一页还特别说明，golang.org/x/text/unicode/norm 的 NFKC 和 NFKD 提供更通用的折叠机制。这里的“规范宽度”是 East Asian Width 语境中的宽窄变体，不是 Unicode Normalization Form C 的缩写。

NFC 的 C 是 Composition。它先进行规范分解，再进行规范组合，目标是维护 canonical equivalence。全角 A 与普通 A 属于兼容关系，通常不会因为 NFC 就自动消除；而 e 加组合重音与 é 属于规范等价关系，NFC 会让它们趋于同一表示。

用 Go 把差异打印出来

下面的最小示例故意同时放入全角 A 和组合重音。观察两个转换器的输出，就能看到它们各自负责哪一部分。代码中的注释说明了输入、转换目标和不应混淆的判断点。

package main

import (
    "fmt"

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

func main() {
    input := "Ａ e\u0301"

    // Fold 只处理全角、半角等宽度变体，不负责组合重音。
    folded := width.Fold.String(input)
    // NFC 处理规范等价的分解与组合，不负责把全角 A 改成普通 A。
    nfc := norm.NFC.String(input)

    fmt.Printf("原文: %q\n", input)
    fmt.Printf("Fold: %q\n", folded)
    fmt.Printf("NFC:  %q\n", nfc)
}

对这个输入，Fold 会改变全角 A，但会保留 e 与组合重音的结构；NFC 会把组合重音合成为 é，但通常保留全角 A。也就是说，判断“有没有变化”之前，要先问自己要消除的是宽度差异还是规范表示差异。

实际项目中怎样选择处理顺序

如果数据来自日文键盘、旧式 East Asian 编码映射或同时接受全角数字的搜索框，可以先做宽度折叠，再按业务决定是否做规范化。若字段的目标是 Unicode 规范表示，例如需要稳定比较等价文本，至少应考虑 norm.NFC。如果业务明确要消除兼容字符差异，才评估 norm.NFKC，因为兼容等价可能会丢失原本有意义的排版或语义区别。

func normalizeForLookup(s string) string {
    // 搜索键需要消除全角半角差异，先折叠宽度，再统一规范组合。
    s = width.Fold.String(s)
    return norm.NFC.String(s)
}

这段组合逻辑适合“搜索键、去重键、用户输入匹配”等明确允许宽度归一的场景，不应无条件套在原文存储上。原始文本、审计记录、需要保留排版差异的内容，应该保存原值，并在派生字段上做归一化。

四个容易误判的边界

最小结论

Fold 里的 fold 指宽度折叠，NFC 里的 C 指规范组合。前者回答“这个字符有没有对应的宽窄变体”，后者回答“这段 Unicode 序列怎样得到规范等价表示”。把两者放在同一条管道时，应按业务目标明确每一步，而不是因为都叫“规范化”就任选其一。

相关问题

• width.Fold 会不会把所有兼容字符都转成 ASCII？不会，它主要围绕宽度属性工作，不是通用兼容折叠器。
• 只做 NFC 能解决全角半角搜索吗？不能把它当作保证；全角半角属于兼容关系，应该显式评估宽度折叠。
• 为什么不直接对所有输入使用 NFKC？NFKC 更激进，可能抹掉业务需要保留的排版或语义差异。