Go x/text/width 半角片假名扩宽为什么可能改变字符组合

在处理旧日文数据时，我遇到过一个看起来像“字符被拆开”的现象：输入里的半角片假名 ｶﾞ 经过 golang.org/x/text/width 的 Widen 后，视觉上仍然像“ガ”，但逐个读取 rune 时却变成了 カ 加一个组合浊音标记。这个结果并不是扩宽失败，而是宽度映射和 Unicode 规范化承担的职责不同。

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

半角片假名扩宽后可能改变字符组合，是因为 Widen 按字符宽度映射每个 rune；半角浊音符号对应的是组合标记。它不会自动把基字符和组合标记做 NFC 预组。如果业务需要预组字符，再显式调用 norm.NFC；如果要保留原始输入，则应把原文单独保存。

先分清 Widen 负责什么

width 包按 Unicode East Asian Width 相关属性处理字符宽度。官方文档把 Widen 定义为“在可用时映射到宽变体”的转换器，把 Narrow 定义为映射到窄变体；Fold 才是把字符映射到规范宽度的另一条路径。也就是说，Widen 的任务是改变宽度表现，不是把文本做完整的 Unicode 规范化。

半角片假名区间里，普通假名和浊音符号并不都是一个“看起来完整的字”。例如 ｶ 是半角片假名基字符，ﾞ 是半角片假名浊音符号。它们在输入中是两个 rune。扩宽后，基字符会变成全角的 カ，浊音符号会变成组合标记 ゙，于是仍然是两个 rune，但第二个 rune 的角色从半角符号变成了附着在前一个字符上的标记。

为什么视觉相同，字符组合却不同

Unicode 文本里需要同时区分 code point、rune 数量、字节数量和用户感知到的字形。半角序列 ｶﾞ 可以写成 U+FF76、U+FF9E；扩宽之后的序列可以写成 U+30AB、U+3099。后者是“片假名基字符 + 组合浊音标记”，它的视觉效果通常与预组字符 U+30AC（ガ）一致，但底层序列并不相同。

因此，下面这些判断不能混为一谈：

• 显示是否看起来像一个字：由字体和渲染器决定。
• 字符串包含几个 rune：由 code point 序列决定。
• 是否能与预组字符按字节相等：由是否做规范化决定。
• 是否能恢复用户输入：取决于有没有保留原始字符串。

如果下游按字节或按 rune 直接比较，ガ 和 ガ 可能不相等；如果下游按用户感知字符分组，组合标记又应该和基字符一起看。问题的关键不是强行选一个“正确字符”，而是在边界上说明你需要哪一种等价关系。

用 Go 观察 Widen 的实际序列

先只调用 width.Widen.String，把每个 rune 的 Unicode 编码、显示形式和 UTF-8 字节数打印出来。这个小实验故意不追加 NFC，方便观察宽度转换留下的组合序列：

package main

import (
	"fmt"
	"unicode/utf8"

	"golang.org/x/text/width"
)

func main() {
	input := "ｶﾞ"
	widened := width.Widen.String(input)

	// 分别打印输入和扩宽后的 rune，观察基字符与组合标记的变化。
	for name, text := range map[string]string{"input": input, "widened": widened} {
		fmt.Printf("%s: %q, runes=%d, bytes=%d\n", name, text, utf8.RuneCountInString(text), len(text))
		for _, r := range text {
			// %U 展示 code point，便于区分视觉相近但编码不同的字符。
			fmt.Printf("  %U %q\n", r, r)
		}
	}
}

这里应重点观察序列关系，而不是把某一次终端输出当作规范化结果：输入的两个半角 rune 经过 Widen 后仍可能是两个 rune，但第二个已经是组合标记。width.Widen 返回的是一个新的字符串，不会修改原始字符串。

需要预组字符时，再显式执行 NFC

如果索引、去重或协议字段要求使用规范组合形式，可以把宽度映射和规范化写成两个清晰的阶段。golang.org/x/text/unicode/norm 的 NFC 会按 Unicode Canonical Composition 规则处理可组合序列，因此扩宽后得到的基字符和浊音标记有机会合成为 ガ。

package main

import (
	"fmt"

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

func main() {
	input := "ｶﾞ"
	widened := width.Widen.String(input)
	composed := norm.NFC.String(widened)

	// 先统一宽度，再按业务要求合成规范形式；两步不要混成一个隐式规则。
	fmt.Printf("原文=%q\n扩宽=%q\nNFC=%q\n", input, widened, composed)
}

这个顺序很重要：直接把所有文本交给某个“万能清洗函数”会让宽度策略、规范化策略和原文保留策略失去边界。若业务只是为了统一显示，扩宽即可；若业务要稳定的规范形式，再追加 NFC；若业务要审计或回放输入，原文要在转换前保存。

把转换边界放在数据流入口

在文件导入、HTTP 请求或消息消费入口统一处理，通常比在多个业务函数里重复转换更容易维护。建议把原始值、展示值和比较值分开命名，避免一个字段既被当作用户原文，又被当作规范化索引键。

package textpolicy

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

// CanonicalJapaneseKey 生成用于比较或索引的宽度统一键，不负责保存原文。
func CanonicalJapaneseKey(input string) string {
	// 组合两种明确的文本策略：先扩宽，再按索引需求做 NFC。
	return norm.NFC.String(width.Widen.String(input))
}

// DisplayJapaneseText 只做宽度统一，保留组合序列的结构信息。
func DisplayJapaneseText(input string) string {
	// 展示层不擅自改变规范组合策略，避免把显示和存储语义混在一起。
	return width.Widen.String(input)
}

如果你的系统还要提供“原样下载”或审计记录，应该另存未经转换的输入；如果要做相等判断，则在进入比较和索引之前使用统一的键生成函数。需要注意的是，NFC 并不是任意字符都能合并，不能把“调用 NFC 后 rune 数一定减少”写成业务假设。

几个容易踩到的边界

1. 不要把视觉宽度当作字符串长度。 utf8.RuneCountInString、len 和终端显示列数回答的是不同问题。
2. 不要用 Widen 代替所有 Unicode 规范化。 它处理的是宽度变体，不负责大小写、组合、兼容分解等全部规则。
3. 不要丢掉原文。 规范化后的值适合比较和检索，但未必适合回显用户最初输入。
4. 不要只测普通片假名。 测试集至少应包含基字符、半角浊音符号、半角半浊音符号，以及已经是全角或没有可用宽变体的字符。

总结

半角片假名扩宽后出现字符组合变化，是 Unicode 数据表示的正常结果：width.Widen 逐个处理可映射的宽度变体，半角浊音符号可能成为组合标记；它不负责把组合序列自动合成为预组字符。实际工程中，可以按“原文保存、Widen 展示、Widen 加 NFC 比较/索引”这三个边界组织代码，既看得到统一显示效果，也不会误伤原始输入。

常见问题

Widen 会把所有日文字符都变成一个全角 rune 吗？

不会。它只在存在宽变体时映射，且一个半角符号可能对应组合标记，不能假设每个视觉字形都对应一个 rune。

为什么不直接使用 NFC？

NFC 解决的是规范组合，不负责把半角字符统一为宽字符。两者解决的问题不同，涉及日文宽度时通常应先明确是否需要 Widen。

什么时候保留 Widen 后的组合序列？

当下游需要保留 code point 结构、做逐步分析或仅关注显示时，可以保留；当下游要求规范组合形式时，再生成单独的 NFC 值。

如何避免转换后无法还原用户输入？

不要把转换结果覆盖原字段。将原始字符串作为输入记录保留，把展示值或比较键作为派生字段。