regexp 处理无效 UTF-8 输入的替代方案

我第一次遇到这个问题，是在读取一段混合文本和协议字节的日志时：regexp.Match 没有返回错误，但匹配结果和按十六进制观察到的内容对不上。结论先说清楚：Go 的 regexp 按 UTF-8 码点工作，无效 UTF-8 输入中的每个异常字节会按 utf8.RuneError（U+FFFD）解释。如果业务必须保留原始字节，就不要继续用正则表达式硬匹配，应改用输入拒绝、文本规范化或 bytes 字节级查找。

先确认 regexp 到底匹配了什么

这里要区分两个问题：正则表达式本身能否编译，以及待匹配数据是不是合法 UTF-8。模式编译失败通常是括号、转义或字符类写错；输入包含无效字节时，MatchString 仍可能正常执行，只是它看到的不是原始字节序列。

Go 官方 regexp 文档明确说明：字符按 UTF-8 码点处理，按照 utf8.DecodeRune 的规则，无效 UTF-8 序列的每个字节都当作 utf8.RuneError。因此，下面的代码适合用来判断输入边界，但不能把匹配结果当作原始报文的字节证据。

package main

import (
	"fmt"
	"regexp"
)

func main() {
	// 0xff 不是合法 UTF-8；regexp 仍会把输入按 rune 解释。
	data := string([]byte{'A', 0xff, 'B'})
	re := regexp.MustCompile(`.`)

	// 这里得到的是 rune 语义，不是“匹配到了 0xff”这一字节结论。
	found := re.FindAllString(data, -1)
	fmt.Printf("matches=%q count=%d\\n", found, len(found))
}

所以，标题中的“替代方案”不是寻找一个隐藏的 regexp 字节模式开关，而是先明确数据模型：它是应该被修复的文本，还是必须原样保留的字节流。

文本输入：先拒绝，或者先规范化

如果字段约定是 UTF-8 文本，最稳妥的办法是在进入正则匹配前检查。无效时记录来源、长度或请求编号，然后返回明确错误；这样不会把一个损坏的输入悄悄转成 U+FFFD。

package main

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

var errInvalidText = errors.New("input is not valid UTF-8")

func findUserID(input string) (string, error) {
	// 文本协议先做 UTF-8 边界检查，避免把损坏数据当成普通字符。
	if !utf8.ValidString(input) {
		return "", errInvalidText
	}

	// 模式只负责提取字段；输入合法性由上面的边界负责。
	re := regexp.MustCompile(`user_id=([0-9]+)`)
	match := re.FindStringSubmatch(input)
	if len(match) != 2 {
		return "", errors.New("user_id not found")
	}
	return match[1], nil
}

有些日志清洗场景允许替换坏字节，这时可以用 strings.ToValidUTF8 把无效序列替换成指定字符串，再匹配替换后的文本。要在文档中说明：匹配结果属于清洗后的视图，不能用来证明原始数据中存在同样的字符。

package main

import (
	"regexp"
	"strings"
)

func matchCleanLog(input string) bool {
	// 用可见占位符替换无效序列，保留“这里发生过损坏”的线索。
	clean := strings.ToValidUTF8(input, "�")
	// 规范化后的文本适合做展示或宽松日志筛选。
	return regexp.MustCompile(`level=(WARN|ERROR)`).MatchString(clean)
}

字节输入：用 bytes 保留原始语义

协议魔数、文件头、压缩格式标记和二进制日志片段不应先强转成字符串再交给 regexp。它们关心的是某个字节序列是否出现，bytes.Index、bytes.Contains 或按位置切片更直接，也不会把无效 UTF-8 重新解释成 RuneError。

package main

import "bytes"

var gzipMagic = []byte{0x1f, 0x8b}

func isGZIPHeader(packet []byte) bool {
	// 文件头是字节协议，必须保留 0x1f、0x8b 的原始值。
	return len(packet) >= len(gzipMagic) && bytes.Equal(packet[:2], gzipMagic)
}

func hasMarker(packet, marker []byte) bool {
	// bytes.Index 按字节搜索，不做 UTF-8 解码或字符替换。
	return bytes.Index(packet, marker) >= 0
}

如果需求是“字节序列 + 少量固定字段”，可以先用 bytes 定位边界，再把确认合法的字段切片转成字符串交给 regexp。这样正则只处理文本字段，协议层仍由字节操作负责。

三种方案怎么选

我在工程里通常采用一个简单规则：先问“下游是否需要原始字节”。需要，就停留在 []byte；不需要，就在入口处验证或规范化成文本。不要用 .、\\xFF 之类的正则写法假装自己获得了字节模式支持。

边界问题

无效 UTF-8 会让 regexp 返回 error 吗？通常不会；它是输入语义问题。正则模式本身包含非法 UTF-8 时，才可能在编译阶段报告解析错误。

把 []byte 传给 Match 会不会自动切换到字节模式？不会。Match 仍遵循 regexp 的 UTF-8 码点语义；要做字节匹配，应使用 bytes 包。

什么时候可以直接替换坏字节？仅当业务接受信息损失，例如日志展示、搜索索引或宽松统计。鉴权、签名、文件格式和协议解析应拒绝或保留原始字节，不能静默替换。

最终可以把决策压缩成一句话：regexp 适合合法文本，ToValidUTF8 适合明确允许损失的文本容错，bytes 适合必须保持原样的输入。先选数据边界，再选工具，匹配结果才不会被误读。