Go base64.Encoding.Strict 如何拦截尾部脏位：解码校验与兼容边界

接口收到一段看起来合法的 Base64 字符串时，真正容易漏掉的是最后一个 6 位字符里的“多出来的位”。Go 的 base64.StdEncoding 默认解码并不检查这些尾部填充位是否为零；如果签名、缓存键或跨系统协议要求同一份字节只能对应一种规范编码，就应该显式使用 base64.StdEncoding.Strict()，并把 CorruptInputError 当成输入不合规处理。

先看同一串输入为什么会出现两种结果

下面的实验只改编码器，不改输入。AB 的标准编码是 QUI=；把最后一个有效字符换成同一 6 位组中尾部比特非零的 QUJ=，普通解码仍可能得到 AB，严格解码则会拒绝这份非规范表示。这个差异适合用来检查签名字段和跨语言协议的规范化策略。

package main

import (
    "encoding/base64"
    "fmt"
)

func main() {
    input := "QUJ="

    loose, looseErr := base64.StdEncoding.DecodeString(input)
    strict, strictErr := base64.StdEncoding.Strict().DecodeString(input)

    fmt.Printf("loose=%q err=%v\n", loose, looseErr)
    fmt.Printf("strict=%q err=%v\n", strict, strictErr)
}

在当前 Go 实现里，普通路径得到的字节可能仍是 AB，而严格路径返回 illegal base64 data at input byte 3 一类的 CorruptInputError。文章里的关键不是死记错误位置，而是让协议入口明确选择“接受兼容表示”还是“只接受规范表示”。

Encoding.Strict 实际收紧了哪一层校验

Strict() 会创建一个与原编码相同、但启用严格解码的副本。它检查的是最后一个 Base64 量化组中没有承载有效数据的尾部位是否为零，解决的是同一字节序列存在多种文本表示的问题。它不是“禁止所有宽松输入”的总开关。

把错误判断放在业务转换之前

不要把 DecodeString 的错误吞掉后继续解析 JSON、令牌或二进制头。先判断错误，再决定是否把结果交给后续模块；下面把这个成功分支称为 business conversion，日志里也能看出是 Base64 格式不合规，还是解码后内容不符合业务协议。

func decodeToken(input string) ([]byte, error) {
    decoded, err := base64.StdEncoding.Strict().DecodeString(input)
    if err != nil {
        return nil, fmt.Errorf("base64 input rejected: %w", err)
    }
    return decoded, nil
}

如果调用方需要区分输入错误，可以用 errors.As 检查 base64.CorruptInputError；但对外响应不宜直接暴露内部偏移。偏移适合放在受控日志中，客户端只需要得到稳定的参数错误。

NoPadding 不等于 Strict

JWT 等场景常用无填充 Base64URL，但“去掉 =”只是外层格式选择。可以把 base64.RawURLEncoding 用于无填充 URL 字符集，再根据协议是否要求尾部位规范选择严格版本；不要因为输入没有等号就认为它自动完成了规范校验。

rawURL := base64.RawURLEncoding.Strict()
encoded := rawURL.EncodeToString([]byte("AB"))
decoded, err := rawURL.DecodeString(encoded)
fmt.Println(encoded, string(decoded), err)

这里要先确认对端是否真的约定了 Raw URL 编码。如果一端使用标准字母表、另一端使用 URL 字母表，严格与否都解决不了字符集不一致。协议文档、编码对象和测试向量应一起固定。

相关问题与排查边界

Strict 会拒绝换行吗？

不会。官方文档明确说明 CR 和 LF 仍会被忽略；如果签名字段必须是单行文本，应在 Base64 解码前增加单行格式检查。

DecodeString 返回空字节就代表输入错误吗？

不能这样判断。空输入可能对应空字节，应该以 err 为第一判断条件，再按业务决定是否允许空值。

普通 StdEncoding 需要全部替换成 Strict 吗？

不一定。对兼容历史数据的展示或导入场景可以保留普通解码；对签名、缓存键、幂等键和跨系统协议，优先明确采用 Strict 并补齐双方测试向量。

验收时只记住三件事

先确认字符集与是否带填充，再确认是否需要尾部位规范化，最后把解码错误挡在业务转换之前。这样 Strict() 才是协议设计的一部分，而不是临时给某个报错加上的补丁。