Go utf8.DecodeRuneInString 为什么会返回 RuneError 和 1

看到 utf8.DecodeRuneInString 返回 RuneError 和 1，关键是不要把两个返回值当成同一种信息：RuneError 表示这次解码没有得到一个有效的 Unicode 码点，而 1 表示本次只消费了一个字节。空字符串也会返回 RuneError，但它的 size 是 0。

官方地址：https://pkg.go.dev/unicode/utf8#DecodeRuneInString

因此，非空字符串遇到无效 UTF-8 时返回 (utf8.RuneError, 1)，是为了让调用方丢弃当前这个无效字节后继续向前扫描；不能把 1 当成“RuneError 字符占一个字节”，也不能只看 rune 值判断输入是否损坏。

先把 RuneError 和 size 分成两条信息

DecodeRuneInString 只查看字符串开头的一个 UTF-8 编码。返回的第一个值是 rune，第二个值是这个编码在原字符串中占用的字节数。ASCII 字符通常是 1 字节，常见中文字符是 3 字节，四字节字符则可能占 4 字节。

RuneError 是 Unicode replacement character，写作 U+FFFD。它既可能是“解码失败时返回的替代符”，也可能是输入本来就合法地编码了 U+FFFD，所以还要结合 size 或整体有效性判断。

四种输入为什么会得到不同的 size

下面的对比把“没有输入”“合法的替换字符”和“无效字节”分开。示例中的字节串故意用 string([]byte{...}) 构造，这样可以表达普通源码字符串不方便直接写出的非法 UTF-8。

package main

import (
	"fmt"
	"unicode/utf8"
)

func main() {
	inputs := []struct {
		name string
		value string
	}{
		{"空串", ""},
		{"ASCII", "A"},
		{"中文", "中"},
		{"合法的 U+FFFD", "\uFFFD"},
		{"非法首字节", string([]byte{0xff, 'A'})},
		{"截断的三字节序列", string([]byte{0xe4, 0xb8})},
	}

	for _, item := range inputs {
		r, size := utf8.DecodeRuneInString(item.value)
		// size 是本次消耗的字节数，不是 rune 的“字符长度”。
		fmt.Printf("%-18s rune=%U size=%d valid=%t\n", item.name, r, size, utf8.ValidString(item.value))
	}
}

可以按下面的规则读结果：

为什么无效输入只让 size 等于 1

解码器不能擅自吞掉后面的字节。比如一个无效首字节后面紧跟着一个合法 ASCII 字符，如果一次跳过多个字节，调用方可能把本来可以识别的内容一起丢掉。返回 1 的策略让调用方拥有恢复方式：替换或记录当前坏字节，然后从下一个字节重新尝试。

这也是循环里必须使用 size，而不是写死 i++ 或遇到错误就退出的原因。对合法多字节字符，索引需要一次跨过 2 到 4 个字节；对无效输入，索引只前进 1 个字节。

循环扫描时怎样避免死循环

如果业务要求尽量保留可解码内容，可以在每轮取出当前切片，再根据 size 推进。因为空切片返回的 size 是 0，所以循环条件应先判断字符串是否为空，不要把“size 大于 0”当成唯一退出条件。

package main

import (
	"fmt"
	"unicode/utf8"
)

func printRunes(s string) {
	for len(s) > 0 {
		r, size := utf8.DecodeRuneInString(s)
		// 非空输入的 size 至少为 1，按它切片才能正确跨过多字节字符。
		fmt.Printf("rune=%U size=%d\n", r, size)
		s = s[size:]
	}
}

func main() {
	// 中间放入无效字节，观察扫描如何继续到后面的 A。
	value := string([]byte{0xe4, 0xb8, 0xad, 0xff, 'A'})
	printRunes(value)
}

这段写法会把无效字节报告为 U+FFFD、size=1，随后继续处理后面的 A。如果业务不允许任何坏字节，先用 utf8.ValidString(s) 整体拒绝，再进入后续逻辑会更清晰。

什么时候应该用 ValidString 或 ToValidUTF8

三个 API 的职责不同，按业务目标选择：

• DecodeRuneInString：需要逐个读取 rune，或者需要知道当前坏字节占用多少原始字节。
• utf8.ValidString：只关心整段字符串是否是合法 UTF-8，不需要逐字符恢复。
• strings.ToValidUTF8：允许清洗输入，并希望用指定替代串替换连续的无效字节。

不要用 strings.ContainsRune(s, utf8.RuneError) 代替有效性检查，因为合法输入本身就可能包含 U+FFFD。也不要把所有 RuneError 都当成同一种错误：结合返回的 size，或者先做整体有效性判断，才能区分真实字符和解码替代结果。

上线前可以按这张清单复查

1. 是否把 size 当成字节数，而不是字符数？
2. 循环是否按 s = s[size:] 推进，避免多字节字符被拆开？
3. 是否单独处理了空字符串返回的 size=0？
4. 是否需要整体拒绝非法输入，而不是边解码边替换？
5. 是否允许真实的 U+FFFD 出现在合法文本中？

记住这一点就够了：RuneError 说明当前 rune 结果是替代符，size 说明原字符串应该向前移动多少字节。遇到无效 UTF-8 时的 RuneError, 1，本质上是一个可恢复的字节边界信号。

相关问题

• 为什么中文字符的 size 常常是 3？ 因为 UTF-8 对这类码点使用三个字节编码，size 表示字节宽度。
• RuneError 本身一定代表错误吗？ 不一定，合法编码的 U+FFFD 也会得到 RuneError，但 size 通常是 3。
• 应该用 range 还是 DecodeRuneInString？ 只需遍历合法文本时 range 更简洁；需要精确处理非法字节边界时，DecodeRuneInString 更直接。