Go x/text/unicode/norm Iter 怎样逐段遍历规范化文本

Go 的 golang.org/x/text/unicode/norm 提供了 norm.Iter，可以把字符串或字节切片按指定的 Unicode 规范化形式处理，并以规范化边界为单位逐段返回结果。最小用法是：选择 norm.NFC、norm.NFD、norm.NFKC 或 norm.NFKD，调用 InitString 或 Init，循环判断 Done，再读取 Next。

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

先选对 Form，再初始化 Iter

norm.Form 表示目标规范化形式。NFC 和 NFD 关注规范等价的组合与分解，NFKC 和 NFKD 还会处理兼容等价。业务要保存或比较哪一种形式，应由协议和数据规则决定，不能因为“结果看起来一样”就随意切换。

处理字符串时使用 InitString；已经拿到 UTF-8 字节切片时使用 Init。下面的辅助函数把每个片段交给回调，回调只在当前调用期间使用返回的字节：

package main

import (
    "fmt"

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

func eachSegment(text string, form norm.Form, visit func([]byte)) {
    var it norm.Iter
    // InitString 记录原始字符串，并指定后续 Next 使用的 Form。
    it.InitString(form, text)

    for !it.Done() {
        segment := it.Next()
        // segment 是当前规范化片段；回调不应把它留到下一轮以后使用。
        visit(segment)
    }
}

func main() {
    eachSegment("Mêlée", norm.NFD, func(segment []byte) {
        // 用 %q 显示转义后的字符串，便于观察组合字符。
        fmt.Printf("%q\n", string(segment))
    })
}

这里选择 NFD 是为了更容易看到一个带重音字符被拆成基础字符和组合标记。真实项目中，Form 的选择应和数据库、搜索索引或协议约定保持一致。

用 Done 和 Next 逐段读取规范化结果

Done 表示没有更多输入需要处理。每次调用 Next 会返回从当前位置开始、能够作为一个规范化片段处理的字节。修改字符会和前面的 starter 组合，因此它并不等同于“每次取一个 rune”。

可以把读取过程理解成“输入字节 → 目标 Form → 规范化片段 → 下一片段”，而不是简单按原始字符串的字符数切片：

func collectSegments(text string, form norm.Form) []string {
    var it norm.Iter
    it.InitString(form, text)

    segments := make([]string, 0, 4)
    for !it.Done() {
        // Next 返回的是 []byte；复制成 string 后再保存，避免依赖下一轮迭代的临时切片。
        segments = append(segments, string(it.Next()))
    }
    return segments
}

如果只是即时比较、统计或写入下游，可以在当前循环里消费 Next 的结果；如果需要把结果放进长期容器，转换成独立的 string 或复制字节更稳妥。不要把返回切片当成可以跨越后续迭代的永久缓冲区。

Pos 返回的是原始输入字节位置

Pos 表示下一次 Next 将从输入的哪个字节位置开始处理。Go 字符串按 UTF-8 字节保存，所以这个位置可能与 rune 数量不同，也可能落在一个多字节字符之后。记录原文切片、构建错误定位或做增量比较时，应该把它当作字节偏移。

func printOffsets(text string, form norm.Form) {
    var it norm.Iter
    it.InitString(form, text)

    for !it.Done() {
        start := it.Pos()
        segment := it.Next()
        end := it.Pos()
        // 两次 Pos 之间对应原始输入的字节范围，不代表规范化结果的字节长度。
        fmt.Printf("input[%d:%d] -> %q\n", start, end, string(segment))
    }
}

这段代码的关键是先记录 Next 之前的位置，再记录下一次起点。规范化后的片段长度可能与原始输入范围不同，因此不要用 len(segment) 推导原文的结束位置。

Seek 只跳到已经确认的片段起点

Seek 可以设置下一次 Next 的起始位置，并使用 io.SeekStart、io.SeekCurrent 或 io.SeekEnd 表示相对方式。官方文档把边界责任交给调用者：跳转位置必须是一个片段的起点，否则下一次规范化可能从组合序列中间开始，结果就不再符合预期。

package main

import (
    "io"

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

func skipFirstSegment(text string) []byte {
    var it norm.Iter
    it.InitString(norm.NFC, text)

    if it.Done() {
        return nil
    }
    // 先消费一个完整片段，当前 Pos 才是后续片段的已知起点。
    it.Next()
    boundary := int64(it.Pos())

    // 回到刚确认的边界；不要把任意 rune 下标当作 Seek 位置。
    if _, err := it.Seek(boundary, io.SeekStart); err != nil {
        return nil
    }
    if it.Done() {
        return nil
    }
    return it.Next()
}

这个例子故意只跳回自己确认过的输入边界。若没有明确的定位需求，直接顺序调用 Next 更简单；需要按边界切分时，也可以先考虑 Form.NextBoundaryInString，它适合只计算下一个边界而不维护一个迭代器。

大文本场景如何选择 Iter、边界函数和 Reader

Iter 适合已经拥有字符串或字节切片、并且希望逐段处理的场景。它的优势是可以用 Pos 建立输入偏移和处理结果之间的关系；代价是输入本身仍然由调用方持有。

常见问题

Iter.Next 返回的是一个 rune 吗？

不是。它返回的是按目标 Form 规范化后的一个字节片段。一个片段可以包含 starter 和跟随它的多个修改字符，也可能对应多个原始输入 rune。

Pos 是字节下标还是字符下标？

是输入的字节位置。对于 UTF-8 字符串，不能用 utf8.RuneCountInString 的结果直接替代它。

可以直接用任意位置调用 Seek 吗？

不建议。Seek 的位置必须由调用方保证是片段起点；如果位置落在组合序列中间，下一次规范化的上下文就可能被截断。

何时不需要 Iter？

如果只需要一次性得到规范化字符串，norm.NFC.String(text) 等方法更直接；只有在逐段处理、比较或需要保留原始偏移时，Iter 的控制能力才更有价值。

把 norm.Iter 用好，关键不是记住几个方法名，而是明确三条边界：Form 决定规范化目标，Next 决定返回片段，Pos/Seek 只围绕原始输入字节位置工作。顺序消费时使用 Done 和 Next，需要跨生命周期保存结果时再做一次明确复制，代码就不容易把 Unicode 片段误当成普通字符切片。