如何在 Go 中强制处理含控制字符的 UTF-8 JSON 字符串

本文介绍如何安全解析包含 ASCII 控制字符（如 、）的 JSON 字符串，通过预处理将非法控制字符转义为标准 Unicode 转义序列（\uXXXX），从而绕过 json.Unmarshal 的语法校验失败问题。

在 Go 里，encoding/json 这个包是出了名的严格。它完全遵循 RFC 8259 规范，明文禁止在 JSON 字符串的字面量中直接出现 ASCII 控制字符（也就是 U+0000 到 U+001F 这个区间，不过制表符、换行符和回车符是例外）。所以，当你从日志注入、老系统导出或者非标准编码接口拿到一串 JSON，里面带着没被转义的  或  这样的字节时，json.Unmarshal 会毫不留情地抛出一个错误：invalid character '' in string literal。

其实，真正需要搞清楚的，是这几个问题：不是解码问题，而是合规问题；不是编码错误，而是协议限制；不是 Go 不够强，而是它选择了守规矩。

解决方案并不是去“强制 UTF-8 解码”——Go 的字符串默认就是 UTF-8 编码的。正确的做法，是对输入字符串做一次语义安全的预处理：遍历每一个 Unicode 码点（也就是 rune），把所有 unicode.IsControl(r) 返回 true 的字符，转义成 JSON 能接受的 \uXXXX 格式。注意，JSON 规范只认 \u 加四位十六进制，\x 或者 \U 都不行。这个思路跟 Ja va 里用 charset.encode().decode() 做净化的逻辑类似，但更精准——它只动那些非法的控制符，合法的文本内容一点不改。

下面就是这个可以直接上生产环境的处理函数：

package mainimport (    "bytes"    "encoding/json"    "fmt"    "unicode")// sanitizeJSONString 将字符串中所有 ASCII 控制字符（U+0000–U+001F）转义为 \uXXXX 格式，// 使其符合 JSON 字符串字面量语法，可被 json.Unmarshal 安全解析。func sanitizeJSONString(s string) string {    var buf bytes.Buffer    for _, r := range s {        if unicode.IsControl(r) && !isJSONAllowedControl(r) {            fmt.Fprintf(&buf, "\\u%04X", r)        } else {            buf.WriteRune(r)        }    }    return buf.String()}// isJSONAllowedControl 判断是否为 JSON 显式允许的控制字符（仅 \t \n \r）func isJSONAllowedControl(r rune) bool {    return r == '\t' || r == '\n' || r == '\r'}func main() {    // 原始含非法控制符的 JSON 字符串（注意：\u001c 和 \u001a 在源码中需用字面量表示）    original := `{"os": "\u001C09:@>A>DB Windows 8.1 \u001A>@?>@0B82=0O"}`    // 预处理：转义非法控制符    cleaned := sanitizeJSONString(original)    fmt.Printf("Cleaned: %s", cleaned) // 输出: {"os": "\\u001C09:@>A>DB Windows 8.1 \\u001A>@?>@0B82=0O"}    // 安全解析    var result struct {        OS string `json:"os"`    }    err := json.Unmarshal([]byte(cleaned), &result)    if err != nil {        panic(err)    }    fmt.Printf("Parsed OS: %q", result.OS) // 输出: "09:@>A>DB Windows 8.1 >@?>@0B82=0O"}

使用时有几个关键点需要留意：

• 用 range s 遍历的是 rune 而非字节，这样能确保正确处理多字节的 UTF-8 字符，不会出现截断或乱码。
• 制表符、换行符、回车符这三个是 JSON 允许的，必须保留。其余的控制字符（比如退格、垂直制表、换页，以及 U+000E 到 U+001F 这一大片）都要转义。
• 这套方案不处理编码层面的错误。如果原始数据本身就不是 UTF-8，比如混入了 GBK 编码，得先用 golang.org/x/text/encoding 这类库做转换。
• 如果控制字符在业务上有实际意义，比如作为设备协议里的分隔符，那转义之后信息就丢了。是否适用，需要跟上游系统沟通清楚。
• 生产环境里，建议封装成一个 json.RawMessage 的预处理器，同时加个日志，记录非法字符的出现频次，方便排查问题。

最后多叮嘱一句：用这个预处理，你不需要去动 Go 底层的 JSON 解析器，就能稳稳地处理那些“不规范但常见”的外部 JSON 输入源。这就像给数据流加了一道安检门，拦下不该进的东西，让它顺利通过。