Go Base64 URL 编码怎么去掉填充符又能正确解码

我在处理 URL 参数和令牌时，最容易踩到的坑不是 Base64 字符表，而是末尾的 = 填充：一端把它去掉，另一端却仍用要求填充的解码器，结果就会出现 illegal base64 data。在 Go 里，去掉填充不需要手动截字符串，直接使用 base64.RawURLEncoding 编码和解码即可。

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

如果协议约定使用无填充的 URL 安全 Base64，就用 RawURLEncoding.EncodeToString 生成数据，再用同一个编码器的 DecodeString 还原。URLEncoding 与 RawURLEncoding 的区别是填充规则，不要只把 = 删除后继续混用解码器。

先弄清两个“URL Base64”差异

这里说的 URL Base64 不是把字符串交给 url.QueryEscape，而是 Base64 的 URL 安全字母表：把普通 Base64 中的 + 换成 -，把 / 换成 _。在这个基础上，还可以选择保留或取消末尾的 = 填充。

所以“去掉填充符”只解决了编码格式的一半问题。输入如果还可能包含 + 或 /，那是字符表不匹配；输入如果含有 =，那是填充规则不匹配，应该先按协议确定允许的格式。

用 RawURLEncoding 成对完成编码和解码

最小写法是让同一个编码器负责两端。下面的示例使用一段包含中文的字节数据，重点观察编码结果没有末尾等号，以及解码后仍按字节还原。

package main

import (
    "encoding/base64"
    "fmt"
)

func main() {
    source := []byte("order=17golang&状态=已签名")

    // RawURLEncoding 使用 URL 安全字符表，并关闭 '=' 填充。
    encoded := base64.RawURLEncoding.EncodeToString(source)
    fmt.Println(encoded)

    // 编码和解码规则必须成对，否则填充约定可能不一致。
    decoded, err := base64.RawURLEncoding.DecodeString(encoded)
    if err != nil {
        fmt.Println("解码失败:", err)
        return
    }
    fmt.Println(string(decoded))
}

这里不需要 strings.TrimRight(encoded, "=")。RawURLEncoding 本身就是把 URL 安全字母表与 NoPadding 组合好的编码器，生成和解析的意图更清晰，也不会误删正文中本来就不该动的字符。

为什么不能只删等号再继续用 URLEncoding

如果已有代码使用 URLEncoding，编码结果通常带有填充。手工删除 = 后，接收端若仍使用 URLEncoding.DecodeString，就把一个无填充字符串交给了有填充约定的解码器。这个组合在长度刚好是 4 的倍数时可能看不出问题，但遇到需要补齐的长度就会失败，问题也很难从字符串表面判断。

更稳妥的方式是从源头切换编码器：

package main

import (
    "encoding/base64"
    "fmt"
)

func main() {
    raw := []byte("go-url")

    // 有填充版本适合协议要求保留 '=' 的场景。
    padded := base64.URLEncoding.EncodeToString(raw)
    // 无填充版本适合协议明确约定 Raw URL Base64 的场景。
    unpadded := base64.RawURLEncoding.EncodeToString(raw)

    fmt.Printf("有填充: %s\n", padded)
    fmt.Printf("无填充: %s\n", unpadded)
}

两种编码的字节含义相同，差别在表示方式。不要因为无填充字符串更短，就默认所有接口都能接受它；接口契约才是选择编码器的依据。

上游格式不确定时，做有限兼容

在 JWT 的某些字段、历史 URL 参数或跨语言接口里，输入可能有时带 =、有时不带。此时不要无条件删除所有等号，而是先尝试协议优先的规则，再明确回退到另一种规则，并保留错误。

package main

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

func decodeURLBase64(value string) ([]byte, error) {
    // 先按无填充格式解析，适配当前约定的令牌格式。
    decoded, err := base64.RawURLEncoding.DecodeString(value)
    if err == nil {
        return decoded, nil
    }

    // 兼容明确允许带 '=' 的旧输入，但不吞掉两次失败的原因。
    decoded, paddedErr := base64.URLEncoding.DecodeString(value)
    if paddedErr == nil {
        return decoded, nil
    }
    return nil, errors.Join(err, paddedErr)
}

func main() {
    decoded, err := decodeURLBase64("Z28tdXJs")
    if err != nil {
        fmt.Println("输入不是合法的 URL Base64:", err)
        return
    }
    fmt.Println(string(decoded))
}

这个回退策略只适用于协议确实声明两种形式都可接受的场景。如果接口只允许一种格式，建议只调用对应的解码器，这样错误更早暴露，数据边界也更清楚。

解码报错时先看字符、长度和填充

Base64 解码失败时，我会按下面的顺序排查，而不是先把字符串改到“能解码”为止。

1. 看字符表。 URL 安全格式应使用 - 和 _；如果出现 + 或 /，先确认发送端是否用了普通 Base64。
2. 看填充约定。 RawURLEncoding 不要求 =；URLEncoding 负责带填充输入。不要凭经验在中间层删除字符。
3. 看长度和截断。 字符串被 URL 截断、复制时混入空格或少了一个字符，换编码器也救不回来。
4. 保留 error。 DecodeString 返回的错误包含非法输入位置，应该记录必要的字段上下文，但不要把完整令牌写入日志。

package main

import (
    "encoding/base64"
    "fmt"
)

func main() {
    input := "Z28tdXJs="

    // 这里故意使用无填充解码器，观察不符合约定时的错误。
    decoded, err := base64.RawURLEncoding.DecodeString(input)
    if err != nil {
        // 只输出错误位置和业务字段，不输出完整令牌。
        fmt.Printf("token 字段解码失败: %v\n", err)
        return
    }
    fmt.Println(string(decoded))
}

我最后会这样选

我的经验是：把“URL 安全字符表”和“是否填充”当成两个开关来沟通，代码就不容易出现“看起来只是少了两个等号，为什么解码失败”的问题。真正重要的不是字符串短了多少，而是发送端、存储层和接收端对同一套格式有明确且一致的约定。

常见相关问题

• RawURLEncoding 和 URLEncoding 是不是两种不同的 Base64 算法？ 不是，主要差别是 URL 安全字符表下是否保留填充符。
• 可以先用 strings.TrimRight 去掉等号吗？ 只有在你同时确定接收端使用无填充规则时才有意义；通常直接从编码端使用 RawURLEncoding 更稳。
• 为什么普通 StdEncoding 不能直接解 URL 参数？ 普通字母表包含 + 和 /，它们在 URL 或表单处理链路中可能被特殊解释，应使用 URL 安全字母表。
• 输入带空格时要不要自动清理？ 先确认空格来自传输层还是数据本身；对令牌类字段更建议拒绝并记录字段上下文，而不是静默修正。

技术依据：Go 标准库 encoding/base64 文档与 Go 官方源码中的 URLEncoding、RawURLEncoding、NoPadding 定义。