Go encoding/base64.RawURLEncoding 如何处理无填充令牌：编码选择与解码边界

回调链接里的令牌偶尔在网关日志中少了末尾字符，排查后常见的第一嫌疑是 Base64 的填充符号。Go 里，base64.RawURLEncoding 专门提供 URL 安全且不带 = 填充的编码；但它只解决字符集和填充形式，不能替代签名或完整性校验。

需要把令牌放进 URL 路径或查询参数时，编码端和解码端应成对使用 RawURLEncoding；如果协议已经约定带填充，就继续使用 URLEncoding，不要靠“先补等号”碰运气。

为什么令牌会在 URL 中多出等号

标准 Base64 每处理 3 个字节会产生 4 个字符，输入长度不是 3 的整数倍时，输出末尾可能出现一个或两个 =。在查询参数里它通常没问题，但如果令牌被拼进路径、经过表单转码，或者某个中间层把尾部当成填充处理，就容易出现“编码成功，传输后解码失败”的错觉。

RawURLEncoding 不是另一套神秘算法，它就是 URL 字符表版本的 URLEncoding 再调用 WithPadding(NoPadding)。下面这条调用链是选择无填充编码时真正发生的关系：

package main

import (
    "encoding/base64"
    "fmt"
)

func main() {
    data := []byte("go-token-01")
    padded := base64.URLEncoding.EncodeToString(data)
    raw := base64.RawURLEncoding.EncodeToString(data)
    fmt.Println(padded)
    fmt.Println(raw)
}

两端必须知道同一个协议约定。不能编码端使用 RawURLEncoding，解码端却强制期待 =，也不能看到字符串里没有等号就断言它一定是合法令牌。

无填充输入的长度边界怎么判断

无填充 Base64 的字符串长度模 4 可以是 0、2 或 3，不能是 1。比如原始数据只剩下一个 Base64 字符时，缺失的信息超过了填充符能表达的范围，DecodeString 应该返回错误，而不是静默猜测。

先固定一对编码器

如果协议选择无填充 URL 编码，最小的封装可以直接把编码器写死在函数里，避免调用方临时选择：

var tokenEncoding = base64.RawURLEncoding

func encodeToken(src []byte) string {
    return tokenEncoding.EncodeToString(src)
}

func decodeToken(s string) ([]byte, error) {
    return tokenEncoding.DecodeString(s)
}

这段代码只保证“字节序列能往返”。如果令牌还包含用户标识、过期时间或权限，仍需在解码后做签名核对和字段校验。

解码失败到底发生在哪里

排查时不要只看“返回了 error”。先区分输入字符非法、长度不对，还是完整性校验失败。标准库的 DecodeString 会把非法 Base64 输入报告为 CorruptInputError；而业务签名不匹配是另一层判断，不能把两者混成一个“令牌无效”的模糊日志。

func decodeStrictToken(token string) ([]byte, error) {
    enc := base64.RawURLEncoding.Strict()
    data, err := enc.DecodeString(token)
    if err != nil {
        return nil, err
    }
    return data, nil
}

Strict 的作用是收紧 RFC 4648 规定的尾部填充位检查。对于无填充编码，最重要的仍是使用正确的编码器、拒绝非法字符，并把错误留在边界层处理；它不会替你验证 HMAC，也不会防止令牌重放。

把格式问题和安全问题分开验收

一个可复现的验收表至少覆盖三类输入：正常往返、长度模 4 为 1 的损坏输入、字符集正确但签名不匹配的输入。前两类由 Base64 层处理，最后一类必须由业务签名层处理。

常见问题：RawURLEncoding 该怎么选

它能直接替代所有 Base64 编码吗？

不能。只有协议允许 URL 安全字符并明确不带填充时，才使用它；文件格式或外部接口若约定标准 Base64，应保持原约定。

解码前要不要自动补等号？

不要把自动补等号当通用修复。先确认协议是否本来就是 Raw 编码，再判断长度是否合法；擅自补齐可能掩盖截断或协议不一致。

Strict 能防止令牌被修改吗？

不能。它只检查 Base64 表示的尾部位，令牌是否被修改要靠 HMAC、签名或其他完整性机制。

总结

RawURLEncoding 解决的是“放进 URL 时使用哪套字符表、是否保留填充”的格式问题。把它和 DecodeString、Strict 的职责分开，再把签名验证单独放在业务边界，才能判断一次失败究竟是传输截断、编码选错，还是令牌真的不可信。