Go x/text/unicode/norm BoundaryBefore 怎样寻找安全切分位置

如果你需要把文本切成可独立规范化的片段，先记住一个容易混淆的点：BoundaryBefore 不会直接返回切分下标，它只回答“当前这个 rune 前面是否可以开始一个新的规范化片段”。真正要在完整字符串里寻找下一个边界，通常使用 norm.NFC.NextBoundaryInString 或对应的其他 Form。

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

先理解 BoundaryBefore 判断的对象

norm 包把一段文本能否独立转换到目标 Form 作为“边界”依据。Properties.BoundaryBefore 的语义是：当前 rune 开始一个新片段，不能与左侧任何 rune 组合。它适合检查一个候选切点，但它不是“给字符串分段”的完整迭代器。

这一区别很重要。一个基础字符后面可能跟着组合附加符，例如 e 后面跟组合重音。切在 e 与组合符之间，虽然字节偏移可能落在合法 UTF-8 rune 的边界上，却可能破坏规范化单元。

用 PropertiesString 扫描候选位置

如果你已经有一个从某个字节偏移开始的字符串切片，可以用 PropertiesString 查看它的第一个 rune，再调用 BoundaryBefore。下面的辅助函数返回“当前切片起点是否能作为新片段起点”，偏移仍然是 UTF-8 字节偏移。

package main

import (
    "fmt"
    "unicode/utf8"

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

// canStartSegment 判断 s 的起点是否是目标规范化片段的安全起点。
func canStartSegment(s string) bool {
    if s == "" {
        // 空切片没有第一个 rune，调用方应直接按边界处理。
        return true
    }
    _, size := utf8.DecodeRuneInString(s)
    if size == 0 {
        // 这里保留显式分支，避免把无输入与非法 UTF-8 混为一谈。
        return false
    }
    return norm.NFC.PropertiesString(s).BoundaryBefore()
}

func main() {
    // 组合重音跟在基础字符后面，切片从组合符开始时不能独立处理。
    text := "e\u0301x"
    fmt.Println(canStartSegment(text), canStartSegment(text[len("e"):]))
}

这个例子只检查“切片起点”的性质。若要遍历整个字符串，应先用 utf8.DecodeRuneInString 按 rune 前进，并把每个偏移处的切片交给 PropertiesString。不要用 len([]rune(s)) 反推字节切分位置，也不要把一次 Read 的结束位置当成规范化边界。

用 NextBoundaryInString 找完整规范化片段

在完整字符串里寻找下一个可独立处理的片段，NextBoundaryInString 更贴合任务。它返回第一个片段与后续片段之间的字节索引；返回值通常可直接用于 s[:n] 与 s[n:]。示例使用 NFC，换成 NFD、NFKC 或 NFKD 时，边界判断也会跟随目标 Form 改变。

package main

import (
    "fmt"

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

// splitNormalizedSegments 按规范化边界切出可独立处理的字符串片段。
func splitNormalizedSegments(s string) []string {
    var segments []string
    for len(s) > 0 {
        // atEOF=true 表示当前 s 已经是完整输入，可以确定尾部边界。
        n := norm.NFC.NextBoundaryInString(s, true)
        if n 

这里的 n 是字节索引，不是 rune 序号。调用方应保证后续切片仍然从完整 UTF-8 rune 的起点开始；NextBoundaryInString 的目的，是再加上规范化片段的约束。

处理 atEOF 与不完整分块

流式读取时，当前缓冲区的尾部可能只包含组合序列的一部分。此时把 atEOF 设为 false，让库表达“还不能确定”的状态：如果没有足够字节判断下一个边界，NextBoundaryInString 会返回 -1。正确策略是保留尾部、读取更多数据，再重新判断。

package main

import (
    "fmt"

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

// takeReadyPrefix 返回当前缓冲区中可以安全交给下游的前缀和待保留尾部。
func takeReadyPrefix(buf string, atEOF bool) (ready, rest string) {
    n := norm.NFC.NextBoundaryInString(buf, atEOF)
    if n 

如果调用方已经知道这是最后一块数据，就传 atEOF=true，让尾部也有机会成为可处理片段。对于更底层的转换循环，还要遵循 transform.Transformer 的返回约定，处理 transform.ErrShortDst，不能因为目标缓冲区一次写不下就丢弃未消费输入。

不要把规范化边界当成所有文本边界

因此，安全规范化切分只解决“规范化转换能否在这里独立继续”的问题。它不等于按屏幕看到的字符切分，也不等于删除重音、拆分词语或限制用户输入长度。做这些事情时，要在规范化边界之外另选对应的文本规则。

最后用一张清单落地

• 只想检查一个候选切点时，取该位置开始的切片，调用 PropertiesString(...).BoundaryBefore()。
• 要在完整文本中找下一段时，优先用目标 Form 的 NextBoundaryInString。
• atEOF=false 得到 -1 时保留尾部并继续读取，不要强行截断。
• 切片索引按 UTF-8 字节计算，不能把 rune 数当成字节偏移。
• 规范化边界、字素簇边界和业务字段长度是三类不同约束，分别处理更稳妥。

常见问题

BoundaryBefore 返回的是下标吗？

不是。它返回布尔值，描述传入切片第一个 rune 前是否存在规范化边界。需要下标时，应在扫描时维护 UTF-8 字节偏移，或使用 NextBoundaryInString。

为什么组合重音前的切点不安全？

组合重音可能与左侧基础字符一起构成同一规范化片段。把它单独交给下游，会让分块处理失去上下文，因此应等到更多输入到达。

atEOF 应该什么时候设为 true？

只有当调用方确认当前缓冲区已经是输入末尾时才设为 true。中间块设为 false，遇到 -1 就保留未确定的尾部。