Go encoding/base64 如何判断输入是否被截断：CorruptInputError 与补位字符处理

接口收到一段看起来像 Base64 的字符串时，最麻烦的情况不是立刻崩溃，而是解码器已经写出一部分字节，随后才发现输入在中间被截断或混入了非法字符。Go 的 encoding/base64 会把这两件事同时告诉你：返回已成功解出的数据，并返回 CorruptInputError。因此，调用方不能只看返回数据，也不能把所有错误都当成“没有结果”。

判断截断输入时，先检查 error，再决定是否接受部分数据；只有明确允许不完整载荷的场景，才使用返回的前缀。

先把“截断”和“非法字符”分开

Base64 按四个字符组成一个量子块。字符串少了末尾字符，可能表现为输入长度不完整；中间出现 #、空格或不属于当前编码表的字符，则会在具体输入位置触发 CorruptInputError。这两个问题都可能落在同一个错误类型上，所以不要只依据错误名称猜原因。

下面的最小程序故意把 SGVsbG8= 改成两类坏输入：一类删掉末尾补位，另一类插入非法字符。它们的共同点是：解码函数可能已经写出 Hello 的前缀。

package main

import (
    "encoding/base64"
    "fmt"
)

func main() {
    samples := []string{
        "SGVsbG8=",  // Hello
        "SGVsbG8",   // 缺少标准补位
        "SGVs#G8=",  // 非法字符
    }

    for _, input := range samples {
        data, err := base64.StdEncoding.DecodeString(input)
        fmt.Printf("input=%q data=%q err=%v\n", input, data, err)
    }
}

这里的验收点不是“打印出了多少字符”，而是把 err 与输入原文一起记录。对于令牌、配置和上传文件这类完整载荷，出现错误就应该拒绝整个值。

DecodeString 的返回值应该怎样读

DecodeString 的结果有三个维度：成功时得到完整字节和 nil；格式错误时可能得到部分字节和 CorruptInputError；空输入则是空字节和 nil。后者很容易被业务层误判成“缺少数据”，因此空值校验仍要由业务规则负责。

错误类型本身是一个输入偏移量，可以用类型断言把错误位置打印出来：

data, err := base64.StdEncoding.DecodeString(input)
if err != nil {
    var corrupt base64.CorruptInputError
    if errors.As(err, &corrupt) {
        fmt.Printf("base64 input byte=%d\n", int64(corrupt))
    }
    return fmt.Errorf("reject base64 payload: %w", err)
}
if len(data) == 0 {
    return errors.New("empty decoded payload")
}

CorruptInputError 的数字表示输入中的位置，不能拿它和 len(data) 比较来判断输出是否完整。若业务必须接受分片数据，应另外约定分片长度、序号和最终拼接状态，不能仅凭“已经拿到部分字节”放行。

补位字符决定了哪一种编码能通过

StdEncoding 使用标准字母表，并按需要使用 = 补齐四字符量子块；RawStdEncoding 则明确表示不带补位的版本。选择编码时要跟发送方协议一致，不能看到“少了等号”就无条件拼接。

padded, err := base64.StdEncoding.DecodeString("SGVsbG8=")
raw, rawErr := base64.RawStdEncoding.DecodeString("SGVsbG8")
fmt.Printf("padded=%q err=%v\n", padded, err)
fmt.Printf("raw=%q err=%v\n", raw, rawErr)

如果协议规定标准 Base64，缺少补位应作为格式错误处理；如果协议规定 raw 形式，使用 RawStdEncoding 才是清晰的契约。不要在解码失败后先补 = 再重试，因为这会掩盖发送端截断，也可能把本应拒绝的数据变成另一段合法字节。

把错误处理放在输入边界

实际项目里可以把解码封装成一个只返回完整载荷的小函数。它不记录原始敏感内容，只保存输入长度和错误位置，既方便排查，也避免把令牌写进日志。

func decodePayload(input string) ([]byte, error) {
    data, err := base64.StdEncoding.DecodeString(input)
    if err != nil {
        var corrupt base64.CorruptInputError
        if errors.As(err, &corrupt) {
            return nil, fmt.Errorf("invalid base64 at byte %d", int64(corrupt))
        }
        return nil, err
    }
    if len(data) == 0 {
        return nil, errors.New("decoded payload is empty")
    }
    return data, nil
}

验收时至少覆盖完整输入、缺少补位、非法字符、空输入和包含换行的输入。官方实现会忽略 \r 与 \n，但不会因此放过任意空白字符；如果上游协议允许空格，应在协议层明确规范并单独清洗。

几个容易误判的边界

部分输出能不能继续使用？

完整对象、签名材料、配置密文和文件内容都不应继续使用。只有明确设计为可恢复分片的协议，才可以把部分输出当作一个带错误标记的前缀，并等待后续分片。

错误位置是不是输出长度？

不是。它指向输入字节位置，输入包含换行时仍应按解码器报告的偏移理解，不要用它推算目标数据长度。

为什么换行能过，空格却不能？

Go 的 Base64 解码逻辑专门忽略回车和换行，这是常见编码文本的兼容处理；其他字符是否允许，仍取决于编码表和输入格式。

验收清单

• 标准格式使用 StdEncoding，无补位格式使用 RawStdEncoding。
• 任何非 nil 错误先拒绝完整载荷，不依据部分输出做成功判断。
• 用 errors.As 提取 CorruptInputError，记录长度和位置，不记录敏感原文。
• 把空输入、换行、缺少补位和非法字符加入单元测试。

相关问题

标准 Base64 缺少等号时要不要自动补齐？

先确认协议。如果协议约定 StdEncoding，应把缺少补位视为输入错误；只有协议明确采用 RawStdEncoding，才使用无补位解码。

解码返回了部分字节，能否先解析再报错？

完整载荷不应这样做。部分字节没有完整性保证，应该记录错误并拒绝；可恢复分片协议则需要独立的分片状态和完整性校验。

如何在日志里定位哪一段 Base64 坏了？

记录输入长度和 CorruptInputError 的位置即可，避免记录令牌或密文原文。结合请求 ID，就能定位上游截断或非法字符来源。