Go base64.Encoding.Strict 如何拒绝非零填充：解码边界与错误定位

接口收到一段看起来合法的 Base64 字符串时，普通解码成功并不代表末尾填充位也符合规范。Go 的 base64.Encoding.Strict 提供了一个窄而实用的校验开关：它复制当前编码，并要求最后一个编码单元中未使用的填充位为零。这样，脏数据会在进入业务转换前暴露。

需要严格检查 Base64 尾部填充时，用 RawStdEncoding.Strict() 或 StdEncoding.Strict() 得到独立编码器，再检查 DecodeString 返回的 CorruptInputError；Strict 不会修复输入，也不会替你补齐缺失字符。

先看普通解码为什么可能放过尾部问题

把 Base64 当作令牌或签名字段时，最容易忽略的是最后一个字符携带的有效位之外还剩多少位。普通 StdEncoding 主要关注字符表、长度和填充结构；如果末尾填充位不是零，业务层仍可能得到一段看似正常的字节。

package main

import (
    "encoding/base64"
    "fmt"
)

func main() {
    input := "TQ=="
    plain, err := base64.StdEncoding.DecodeString(input)
    fmt.Printf("plain=%q err=%v\n", plain, err)

    strict := base64.StdEncoding.Strict()
    checked, err := strict.DecodeString(input)
    fmt.Printf("strict=%q err=%v\n", checked, err)
}

这个例子先用同一份输入走两条路径：StdEncoding 完成数据转换，Strict 则在相同字符结构上追加尾部位校验。判断结果时不要只看字节切片，必须同时检查 err。

Strict 返回的是副本，原编码器不会被改写

Strict() 的语义是基于当前编码器得到一个更严格的副本。可以把它命名为 strict 并长期复用；需要普通兼容行为的旧调用仍可继续使用原来的 StdEncoding。

strict := base64.StdEncoding.Strict()

valid, err := strict.DecodeString("TQ==")
if err != nil {
    fmt.Println("strict decode failed:", err)
    return
}
fmt.Printf("bytes=%q\n", valid)

这里的生命周期是“创建副本—读取输入—返回字节”。Encoding 可以并发使用，实际项目里应在包级变量初始化时创建严格编码器，避免每次请求重复构造，同时把格式选择写在变量名中。

如何从 CorruptInputError 判断坏在哪

解码失败时，DecodeString 会返回数据和错误。对格式错误，错误通常可以断言为 base64.CorruptInputError，它携带解码器发现问题的位置。日志里记录偏移比直接记录整段令牌更安全，也更方便关联请求。

strict := base64.StdEncoding.Strict()
decoded, err := strict.DecodeString("TQ$=")
if err != nil {
    var bad base64.CorruptInputError
    if errors.As(err, &bad) {
        fmt.Println("bad offset:", int(bad))
    }
    return
}
fmt.Println(decoded)

错误分支应该在业务转换前结束，不能把不完整的 decoded 继续送进 JSON、签名或数据库写入。若输入来自 URL，还要先确认发送方用的是标准 Base64 还是 URL-safe 编码，字符表不同会导致另一类失败。

RawStdEncoding 与 Strict 不是一回事

是否带 = 填充和是否检查填充位，是两个不同选择。没有填充的字段使用 RawStdEncoding；需要尾部位严格为零时，再对相应编码器调用 Strict()。不要用截断字符串或手动补等号来掩盖协议不一致。

这张表的关键不是“越严格越好”，而是编码器必须和上游协议一致。先定格式，再决定是否启用严格尾部检查，排错时才能把问题归因到输入而不是库的默认行为。

相关问题

Strict 会修复非零填充位吗？

不会。它只会拒绝不符合要求的输入，修复动作应由上游重新编码，而不是在服务端静默改写。

没有等号的 Base64 能直接用 Strict 吗？

先选择 RawStdEncoding 或对应的 RawURLEncoding，再按需要调用 Strict；Strict 不会改变是否带填充的协议。

CorruptInputError 的偏移能直接当字符串下标吗？

它表示解码器发现坏输入的位置。若输入含多字节文本或经过 URL 编码，日志展示时还应保留原始字节与转换步骤，不能盲目按中文字符数解释。

小结

Base64 严格校验的落点是编码格式和尾部位，而不是“把字符串再解码一次”。先选对 StdEncoding、RawStdEncoding 或 URL-safe 编码，再创建 Strict 副本；解码失败就按 CorruptInputError 的位置记录和拒绝，让脏输入停在边界上。