Go base64 怎样编码不带等号的 URL 参数

Go 要生成不带等号填充的 URL 安全 Base64 参数，可以直接使用 base64.RawURLEncoding.EncodeToString(data)；接收端对应调用 base64.RawURLEncoding.DecodeString(token)。它同时选择 URL 安全字符集和无填充形式，适合双方约定好的查询字段。

我会把参数格式写成两个条件：使用 base64url 字符集，省略末尾填充。仅去掉等号不能把普通 Base64 变成 base64url；完整查询字符串仍交给 net/url 组装。

下面以目录分页书签为设计例子。示例没有连接真实服务，也没有生成认证凭据。Go 标准库文档：https://pkg.go.dev/encoding/base64。

先把字符集与填充约定分开

设计一个书签参数时，我更关心调用方是否能明确知道“该用哪一种解码器”，而不是只在接口文档里写一句 Base64。Go 提供的四个常用预设恰好对应两项独立选择：字符集，以及是否保留填充。

因此，需求若明确是“无等号的 URL 参数”，我的选择是 RawURLEncoding。Raw 表示不加填充，URL 表示使用替代字符集。普通编码有时碰巧没有产生加号、斜杠或等号，不能仅凭某一条样本外观判断编码种类。

这个选择也有代价：对端如果只接受带填充的 URLEncoding，接口会出现格式不兼容。是否省略填充应成为协议约定，不应由每个调用方自行猜测。

用 RawURLEncoding 生成参数值

完整示例用两个字节作为书签。这个输入刻意包含能体现字符集区别的内容，而不是只用字母组成的短句。下列代码是可保存为 main.go 的独立示例，文中的结果说明依据编码规则推导，并非本机运行记录。

package main

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

func main() {
    // 演示二进制书签；不是认证令牌，也不包含真实用户数据。
    bookmark := []byte{0xfb, 0xff}
    token := base64.RawURLEncoding.EncodeToString(bookmark)

    // Base64 负责值的表示，url.Values 负责查询字段的转义与组装。
    u := url.URL{Path: "/catalog"}
    q := url.Values{}
    q.Set("bookmark", token)
    q.Set("label", "阅读 & 收藏")
    u.RawQuery = q.Encode()
    fmt.Println(u.String())

    // 模拟接收端解析同一份查询串，错误时不继续使用部分数据。
    values, err := url.ParseQuery(u.RawQuery)
    if err != nil {
        log.Fatal(err)
    }
    decoded, err := base64.RawURLEncoding.DecodeString(values.Get("bookmark"))
    if err != nil {
        log.Fatal(err)
    }
    fmt.Println(bytes.Equal(decoded, bookmark))
}

对于字节 0xfb, 0xff，普通带填充 Base64 表示为 +/8=，RawURLEncoding 的表示为 -_8。变化既包括特殊字符，也包括末尾填充；若只对普通编码做 TrimRight 去掉等号，得到的仍是 +/8。

RawURLEncoding 本身等价于 URLEncoding.WithPadding(base64.NoPadding)。我在业务代码里更愿意用现成预设：读者看到变量名就能识别约定，不必再检查额外的 WithPadding 配置。

用 url.Values 组装查询字符串

书签值已经选用 URL 安全字符集，为什么示例仍然使用 url.Values？因为一个 URL 往往还有 label、筛选条件等其他字段。示例里的 label 含空格和 &，直接拼接会把数据与查询语法混在一起。

这里的对象关系很清楚：bookmark 字节由 RawURLEncoding 表示为 token；token 与 label 都作为 url.Values 中的字段值；Values.Encode 的结果赋给 URL.RawQuery。编码器只处理书签的字节表示，URL 组装器处理完整查询结构。

不要先对字段调用 QueryEscape，再把结果放进 url.Values，否则容易造成重复转义。接收端拿到 ParseQuery 或 URL.Query 已还原的字段后，也不要惯性再做一次 QueryUnescape。本例使用 ParseQuery，是为了把查询语法错误明确交给错误分支。

接收端按同一约定处理错误

读取端应使用与发送端相同的预设。Base64 解码失败时可能同时返回部分已解码数据和错误；我的接口选择是一旦 err 非空就丢弃这份数据，不尝试将其解释成书签。

下面是函数体片段，假设外围函数签名返回 ([]byte, error)，且已经导入 encoding/base64 和 fmt。512 是这个示例自行规定的编码后字节长度上限，应由实际书签大小决定。

// 接收端片段：已从查询参数中取得 token；上限由本接口约定。
if token == "" || len(token) > 512 {
    return nil, fmt.Errorf("invalid bookmark length")
}
decoded, err := base64.RawURLEncoding.DecodeString(token)
if err != nil {
    // 解码失败时丢弃 decoded，不能把部分结果当成有效书签。
    return nil, fmt.Errorf("invalid bookmark encoding: %w", err)
}
return decoded, nil

空字符串本身可以是空字节串的合法编码，但目录翻页接口可以规定“传入 bookmark 时必须非空”。编码层允许什么，与接口层允许什么，应分别写清楚。若接口还要区分未传字段和传了空字段，应在读取查询参数时检查字段是否存在。

我也不会把“能解码”当作书签有效：解码后仍要检查字段结构、版本、业务范围与访问权限。Base64 是可逆表示，不提供加密、签名或防篡改；敏感字段与可信凭据需要单独的设计。

给既有接口保留明确的兼容范围

如果是新接口，我会只规定一种无填充 base64url 格式；如果旧接口已经对外约定带填充，就先保持原约定，或通过明确的版本字段迁移。直接删掉旧值的等号再改变解码器，会让兼容行为藏在字符串处理里。

上述表格是接口取舍说明，不是本次执行结果。若确实需要同时接收两种形式，应在接口文档中列明可接受集合和返回格式，限制兼容期，而不是不断尝试多个解码器直到某个成功。

为什么有些 RawURLEncoding 结果看起来没有变化？

输入不同，结果可能没有用到两种特殊字符；某些长度的普通 Base64 本来也不需要填充。外观相同不代表两套编码契约相同。

没有等号是不是更短、更安全？

无填充形式只省略需要填充时的一个或两个等号。它不是压缩，也不会增加保密性；我选它是为了参数格式一致和 URL 使用方便。

可以把中文直接传给 EncodeToString 吗？

先将 Go 字符串转成 []byte，编码的是原始字节。解码返回的也是字节；若协议约定内容是 UTF-8 文本，再按文本约定处理。

在这个目录书签方案中，我会把“无填充 base64url”直接写进字段定义，让 EncodeToString、DecodeString 和接口文档使用同一套预设。这样最小示例与兼容策略才能保持一致。

官方 API：https://pkg.go.dev/encoding/base64#RawURLEncoding；URL 组装文档：https://pkg.go.dev/net/url#Values.Encode；编码规则：https://www.rfc-editor.org/rfc/rfc4648.html。