Go 正则处理非法 UTF-8 字节时结果异常怎么办

Go 正则处理非法 UTF-8 字节时，结果“异常”通常不是正则表达式突然换了规则，而是输入里混入了不完整或不合法的 UTF-8。regexp 会把非法序列中的每个字节按 utf8.RuneError（U+FFFD）解释，所以 .、字面量替代字符和返回索引都可能与直觉不同。官方文档可查：https://pkg.go.dev/regexp。

排查这类问题要先回答一个问题：业务允许原始字节存在，还是要求输入必须是合法 UTF-8？如果契约没有定清楚，直接改正则只能把问题藏到下一层。

先确认正则看到的是字节还是替代字符

Go 的字符串可以保存任意字节，并不因为类型是 string 就自动变成合法文本；[]byte 也一样。区别在于，正则匹配时会按 UTF-8 解码输入，遇到非法字节就把它当作一个错误字符。连续的非法字节通常会分别占据各自的一个错误字符位置，而不是组成一个业务字符。

因此，一个看起来很宽的 . 可能匹配到这些错误字符；相反，\p{L} 这类按 Unicode 属性匹配的表达式不会因为字节“存在”就把它当作字母。若表达式里直接写了替代字符 �，它还可能与输入中的非法字节产生语义重叠，这正是数据清洗和文本搜索中最容易被忽略的边界。

下面的代码只展示观察点：MatchString 面向字符串，Match 面向字节切片，但两者都不能把非法输入自动恢复成原始编码。

package main

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

func main() {
	// 0xff 是故意放入的非法 UTF-8 字节，用来观察输入边界。
	data := []byte{'A', 0xff, 'B'}
	re := regexp.MustCompile(`.`)

	// 先记录编码是否有效，不把匹配结果当成编码校验结果。
	fmt.Println("valid UTF-8:", utf8.Valid(data))
	for _, index := range re.FindAllIndex(data, -1) {
		// Index 返回的是原始输入的字节偏移，而不是字符序号。
		fmt.Printf("match bytes [%d:%d]\n", index[0], index[1])
	}
}

这个示例的重点不是某一行输出，而是不要用“能匹配到”推断“输入就是合法文本”。如果日志、搜索或替换需要保留原始字节，还应把原始 []byte 单独保存，避免先转成字符串再丢失来源信息。

先做 UTF-8 策略，再决定是否匹配

输入来自文件、网络协议或旧系统时，建议在正则之前明确策略。第一种是严格文本：发现非法字节就返回错误，适合用户名、配置字段和需要稳定 Unicode 语义的搜索条件。第二种是二进制兼容：保留原始字节，不把正则结果当成字符级结论。第三种是允许替换：把非法片段归一化后再匹配，但要记录替换策略。

unicode/utf8 的官方入口是 https://pkg.go.dev/unicode/utf8。对 []byte 可以使用 utf8.Valid，对已有字符串可以使用 utf8.ValidString；这一步只判断编码，不判断业务内容是否合规。

package textmatch

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

var tokenPattern = regexp.MustCompile(`^[[:alnum:]_-]+$`)

// StrictToken 只接受合法 UTF-8，再执行字符级正则匹配。
func StrictToken(data []byte) error {
	if !utf8.Valid(data) {
		return fmt.Errorf("输入不是合法 UTF-8")
	}
	if !tokenPattern.MatchString(string(data)) {
		return fmt.Errorf("输入不符合 token 规则")
	}
	return nil
}

// NormalizeToken 适用于业务明确允许替换的文本，不适合需要保留原字节的审计场景。
func NormalizeToken(data []byte) (string, error) {
	if len(data) == 0 {
		return "", fmt.Errorf("输入不能为空")
	}
	// 替换发生后再交给正则，调用方仍应保留原始 data 供排障。
	normalized := strings.ToValidUTF8(string(data), "�")
	return normalized, nil
}

不要把 strings.ToValidUTF8 当成万能修复：它解决的是非法 UTF-8 的表示问题，不会判断原始字节来自哪种编码，也不会恢复被截断的业务字符。若来源实际上是 GBK、Latin-1 或带协议头的二进制字段，应先按来源协议解码。

匹配成功后别把索引当字符位置

FindIndex、FindAllIndex 和带 Index 的方法返回的是字节偏移。中文字符通常占多个字节，非法字节按错误字符解释时又可能每个只占一个字节，所以“第几个字符”和“第几个字节”不能混用。

如果业务需要把结果展示给用户，应在确认输入合法后再做 rune 级计数；如果业务要回写原始协议或切片原始报文，则应继续使用字节区间。日志中同时记录输入是否通过 utf8.Valid、匹配方法以及索引单位，排障时才能复现同一边界。

把这类异常收敛成输入契约

修复完成后，建议把边界写进函数名或接口文档：严格文本函数接收合法 UTF-8，二进制函数明确只返回字节区间，规范化函数说明替换字符和原始数据的保留方式。这样后续维护者不会把某次偶然匹配当成通用编码规则。

还要避免两个常见误区：第一，看到 regexp 返回了结果就认为编码没问题；第二，只替换正则表达式而不记录输入来源。真正稳定的排查顺序是先判断编码，再决定是否拒绝或规范化，最后解释匹配语义和索引单位。

Go 正则遇到非法 UTF-8 的几个疑问

把 []byte 转成 string 后，非法字节会自动报错吗？

不会。类型转换本身不会完成 UTF-8 校验；需要显式调用 utf8.Valid 或 utf8.ValidString。

为什么 . 能匹配非法字节？

因为 regexp 会把非法序列中的每个字节按 utf8.RuneError 解释，而点号可以匹配这个非换行错误字符。它说明正则看到了一个可解释的 rune，不代表原始编码合法。

应该先替换非法字节再匹配吗？

取决于契约。需要保留原始报文时先拒绝或分离记录；业务允许容错文本时才规范化，并明确替换字符不会恢复原始编码。