如何在 Golang 中利用 base64.RawURLEncoding 生成省略填充等号的 URL 安全字符串-Golang-PHP中文网

base64.rawurlencoding不自动去除填充=，仅当输入字节数为3的倍数时才无=；需手动trimright裁剪末尾连续=才能确保url安全。

如何在 golang 中利用 base64.rawurlencoding 生成省略填充等号的 url 安全字符串

为什么 `base64.RawURLEncoding` 生成的字符串有时仍有等号？

因为 base64.RawURLEncoding 确实不使用 + 和 /，也省略了换行，但它**不自动去掉填充字符 =**——填充是编码逻辑的一部分，仅当输入字节数恰好是 3 的倍数时才不产生 =。很多人误以为它“天然无填充”，结果在 JWT 或 URL 参数里遇到 = 被 URL 编码或截断的问题。

如何确保输出绝对不含等号？

必须手动裁剪末尾的 =，但不能简单用 strings.TrimRight(s, "=")——因为原始数据末尾若真含有 ASCII =（虽然罕见），会被误删。正确做法是只移除编码后**作为填充出现的等号**，即只去掉末尾连续的 =：

encoded := base64.RawURLEncoding.EncodeToString([]byte("hello"))
clean := strings.TrimRight(encoded, "=")

这个操作安全，因为填充永远在末尾、连续出现、且只可能有 0–2 个。

`RawURLEncoding` 和 `URLEncoding` 的关键区别在哪？

二者都用 - 替代 +、_ 替代 /，但：

Alibabacloud Sdk Client Initialization For Golang

初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。

下载

base64.URLEncoding 保留填充（即可能含 =）
base64.RawURLEncoding 不保留填充（但如上所述，**它不负责移除已有填充**；它只是“不添加”新填充——实际行为是：编码时不加 =，但解码时仍能处理带 = 的输入）

也就是说：RawURLEncoding 的设计目标是「编码输出无换行、无 +//，且解码器容忍无填充输入」，但它不保证输出无 =——因为输入长度决定是否需要填充，而它不干预这个逻辑。

实际用于 JWT 或查询参数时的推荐写法

直接封装成可复用函数，避免每次重复裁剪：

func EncodeURLSafe(data []byte) string {
    encoded := base64.RawURLEncoding.EncodeToString(data)
    return strings.TrimRight(encoded, "=")
}

// 使用示例
tokenPart := EncodeURLSafe([]byte{"foo", "bar"})
// 输出类似：Zm9vYmFy（绝无等号）

注意：解码时仍要用 base64.RawURLEncoding.DecodeString，它能正确处理无填充字符串——这是它比 URLEncoding 更适合 URL 场景的核心原因。

真正容易被忽略的是：裁剪等号这一步不可省略，哪怕你测试时碰巧没出现 =；只要输入长度模 3 不为 0（比如 1 字节、2 字节、4 字节……），就一定会出 =。