Go x/text/unicode/norm NFKC 为什么会改变兼容字符外观

会改变，而且这是 NFKC 的核心语义，不是 Go 把字符串“显示错了”。golang.org/x/text/unicode/norm 中的 NFKC 先采用兼容分解，再进行规范组合，因此全角字符、带圈数字、上标、连字等带有排版差异的字符，可能被折叠成普通字符序列。它适合在明确允许丢弃样式差异的标识匹配、检索或输入归一化场景使用，不适合无条件覆盖原始文章、数学公式或需要保留排版信息的文本。

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

NFKC 的“C”表示规范组合，“K”表示兼容处理。看到外观变化时，先问文本是否只需要核心字符意义；如果还要保留字体、宽度、上标等语义，就不要把 NFKC 当作默认清洗器。

为什么 NFKC 会改掉字符的外观

Unicode 区分两类等价关系。规范等价通常表示同一个抽象字符的不同编码表达；兼容等价则更弱，两个字符可能代表相近的抽象内容，但视觉外观或行为并不相同。Unicode UAX #15 把 NFKC 定义为“兼容分解后再规范组合”，所以它会主动消除一部分格式差异。

例如，下面几组输入的重点不在于“换了字体”，而在于它们被映射到了更适合比较的字符序列：

先用最小代码确认变化发生在哪里

Go 代码可以直接使用 norm.NFKC.String。示例把输入和转换后的字符串同时打印，便于在日志或测试中定位“外观变化”究竟来自哪一个规范化步骤。

package main

import (
	"fmt"

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

func main() {
	// 这些字符分别代表宽度、装饰、位置和连字差异。
	input := "Ａ①⁵fi"
	normalized := norm.NFKC.String(input)

	// 这里关注规范化后的比较值，不把它当作原文备份。
	fmt.Printf("原文: %s\\nNFKC: %s\\n", input, normalized)
	fmt.Println("是否已经是 NFKC:", norm.NFKC.IsNormalString(normalized))
}

这个示例的预期语义是把输入折叠为 A15fi 一类的普通字符序列，并且转换结果再次判断时已经处于 NFKC。注意：这只说明规范化结果稳定，不表示所有业务都应该保存转换后的值。

四种形式应该怎样选

NFC、NFD、NFKC、NFKD 的差别可以拆成两个问题：是否采用兼容分解，以及最后是否做规范组合。NFC/NFD 保留兼容字符的区别；NFKC/NFKD 会进一步折叠兼容差异。带 C 的形式会组合，带 D 的形式保持分解结果。

一个实用原则是：用于比较的副本可以 NFKC，展示给用户的原文仍保留原始字符串。不要用 NFKC 直接覆盖原文列，否则“上标”“全角”“带圈编号”等可能承载的排版信息就无法恢复。

字符串、字节和流式输入分别用哪个 API

短字符串优先用 String；已有 UTF-8 字节切片时用 Bytes；需要持续从输入流读取时，用 Reader 包装原始读取器。判断是否已经规范化则用 IsNormalString 或 IsNormal，避免为了“检查”而重复生成一份结果。

package main

import (
	"fmt"
	"io"
	"strings"

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

func readNFKC(input string) (string, error) {
	// Reader 会跨 Read 保留转换状态，适合处理分块输入。
	reader := norm.NFKC.Reader(strings.NewReader(input))
	data, err := io.ReadAll(reader)
	if err != nil {
		return "", fmt.Errorf("读取规范化文本: %w", err)
	}
	return string(data), nil
}

func main() {
	result, err := readNFKC("订单：Ａ①")
	if err != nil {
		// 真实服务中应记录上下文，但不要把原文当成可信指令执行。
		panic(err)
	}
	fmt.Println(result)
}

流式接口的重点是把规范化放在读取边界，而不是对每个分块独立调用 String 后再简单拼接。官方文档还提供 Transform、NextBoundary 等更底层能力；只有在需要控制缓冲或分段处理时才有必要使用。

迁移到 NFKC 前要做的回归检查

1. 把原文和用于检索、去重、匹配的规范化值分开存储，确认业务确实允许兼容差异消失。
2. 为全角/半角、带圈数字、上标下标、连字、分数和数学符号准备边界样例，分别确认展示值与比较值。
3. 检查数据库唯一键、缓存键和搜索索引是否只在预期字段使用 NFKC，避免不同业务字段互相污染。
4. 如果输入会分块到达，优先使用 norm.NFKC.Reader 或正确处理 transform.Transformer 的短缓冲错误。
5. 把 norm.NFKC.IsNormalString 放进断言或诊断日志，而不是把“已经规范化”当作肉眼可见的外观结论。

结论与常见追问

NFKC 改变兼容字符外观，是因为它不仅统一规范等价，还会执行兼容分解；这正是它帮助文本匹配的原因，也是它不能无脑处理原文的原因。Go 中先用 String 或 Bytes 生成比较副本，流式场景使用 Reader，再根据业务语义决定是否持久化转换结果。

为什么 NFC 通常不会把全角字符变成半角？

NFC 只处理规范等价，不执行兼容分解，因此会保留这类兼容差异；是否使用 NFKC 应由业务是否允许折叠来决定。

NFKC 能不能代替大小写转换？

不能。NFKC 解决 Unicode 兼容规范化，不等同于按语言规则做大小写映射；需要大小写处理时应单独选择相应的文本策略。

规范化后还能还原成原来的全角或上标吗？

通常不能可靠还原。规范化可能把多个外观不同的输入映射到同一个结果，所以需要保留展示或审计信息时，应保存原文。