Go unicode/utf8.ValidString 如何在协议边界拒绝非 UTF-8 字符串

Go 里的 string 不保证一定是合法 UTF-8，它只是保存一段字节序列。只要请求、消息或文件内容还没有经过文本边界校验，就可以先调用 utf8.ValidString(s)：返回 true 才继续解析，返回 false 就在协议入口拒绝。这样能避免损坏字节进入 JSON、日志或业务字段后才暴露问题。

先区分空字符串和非法 UTF-8 字节

utf8.ValidString 的判断对象是整个 string。普通 ASCII、中文等完整编码会通过；例如只保留一个三字节汉字的前两字节，就会得到非法序列。空字符串没有非法字节，因此结果也是 true。这点很容易和“字段必须有值”混在一起，实际应拆成两个规则。

package main

import (
    "fmt"
    "unicode/utf8"
)

func main() {
    valid := "订单-上海" // 完整的 UTF-8 文本。
    invalid := string([]byte{0xE4, 0xB8}) // 截断“世”的编码，故意制造非法输入。

    fmt.Println(utf8.ValidString(valid))   // true：可以进入文本解析。
    fmt.Println(utf8.ValidString(invalid)) // false：应在协议边界拒绝。
    fmt.Println(utf8.ValidString(""))      // true：合法性与非空校验是两回事。
}

把校验放在协议入口，失败就停止解析

如果字符串来自 HTTP body、消息队列或自定义帧，建议先完成字节层判断，再交给 JSON 解码或业务转换。下面的函数只表达“编码合法”这一层，空值和字段长度由调用方另行处理。

package boundary

import (
    "fmt"
    "unicode/utf8"
)

func checkText(payload string) error {
    if !utf8.ValidString(payload) { // 先拒绝不完整或非法的 UTF-8 序列。
        return fmt.Errorf("payload is not valid UTF-8") // 不把原始字节直接写入日志。
    }
    return nil // 通过编码检查后，才进入下一层解析。
}

在 HTTP handler 里，错误可以映射为 400 Bad Request；在队列消费者里，则应按协议约定进入死信或重试分支。不要把这类输入错误包装成服务端崩溃，也不要为了“尽量处理”而静默替换字节。

不要用 range 看到 RuneError 就当成校验结果

Go 遍历字符串时遇到编码错误会产生 utf8.RuneError，并按一个字节向前推进。这种行为适合继续遍历、显示替代字符或统计错误位置，却不等于输入通过了 UTF-8 校验。需要“拒绝还是接受”的协议决策时，直接看 ValidString；需要定位时，再用 DecodeRuneInString 记录偏移。

上线前把编码规则写进协议检查清单

1. 明确协议字段是否要求 UTF-8；若要求，就在入口统一调用 ValidString。
2. 把“合法但为空”和“编码非法”分成不同错误，避免客户端误改数据。
3. 记录字段名、请求 ID 和字节偏移等安全信息，不记录未经脱敏的原始内容。
4. 为截断的 2、3、4 字节序列补测试，并覆盖 ASCII、中文和 emoji。

相关问题

ValidString 对空字符串返回什么？

返回 true。它只检查编码合法性，必填约束要单独判断 s == ""。

把 string 转成 []rune 能修复非法 UTF-8 吗？

不能把它当作拒绝校验。转换过程可能产生替代 rune，原始字节信息会丢失；协议边界应先判断，再决定是否修复或展示。

Valid 和 ValidString 怎么选？

输入是 []byte 时用 utf8.Valid，已经是 string 时用 utf8.ValidString，两者都表达整段 UTF-8 合法性。

把 utf8.ValidString 放在边界层，核心价值不是“让字符串更像文本”，而是让协议对输入负责：合法文本继续流转，非法字节在最靠近来源的位置被明确拒绝。