Go base64.RawStdEncoding 与标准编码的补位差异是什么

Go 的 StdEncoding 和 RawStdEncoding 使用的是同一套标准 Base64 字母表，真正的区别只有一个：是否保留末尾的 = 补位。标准编码会把 1 字节输入写成两个有效字符加两个 =，把 2 字节输入写成三个有效字符加一个 =；Raw 版本把这些补位删掉。两者不是“内容不同”，而是文本格式契约不同。

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

先看同一输入在两种编码器中的差异

排查接口签名、Cookie 或短令牌时，先不要手动拼接或删除字符。把同一组字节分别交给两个编码器，差异会非常直观：

package main

import (
	"encoding/base64"
	"fmt"
)

func main() {
	inputs := [][]byte{[]byte("f"), []byte("fo"), []byte("foo")}
	for _, input := range inputs {
		// 两个编码器使用相同字母表，只比较是否保留 = 补位。
		std := base64.StdEncoding.EncodeToString(input)
		raw := base64.RawStdEncoding.EncodeToString(input)
		fmt.Printf("%q: std=%q raw=%q\\n", input, std, raw)
	}
}

"f": std="Zg==" raw="Zg"
"fo": std="Zm8=" raw="Zm8"
"foo": std="Zm9v" raw="Zm9v"

因此，RawStdEncoding 不是另一种字符表，也不是压缩算法。它是 StdEncoding.WithPadding(base64.NoPadding) 的预定义写法。输入长度刚好是 3 的倍数时，两者本来就会产生相同文本，这也是只拿一条样例判断时最容易漏掉的情况。

为什么同一段数据会出现 =、== 或完全没有补位

Base64 每 3 个字节组成 24 位，再拆成 4 组 6 位索引。最后不足 3 字节时，标准编码用 = 把输出补到 4 个字符：

这个规则解释了为什么删掉 = 后文本长度不一定仍是 4 的倍数。若协议已经通过字段长度、外层结构或其他元数据知道原始字节长度，省略补位通常没有歧义；如果接收方没有这种约定，优先保留标准补位。

编码器和解码器必须遵守同一个格式契约

工程上最隐蔽的错误不是编码失败，而是发送方和接收方对“是否有补位”理解不同。Go 不会把所有 Base64 变体自动当作同一种格式，调用时应让编码器和解码器成对出现：

func decodeToken(rawText string, raw bool) ([]byte, error) {
	// raw 必须来自协议配置，不要依据字符串长度猜测编码格式。
	enc := base64.StdEncoding
	if raw {
		enc = base64.RawStdEncoding
	}
	decoded, err := enc.DecodeString(rawText)
	if err != nil {
		// 把格式错误留在边界处，避免把坏令牌继续传入业务层。
		return nil, fmt.Errorf("decode base64 token: %w", err)
	}
	return decoded, nil
}

例如，标准编码的 Zg== 应交给 StdEncoding；raw 编码的 Zg 应交给 RawStdEncoding。不要把“先补两个 = 再解码”写成全局修复器，因为当协议本来规定标准编码时，重复补位会掩盖调用方的字段错误。

RawStdEncoding 不是 RawURLEncoding

两者都可能没有 =，但字母表不同。RawStdEncoding 仍使用标准 Base64 的 + 和 /；RawURLEncoding 才会使用 URL 和文件名更友好的 -、_。所以判断 URL 兼容性时，不能只检查尾部有没有补位。

上线前可以按下面的清单核对：

• 对端文档是否明确写了 padded、unpadded、base64url 或 RFC 4648。
• 固定测试数据是否同时覆盖 1、2、3 字节余数，而不是只测完整 3 字节。
• 解码错误是否在 API 边界返回，是否记录了实际采用的编码模式。
• 签名、缓存键或比较字符串是否在编码前后统一格式，避免同一字节得到两种文本。

常见问题

RawStdEncoding 会不会改变 Base64 的内容？

不会改变有效 Base64 字符对应的 6 位索引，只是不输出末尾的 =。输入长度是 3 的倍数时，二者结果完全相同。

能不能把 RawStdEncoding 当成 URL 安全编码？

不能。它仍可能包含 + 和 /；需要 URL 或文件名字母表时应选择 RawURLEncoding，并以对端协议为准。

为什么解码时提示 illegal base64 data？

优先检查补位模式、字母表和输入是否混入空格或截断字符，再确认调用的 Encoding 与发送端一致，不要先用字符串替换掩盖问题。