Go encoding/base64 怎样判断 URL 编码和标准编码的区别

判断 Go 的 Base64 变体，先看两件事：使用哪套字符表，以及是否保留末尾填充。URLEncoding 改的是字符表，不代表没有等号；RawURLEncoding 才同时选择 URL 安全字符表和无填充形式。两端必须按同一协议配对，不能把“能放进 URL”理解成“可以自动识别”。

来源：先确定协议，再看字符串

接口字段、配置文件和 URL 参数都可能携带 Base64 文本。真正的选择依据是生产方与消费方的协议说明，而不是变量名包含 token、url 或 base64。如果字符串只出现字母和数字，标准字符表与 URL 字符表可能产生完全相同的文本，单靠外观无法判断来源。没有等号也不能直接证明使用 Raw：原始字节数恰好为三的倍数时，带填充编码本来就没有补位字符。

本文面向 Go 标准库的四个预定义对象，不引入第三方包。定义依据见 Go encoding/base64 文档，字符表与填充约定参见 RFC 4648 第 3、4、5 节。下面是文档语义推导的示例，未执行本地运行测试。

校验：字符表与填充分别选择

除最后两个字符外，两套字符表的字母和数字相同。Raw 不改变原始字节，也不增加加密或压缩功能，只是不输出填充。输入余一字节时，带填充编码补两个等号；余二字节时补一个；整三字节时不补。

package main

import (
    "encoding/base64"
    "fmt"
)

func main() {
    // 特意选取会使用字符表末尾符号的字节。
    data := []byte{0xfb, 0xff}
    choices := []struct {
        name string
        enc *base64.Encoding
    }{
        {"标准带填充", base64.StdEncoding},
        {"标准无填充", base64.RawStdEncoding},
        {"URL带填充", base64.URLEncoding},
        {"URL无填充", base64.RawURLEncoding},
    }
    for _, item := range choices {
        fmt.Println(item.name, item.enc.EncodeToString(data))
    }
}

按编码规则，这四个结果依次应为 +/8=、+/8、-_8=、-_8。这组字节同时暴露字符表差异和填充差异，比用普通英文单词观察更直观。这是预期值说明，不是执行回执。

存储：保存字节还是保存协议文本

数据库保存二进制内容时，可以使用适当的二进制字段；必须保存 Base64 字符串时，应在接口或字段说明中固定变体，例如“RFC 4648 base64url，无填充”。不要让写入端用标准带填充、读取端再轮流尝试四种解码器。这种兜底会掩盖协议漂移，也无法可靠识别只含公共字符的输入。

同一份字节可以对应多个变体文本。业务若比较的是内容，就在成功解码后比较字节；若签名、缓存键或外部协议定义比较原始文本，则不能自行替换符号、删除等号或重新编码。应先明确签名对象是文本还是字节。不要把存储规范化操作混入签名验证前的处理。

查询：Base64URL 不等于 URL 转义

Base64 把字节转为文本，URL 转义则处理文本在 URL 各组成部分中的表示，两者不是同一层。标准 Base64 中的加号若直接拼入查询字符串，经过表单式查询解析可能成为空格。因此即便接口约定标准 Base64，也可以通过 url.Values 安全构造查询；不能为省事擅自改成 URL 字符表。解析规则可查 net/url.Values.Encode。

package main

import (
    "encoding/base64"
    "fmt"
    "net/url"
)

func main() {
    // 此接口假定约定标准带填充，不能私自改成 URL 变体。
    token := base64.StdEncoding.EncodeToString([]byte{0xfb, 0xff})
    query := url.Values{}
    query.Set("data", token)
    fmt.Println(query.Encode())
}

该示例按规则应得到 data=%2B%2F8%3D。服务端正常解析查询后取得的是 +/8=，再交给标准解码器。若框架已解析参数，不要再次调用 QueryUnescape。路径部分另有路径转义规则，不能把 QueryEscape 当成所有 URL 位置都适用的工具。

异常：解码失败不能继续使用部分结果

DecodeString 遇到畸形内容可能同时返回部分字节和错误。对完整业务字段应以错误为准，丢弃这次字节结果。编码对象不匹配、填充缺失或多余、非法字符，均应按输入格式错误处理，不要在错误后把部分内容当完整标识继续查询。

Strict() 只额外要求尾部未使用的填充位为零，并不意味着拒绝所有文本变形；Go 解码器仍会忽略回车和换行。如果协议要求无换行且唯一的无填充 URL 文本，可以限制长度，严格解码后用同一对象重新编码，再与原字符串比较。

package tokenfmt

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

// DecodeToken 只接受本项目约定的规范、无填充 Base64URL 文本。
func DecodeToken(text string) ([]byte, error) {
    // 长度是业务示例值，应与接口字段上限保持一致。
    if len(text) == 0 || len(text) > 4096 {
        return nil, errors.New("编码字段为空或过长")
    }
    enc := base64.RawURLEncoding.Strict()
    data, err := enc.DecodeString(text)
    if err != nil {
        // 不向调用者交付可能已解出的部分内容。
        return nil, fmt.Errorf("Base64URL 格式错误: %w", err)
    }
    if enc.EncodeToString(data) != text {
        return nil, errors.New("编码文本不是协议要求的规范形式")
    }
    return data, nil
}

这里拒绝空串是业务限制，不是 Base64 标准规定。重编码相等检查能挡住被解码器忽略的换行；长度上限限制输入规模，但不能代替 HTTP 请求体限制、鉴权或内容有效性检查。恢复出来的字节仍然可能不是合法的业务数据，必要时还要核对预期字节长度和结构。对已签名文本的协议，必须遵循其指定的签名处理顺序，不能直接套用这个普通字段入口。

清理：将兼容逻辑收口到明确边界

迁移历史数据时，先按来源版本或字段元信息确定旧格式，再成功解码并写入明确的新表示；有签名或外部引用的记录要单独设计迁移方案。迁移完成后移除散落在调用处的字符替换和自动补等号逻辑，保留一个编码约定和一个解码入口。错误日志记录字段名、来源版本及错误类别即可，不要把令牌全文写入日志。

最终选择可以压缩成一句话：协议写标准 Base64 就选 StdEncoding，写 URL 安全字符表就选 URLEncoding；只有协议同时规定省略填充，才选择对应 Raw 对象。Base64 不是加密，URL 安全也不代表具备防篡改、保密或访问控制能力。