Go base64.DecodeString 报 CorruptInputError 怎么定位偏移

Go 的 base64.DecodeString 报 illegal base64 data at input byte N 时，N 不是模糊的错误编号，而是解码器发现问题的零基字节偏移。先把错误转成 base64.CorruptInputError，再围绕这个偏移查看原始字节；如果偏移等于输入长度，则重点检查末尾补位或输入是否被截断。

先提取 CorruptInputError，再读取准确偏移

直接解析Go标准库返回的CorruptInputError实例里的偏移字段，就能快速定位到base64字符串里第一个非法字符所在的位置，不用逐字符比对整段内容。

CorruptInputError 的底层类型是 int64，其值就是解码器报告的位置。下面的辅助函数保留原始输入，不急着删除空白，这样日志里的偏移仍能回到收到的载荷。

package main

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

func decodeWithOffset(src string) ([]byte, int64, error) {
    // DecodeString 失败时仍可能返回部分结果；调用方要同时检查 data 和 err。
    data, err := base64.StdEncoding.DecodeString(src)
    if err == nil {
        return data, -1, nil
    }

    var corrupt base64.CorruptInputError
    if errors.As(err, &corrupt) {
        // corrupt 是零基字节偏移；它不是 Unicode 字符序号。
        return data, int64(corrupt), err
    }
    return data, -1, err
}

func main() {
    data, offset, err := decodeWithOffset("SGVsbG8$IQ==")
    if err != nil {
        fmt.Printf("offset=%d data=%q err=%v\n", offset, data, err)
        return
    }
    fmt.Println(string(data))
}

这个例子中的 $ 不在标准字母表内，偏移会指向它。不要只记录 err.Error()；生产日志最好同时保留输入来源、偏移、输入长度和脱敏后的上下文。

用偏移附近的字节区分非法字符和截断

定位时不要直接把整段 Token 打进日志。以错误位置为中心截取少量字节，并同时输出十六进制和可见文本，既便于识别 +、/、-、_ 或 =，也能发现不可见换行和传输污染。

func showContext(src string, offset int64) {
    // 只展示错误点附近的字节，避免把完整凭据写入日志。
    if offset = int64(len(src)) {
        fmt.Printf("offset=%d len=%d：可能是缺少补位或输入被截断\n", offset, len(src))
        return
    }
    pos := int(offset)
    start, end := pos-4, pos+5
    if start  len(src) {
        end = len(src)
    }
    fmt.Printf("byte[%d]=0x%02x context=%q\n", pos, src[pos], src[start:end])
}

如果偏移等于 len(src)，常见原因是标准 Base64 末尾少了 =，或者上游在传输途中截断。若偏移落在中间位置，再检查该字节是否来自错误的 URL 解码、JSON 转义、空格替换或复制粘贴。

先匹配字母表，再判断是否需要补位

同样的字符串，选择错误的 Encoding 也会得到 CorruptInputError。标准 Base64 使用 + 和 /；URL-safe 版本使用 - 和 _。无补位数据则应该使用 RawStdEncoding 或 RawURLEncoding。

如果数据来自 JWT 或其他 URL-safe 协议，先确认协议约定，再决定是否补回 =。补位不是万能修复：字母表错误、截断和中间非法字节仍应回到上游修复。

UTF-8、换行与 Strict 模式的边界

偏移是字符串底层字节下标，不是中文字符序号。输入包含中文前缀或日志混入多字节字符时，看到的第几个“字符”可能与 CorruptInputError 的数字不同。\r 和 \n 会被解码器忽略，但其他空白字符不会自动忽略；若业务要清洗，应该在清洗前建立原始位置映射。

StdEncoding.Strict() 只会进一步检查末尾未使用的填充位是否为零，不能替代字母表选择，也不能修复缺少补位或被截断的输入。对外部输入，建议记录失败原因后拒绝载荷；不要静默删除任意字符或无限尝试多个 Encoding。

常见问题

CorruptInputError 的偏移从 0 还是从 1 开始？

从 0 开始，并且按字节计数。要给用户展示时可以另加 1，但日志和程序判断应保留原始零基值。

为什么错误偏移会等于字符串长度？

这通常表示解码器读到输入末尾仍缺少必要补位，也可能是数据在网络、表单或消息队列中被截断。

能不能先 strings.TrimSpace 再 DecodeString？

只有协议明确允许这样做才可以。TrimSpace 会改变偏移与原始载荷的对应关系，而且不能替代对字母表、补位和传输完整性的判断。

实际排障可以固定成一条链：提取错误偏移，打印少量脱敏上下文，确认输入协议和 Encoding，最后决定修复上游还是拒绝请求。这样比反复更换解码函数更容易保留可复现证据。