Go Unicode 文本怎样在规范化前识别组合字符

我在做文本索引时遇到过一个很容易误判的情况：屏幕上看起来都是“é”，底层却可能是一个预组合字符 U+00E9，也可能是普通字母 e 后面跟着组合重音符 U+0301。两种写法的字节数、rune 数量都不同，直接按字节截断还可能把 UTF-8 字符拆开。

如果目标只是“在规范化之前找出组合标记”，Go 标准库已经够用：先用 unicode/utf8 按 rune 解码并记录字节边界，再用 unicode.IsMark 判断当前 rune 是否属于 Unicode 的 M 类标记。这个过程只识别结构，不负责把文本规范化成 NFC 或 NFD。

可复用的边界是：字符串先做 UTF-8 合法性检查；扫描时以 rune 前进、以 byte 偏移定位；看到 unicode.IsMark(r) 为真，就把它视为附着在前一个基字符之后的组合标记候选。不要把这个判断写成完整的用户感知字符分割器。

先把“一个字符”拆成三个层次

Go 的 string 是字节序列，len(s) 返回字节数。rune 是 Unicode 码点的别名，使用 utf8.DecodeRuneInString 可以得到当前码点和它占用的字节宽度。至于用户看到的一个字形，可能由多个码点共同组成，组合标记就是常见情况之一。

例如下面两段文本看起来接近，但编码结构不同：

// 预组合形式只有一个 Unicode 码点。
precomposed := "é"

// 分解形式由基字符和组合重音标记组成。
decomposed := "e\u0301"

fmt.Println(len(precomposed), utf8.RuneCountInString(precomposed))
fmt.Println(len(decomposed), utf8.RuneCountInString(decomposed))

这里的输出差异不是 bug，而是两种合法的 UTF-8 表示。若需求是按原文保存、定位或高亮，必须保留字节偏移；若需求是比较“视觉上相同”的文本，则还需要另一个规范化策略，本篇不把它混进标记识别。

用 utf8 解码，同时留下可回指的字节位置

扫描文本时不要先把字符串转成 []rune 再回头猜字节位置，因为那样会丢掉原始偏移与非法输入的处理上下文。更稳妥的方式是先检查 utf8.ValidString，然后在字节索引上调用解码函数。

package main

import (
	"fmt"
	"unicode/utf8"
)

type RuneSpan struct {
	ByteStart int
	ByteEnd   int
	Rune      rune
	Width     int
}

func scanRunes(s string) ([]RuneSpan, error) {
	// 先拒绝非法 UTF-8，避免把 RuneError 当成原文中的真实字符。
	if !utf8.ValidString(s) {
		return nil, fmt.Errorf("输入不是合法 UTF-8")
	}

	spans := make([]RuneSpan, 0, utf8.RuneCountInString(s))
	for byteStart := 0; byteStart 

ByteStart 和 ByteEnd 是半开区间，正好可以用于 s[ByteStart:ByteEnd]。合法 UTF-8 输入下，解码得到的 width 总会让循环向前推进；非法输入则在进入循环前返回错误。

用 unicode.IsMark 找出组合标记

unicode.IsMark 判断 rune 是否属于 Unicode 的 Mark 类别，涵盖非间距标记、间距组合标记和包围标记。它回答的是“这个码点是不是标记”，不是“浏览器最终会把哪些码点画成一个字素簇”。

package main

import (
	"fmt"
	"unicode"
	"unicode/utf8"
)

type MarkSpan struct {
	ByteStart int
	ByteEnd   int
	Rune      rune
	IsMark    bool
}

func findMarks(s string) ([]MarkSpan, error) {
	// 识别标记前先保证输入边界可靠。
	if !utf8.ValidString(s) {
		return nil, fmt.Errorf("输入不是合法 UTF-8")
	}

	marks := make([]MarkSpan, 0)
	for start := 0; start 

对 "e\u0301" 扫描时，字母 e 的 IsMark 是 false，U+0301 的结果是 true。对预组合的 "é" 扫描时，只会看到一个非 Mark 的码点，这正是两种表示在底层的差别。

把基字符和连续标记组成可用的扫描结果

实际业务通常不只想打印“某个 rune 是标记”，还想知道它属于哪个片段。可以在保持原始字节区间的同时，遇到普通 rune 就开启一个新片段，遇到 Mark 就扩展当前片段。开头就出现 Mark 时不要偷偷丢掉它，单独保留为孤立标记，交给上层决定如何处理。

type TextUnit struct {
	ByteStart int
	ByteEnd   int
	Base      rune
	Marks     []rune
	Orphan    bool
}

func groupBaseAndMarks(s string) ([]TextUnit, error) {
	if !utf8.ValidString(s) {
		return nil, fmt.Errorf("输入不是合法 UTF-8")
	}

	units := make([]TextUnit, 0)
	for start := 0; start  0 {
			// 连续标记仍属于当前逻辑片段，只扩展字节范围。
			last := &units[len(units)-1]
			last.Marks = append(last.Marks, r)
			last.ByteEnd = end
		} else {
			// 开头的标记没有基字符，保留为孤立标记而不是丢弃。
			units = append(units, TextUnit{
				ByteStart: start,
				ByteEnd:   end,
				Base:      r,
				Orphan:    unicode.IsMark(r),
			})
		}
		start = end
	}
	return units, nil
}

这个分组只是一个面向扫描任务的“基字符加连续 Mark”模型。它能服务于字节定位、输入提示和预处理统计，但不应被命名成 GraphemeCluster，因为 Emoji ZWJ 序列、区域指示符、换行规则等还需要更完整的字素簇算法。

规范化前最容易踩的四个坑

• 把 len 当成字符数。它返回字节数，不能用于截取第几个 Unicode 码点，更不能代表用户看到的字符数。
• 看到 RuneError 就断定原文有替换字符。合法文本本身也可以包含 U+FFFD；要区分它和非法 UTF-8，先检查 utf8.ValidString，或保留解码时的输入上下文。
• 用 IsMark 代替规范化。IsMark 只分类，不会把 e\u0301 变成 é，也不会把预组合字符拆开。
• 把连续 Mark 当成完整字素簇。这是一个实用的预处理分组，不覆盖所有 Unicode 排版和 Emoji 规则。

一张表记住处理边界

如果你的下游只需要定位、统计或提示组合标记，上面的扫描模型已经足够清晰；如果下游需要用户感知的光标移动、删除或相等比较，则应单独设计规范化和字素簇处理策略，继续保留原始字节偏移，避免把不同层次的“字符”混在一起。

相关问题

Go 的 range 能不能识别组合字符？

range 可以按 UTF-8 解码得到 rune 和字节起点，但它不会把基字符与组合标记合并成一个用户感知字符。仍需用 unicode.IsMark 或更完整的字素簇算法处理上层语义。

只判断非间距组合标记该怎么写？

可以把分类收窄为 unicode.Is(unicode.Mn, r)，但这会排除 Mc 和 Me。是否收窄取决于你的输入协议，不要默认把所有组合效果都归入 Mn。

为什么不在本文直接引入规范化库？

标题限定的是规范化之前的识别。识别与规范化是两个动作：前者记录结构，后者改变或统一表示。先把边界记录清楚，后续替换方案时才不会丢失定位信息。

资料参考：https://pkg.go.dev/unicode、https://pkg.go.dev/unicode/utf8