Go unicode/utf8.Valid 怎样过滤无效 UTF-8 输入

Go 中过滤无效 UTF-8 输入，通常是在取得一条完整文本的原始字节后调用 utf8.Valid(raw)，返回 false 就拒绝该条输入。它只给出编码是否合法的判断，不会删除坏字节，也不会自动修复文本。已有字符串则可以直接用 utf8.ValidString(s)。

如果由我设计一个文本接收入口，我会先给请求体设大小上限，再读取完整内容、判断编码，最后进入业务处理。这样能把“传输未完成”“请求过大”和“编码错误”分开；不会让后面的展示、入库和索引各自猜测该怎样处理同一份坏数据。这里讨论的是设计取舍，下面代码为原创示例，未在本文中实际执行，也没有压测结果。

Go标准库官方文档：https://pkg.go.dev/unicode/utf8

把完整原始字节作为入口约束

让我最在意的细节是：Go 的 string 是字节序列，执行 string(raw) 并不意味着内容已经成为合法 UTF-8。若系统约定输入是 UTF-8文本，就应在仍能取得原始字节的位置明确处理错误，而不是把类型转换当成编码转换。Go语言规范：字符串类型。

以小型文本导入服务为例，输入边界可以由三部分组成：文本格式约定、请求体大小上限、编码有效性判断。格式约定决定是否接收其他字符集；大小限制约束本次读取的字节数；UTF-8检查判断完整字节序列能否按约定解释。三者不能互相替代。

我更愿意把“过滤”定义为不接收无效记录。对于用户名、业务键或需要精确匹配的字段，静默删除字节可能改变含义，甚至让不同原始输入变成同一个字符串；如果业务确实要修复，应该让这种变化成为明确的产品规则。

一个有大小限制的纯文本接收入口

下面的 Handler 只接收 POST纯文本，缺省字符集按本接口约定解释为UTF-8，显式声明其他字符集时拒绝。它也拒绝压缩内容编码，避免在没有解压策略的情况下把压缩字节当成文本。64 KiB只是样例阈值，不是UTF-8的限制。

package textgate

import (
    "errors"
    "io"
    "mime"
    "net/http"
    "strings"
    "unicode/utf8"
)

const maxTextBytes int64 = 64 

MaxBytesReader 约束读取量；io.ReadAll 出错就停止，不把已读到的前缀作为完整请求。代码中的204只表示本例入口接受，未包含鉴权、业务写入或消息投递。真实项目应在业务操作成功后再返回对应的成功响应。请求体限流、连接读取超时与并发控制仍需由服务配置处理，单个请求大小上限不等于服务整体资源上限。

这里保持 []byte 直接传给 Valid，避免为了判断合法性专门转成字符串。如果调用方本来就持有string，使用ValidString即可，不必为了同一目的来回转换。net/http：MaxBytesReader；unicode/utf8：Valid与ValidString。

还要确保检查后没有其他协程修改同一个字节切片。如果下游异步持有数据，切片所有权和必要的复制由调用链明确约定；一次Valid返回true，只描述当时的内容，不能替未来被改写的字节作保证。

诊断时区分无效字节与合法替代字符

Valid适合入口的是非判断。需要定位问题时，可以单独编写一个小函数，报告第一个无法解码位置的字节偏移。这里要同时看RuneError和解码宽度，不能看到RuneError就判错：合法的U+FFFD也会解码为该码点。

package textgate

import "unicode/utf8"

// FirstInvalid返回第一个无效编码起点的字节偏移；全有效返回-1。
func FirstInvalid(raw []byte) int {
    for offset := 0; offset 

按函数规则推导，[]byte{'A', 0xff, 'B'} 应返回1；[]byte("A\uFFFD") 应返回-1，因为这里的U+FFFD使用合法UTF-8编码；空切片也应返回-1。这些是示例的预期判断，不是本文展示的实际运行日志。若用户输入本来就含有替代字符，无法只靠这个函数判断它是否在更早的环节丢失过信息。

偏移以字节计，不是第几个汉字，更不是屏幕上第几个可见字符。向调用方反馈时说明单位，内部定位也要绑定输入记录。日志通常只需要记录错误类型、请求大小和偏移；不要默认把完整输入原文写入日志。

分块读取不能把每个块直接当成完整文本

在更大的文件或流式入口中，我不会对每个Read得到的块独立调用Valid后立刻拒绝。读操作的边界可能位于一个多字节字符中间：前一块包含起始字节，后一块包含剩余字节，拼接后合法，单块却不完整。

有明确大小上限的小文本可以像前面的Handler一样先读完整条目。确实需要流式处理时，应维护跨块的尾部状态：utf8.FullRune 用来判断当前前缀是否足以作出解码决定，DecodeRune 处理完整前缀；真正结束时仍有不完整尾部才按完整输入错误处理。FullRune返回true也可能意味着前缀已经能判为非法，并不等于这个字符合法。

正常未完成的UTF-8字符尾部最多涉及少量字节，但这不意味着把任何坏块末尾都缓存起来就正确。已经明确非法的前缀应及时处理；自定义流式状态还要处理读取同时返回数据和错误的情况。本文的HTTP样例选择有界完整读取，未实现通用流式解码器。

这是架构取舍：完整读取让错误处理简单，却保留了每个在途请求的内存成本；流式处理减少整条驻留的需要，却增加状态与结束条件管理。没有实际负载测量前，我不会为这两种方案编造吞吐提升数字。

有损展示与严格接收要分开

如果需求只是让历史文本能展示，可以使用单独的有损副本。例如以下代码用替代字符标出无效段，而原始输入的接收、留存或丢弃仍由上层策略决定。

package displaytext

import "strings"

// ForDisplay仅构造有损展示副本；调用方仍须保留原始数据处理策略。
func ForDisplay(raw string) string {
    return strings.ToValidUTF8(raw, "\uFFFD") // 每段连续无效编码用替代字符标记。
}

ToValidUTF8会将每一段连续的无效编码替换成指定字符串；替换字符串为空意味着删除。例子选择合法的U+FFFD，不应随意传入本身包含无效编码的替换字符串。修复后的文字不应冒充原始输入，也不应自动用作需要精确匹配的业务标识。strings：ToValidUTF8。

上线后的观察重点，我会放在拒绝数、读取失败数、超限数和来源分布，结合部署或调用方变更定位输入链路。不要把无效UTF-8全部归因于网络；上游编码约定不一致、截断、错误的字节切片处理也应列入排查。指标标签避免带原始文本、用户标识或任意偏移值，防止标签数量失控。

Valid能拦住所有乱码吗？不能。错误转码后的字节仍可能是合法UTF-8，语义已经错误；这需要回到来源编码和转换过程。

Valid通过就能直接输出HTML吗？不能。UTF-8有效性、HTML转义、权限和字段规则是不同问题；控制字符或不允许的业务内容也可能有合法编码。

检查后还要规范化吗？如果业务要求统一等价字符的表示，需要另外定义规范化规则。Valid不负责字符归一化，也不判断用户可见字符长度。

对于明确约定UTF-8的小型文本接口，我倾向于有界读取后严格拒绝无效输入；只有展示或兼容需求明确时，才引入单独的有损副本。把这两种策略分开，后续存储、搜索与问题定位才能知道自己拿到的是什么数据。