Go x/text/unicode/norm 规范化后的字节长度为什么可能变大

Unicode 规范化统一的是码点表示，不保证 UTF-8 字节数变小。分解可能把一个码点展开成多个码点，兼容规范化也可能展开字符；即使 NFC 采用组合形式，组合排除等规则仍可能让某些输入变长。因此，保存前应针对规范化后的实际值检查字节限制。

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

规范化统一表示而不是压缩文本

假设一个标签字段在接收时满足字节上限，经过 norm 处理后却无法写入。首先要检查上限是否只应用在原始值上，而不是怀疑规范化库把字符编码错了。我更倾向把它设计成“确定存储表示”的环节：先明确采用哪种形式，再让下游长度与比较规则针对同一结果。

例如，NFD 可以将预组合的 é 表示为 e 加组合重音。前者的 UTF-8 长度是两个字节，后者为一个 ASCII 字节加两个重音字节，合计三个字节。这里是按码点和 UTF-8 编码规则推导的示例，不是本文执行日志。

区分字节、码点和可见字符

Go 的 len(string) 计算字节数；utf8.RuneCountInString 计算码点数量。一个由基础字符与组合标记构成的可见单位又不一定只有一个码点。所以“用户看起来还是一个字”与“存储字节增长”可以同时成立。

NFC 也不是“挑选最短编码”的算法。Unicode 规范列出了组合排除情况，U+0344 就属于非起始字符分解排除的例子。不能根据某些重音字符在 NFC 中会被组合，就推断所有输入都只会保持或缩短。

兼容形式还可能抹平某些表现差别。是否采用 NFKC 应根据搜索、标识比较或显示保真需求决定，不能单纯因为它看起来更“统一”就替换现有 NFC 规则。

把存储长度限制放在规范化之后

下面完整函数有两个不同上限：接收上限限制原始数据规模，存储上限限制实际保存值。它固定采用 NFC，不把不同规范化策略混在一个业务字段里。示例未执行，调用方应按项目依赖和字段定义使用。

package textstore

import (
    "fmt"
    "unicode/utf8"
    "golang.org/x/text/unicode/norm"
)

// NormalizeForStorage 用 NFC 统一表示，并检查实际要保存的字节数。
func NormalizeForStorage(input string, maxInputBytes, maxStoredBytes int) (string, error) {
    if maxInputBytes  maxInputBytes {
        return "", fmt.Errorf("原始输入超过接收上限")
    }
    if !utf8.ValidString(input) {
        return "", fmt.Errorf("输入不是有效 UTF-8")
    }
    value := norm.NFC.String(input)
    // 存储约束针对规范化结果，不能只检查原始输入。
    if len(value) > maxStoredBytes {
        return "", fmt.Errorf("规范化结果为 %d 字节，超过上限 %d",
            len(value), maxStoredBytes)
    }
    return value, nil
}

函数超过上限时明确返回错误，没有按字节强行截断。直接 value[:maxStoredBytes] 可能切断 UTF-8 编码；即便恰好落在码点边界，也可能截断组合序列。若产品需要截断，应单独定义字符或字素层面的规则，之后重新处理相关约束。

这份函数会先生成完整规范化结果，再检查存储大小，所以存储上限并不是严格的中间内存上限。原始接收上限必须合理配置；超大文本可考虑带资源上限的流式方案，不能把这段小字段示例原样当成无限文件处理器。

反例与缓冲区设计的取舍

一个容易出现的反例是：按 len(input) 创建同长度输出缓冲区，认为规范化不会扩张。使用 Form.String 或 Bytes 能减少自行管理缓冲区的工作；若直接使用 Transform，则需要按其短目标错误约定处理空间不足。norm 的文档还说明单次变换可能需要容纳一个完整片段，不能把“总空间还有剩余”误认为每次目标窗口都一定够用。

另一个反例是只保存原值的长度，却把规范化值用于索引、比较和展示。这样同一个字段的不同环节引用不同表示，报错难以解释。建议在存储接口清楚命名 raw 和 normalized 的用途，并让后续字节限制、哈希或比较针对规定的那一份值。

这里的模式是“固定表示，再应用结果约束”。它适合需要统一比较和保存的小型文本字段；需要原始输入保真的文档则可以另存原值，不应静默覆盖。长度增长本身没有证明内容变坏，也没有证明内容通过了其他业务检查。

常见疑问与判断清单

换成 NFC 就能保证不变长吗？不能。组合形式依照 Unicode 规则工作，不以最小 UTF-8 长度为优化目标。

RuneCount 没变，字节数就一定没变吗？不能。码点个数与每个码点的 UTF-8 宽度是不同维度。

只在入库前检查原始长度够吗？不够。若实际保存规范化结果，就要检查那个结果的约束，同时保留合理的输入资源限制。

分块后各自规范化再拼起来是否总相同？不能直接假设。块边界可能存在组合相互作用，应使用规范化边界或适当的流式接口。

决定接入方式时依次写清规范化形式、长度单位、原始输入上限、结果上限和超限行为，避免让“字符数”和“存储字节数”共用一个含糊限制。

参考：norm.Form.String、Unicode 规范化说明 UAX #15。