Go base64.CorruptInputError 如何报告错误发生的字节位置

Go 的 Base64 解码报错为 illegal base64 data at input byte N 时，N 指向原始输入中的零基字节下标，不是已经解码了多少字节，也不是屏幕上的字符列。排查时应保留这个偏移和原始编码方式；DecodeString 返回的部分数据不能在错误未处理时直接当成完整结果。

官方地址：https://pkg.go.dev/encoding/base64

先确认 CorruptInputError 中数字的含义

例如输入 SGVsbG8!，前面的字符仍属于 Base64 字母表，感叹号位于下标 7。错误值可以写成 base64.CorruptInputError(7)，它描述的是“解析输入时在哪个字节发现问题”。这个数字不是 UTF-8 字符数，也不是输出切片的长度；如果输入来自文件或网络，日志应把它当作原始字节偏移使用。

标准库的错误文本由 Error() 拼出 illegal base64 data at input byte 和这个整数。源码中解码器按输入切片的索引推进，所以看到错误后，先检查该位置附近的字符、是否混入 URL 编码或额外标点，再决定修复方式。

用 errors.As 提取偏移和出错字节

不要只用字符串截取错误消息。CorruptInputError 是可断言的具体错误类型，使用 errors.As 可以在未来增加包装错误时仍然取到它：

package main

import (
	"encoding/base64"
	"errors"
	"fmt"
)

func main() {
	// 感叹号故意放在输入下标 7，用来演示错误位置的读取方式。
	src := "SGVsbG8!"
	data, err := base64.StdEncoding.DecodeString(src)
	if err == nil {
		fmt.Printf("decoded=%q\n", data)
		return
	}

	var corrupt base64.CorruptInputError
	if errors.As(err, &corrupt) {
		// CorruptInputError 是原始输入的零基字节偏移，不是 data 的长度。
		offset := int64(corrupt)
		fmt.Printf("offset=%d\n", offset)
		if offset >= 0 && offset 

这段示例的典型输出是 offset=7 和 bad-byte='!'。DecodeString 可能已经返回一部分字节，但只有 err == nil 时才把它视为完整解码结果；错误场景下它更适合用于诊断，不适合直接入库。

非法字符、换行和补位要分开排查

换行是一个容易误读的点：标准解码器会跳过 \r 和 \n，但内部索引仍在原始 src 上移动。因此日志里的偏移适合回到原始字节串定位，不一定等于去掉换行后字符串的下标。

把偏移变成可操作的排障信息

线上记录至少包含编码选择（标准、URL-safe 或 Raw）、原始输入长度、错误偏移和偏移附近的脱敏片段。不要为了“让它成功”把所有非字母字符清掉：那可能改变签名、令牌或二进制数据的含义。修复数据源后，再用同一套 Encoding 重新解码，并检查完整结果长度和业务校验。

如果输入是 URL 参数或 JSON 字段，还要先确认传输层有没有把 + 变成空格、把百分号编码残留在内容里。偏移只能告诉你“第一个可识别的失败位置”，不能替你判断上游为什么产生了坏数据。

常见问题

CorruptInputError 的下标从 0 还是从 1 开始？

从 0 开始。要展示给非程序用户时可以另加 1，但日志和切片访问应保留原始零基值。

为什么错误时 data 不是空切片？

解码器可能先完成前面的完整量，再在后续输入发现错误，所以返回部分数据；这不代表整段输入有效。

换成 RawStdEncoding 就能消除错误吗？

只有当输入本来就约定不带 = 补位时才应使用 Raw 变体。它改变的是编码规则，不是对任意非法字符的容错开关。