Go encoding/base64.RawStdEncoding 怎样处理无填充 Base64

如果接口约定传输的是“标准 Base64，但不带 = 补位”，Go 里应直接使用 base64.RawStdEncoding。它沿用标准 Base64 的 +、/ 字母表，只把 StdEncoding 的补位关闭；如果数据要放进 URL 或文件名，则应改看 RawURLEncoding，不能只因为“没有等号”就混用两者。

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

先分清三种 Base64 编码器

Go 标准库 encoding/base64 按 RFC 4648 提供多种编码器。StdEncoding 使用标准字母表并默认用 = 补齐到四字节一组；RawStdEncoding 是它的无补位版本；RawURLEncoding 则使用 URL 安全字母表，把 +、/ 换成 -、_，同时不补位。

图中的重点是“字母表”和“补位策略”是两个独立维度。判断输入属于哪一种格式时，先确认协议是否允许 +、/，再确认末尾是否允许 =，不要只看字符串长度。

用 RawStdEncoding 生成无填充字符串

生成无填充标准 Base64 时，直接调用 EncodeToString 即可。不要先用 StdEncoding 编码后再通过字符串替换删除等号，因为那会把“编码策略”拆散到两个地方，后续很难判断输入究竟遵循哪份协议。

package main

import (
    "encoding/base64"
    "fmt"
)

func main() {
    raw := []byte("Go 无填充示例")

    // RawStdEncoding 保留标准字母表，但不会在末尾追加等号补位。
    encoded := base64.RawStdEncoding.EncodeToString(raw)
    fmt.Println(encoded)

    // 使用同一个编码器解码，避免把无补位输入交给默认补位编码器。
    decoded, err := base64.RawStdEncoding.DecodeString(encoded)
    if err != nil {
        // 编码结果来自本地生成时也保留错误分支，便于改成外部输入。
        fmt.Println("decode error:", err)
        return
    }
    fmt.Println(string(decoded))
}

实际业务中，编码结果写入 JSON、HTTP 头或数据库前，还要遵守对应字段的字符限制。Raw 标准 Base64 仍可能出现 + 和 /；如果下游把它放进 URL 查询参数，应改用 URL 字母表版本，而不是手工替换字符。

解码时保留错误和部分结果边界

DecodeString 在输入格式错误时会返回部分已解码数据和错误。部分数据不能直接当成完整业务值使用，调用方应该先判断错误，再决定是否丢弃结果、记录原始输入或返回协议错误。

func decodeRawStd(input string) ([]byte, error) {
    // 无填充输入必须交给 RawStdEncoding，不能依赖自动猜测。
    decoded, err := base64.RawStdEncoding.DecodeString(input)
    if err != nil {
        // 只返回错误，不把可能不完整的 decoded 交给后续业务层。
        return nil, fmt.Errorf("invalid raw standard base64: %w", err)
    }
    return decoded, nil
}

这里的规则很简单：错误为 nil 才把结果交给业务逻辑。换行符在标准库解码时会被忽略，但空格、非法字符、错误的补位或不符合协议的字母表，仍应由协议层定义是否接受，不能在函数里无条件清洗。

什么时候补位，什么时候使用 Strict

如果外部协议明确要求无补位，优先保持输入原样并使用 RawStdEncoding。如果某个旧系统偶尔把无补位文本交给需要补位的组件，可以在适配层按长度规则补回 =，但要把这一步写成明确的兼容策略，而不是隐藏在通用解码函数里。

Strict() 的关注点又不同：它要求末尾未使用的填充位为零，用来收紧 RFC 4648 的解码约束。它不是“自动修复补位”的开关，也不负责把标准字母表转换成 URL 字母表。是否启用严格模式，应由协议对规范性的要求决定。

常见问题

RawStdEncoding 和 RawURLEncoding 可以互换吗？

不能。两者都不补位，但字母表不同；前者仍可能出现 +、/，后者使用 -、_。

能不能直接删除 StdEncoding 结果末尾的等号？

不建议。协议层应直接选择 Raw 编码器，保证编码和解码策略对称；字符串替换容易让不同调用点出现不一致。

DecodeString 返回了数据但同时有错误，数据能用吗？

默认不能。返回的数据可能只是成功解码的前缀，除非协议明确规定如何处理部分内容，否则应先记录错误并丢弃该结果。