Go base32 无填充编码后怎样兼容需要补齐等号的系统

我在对接文件名令牌时遇到过一个很容易误判的问题：Go 端生成的 Base32 字符串没有 =，对方却要求输入长度必须是 8 的倍数。这里通常不是数据损坏，而是两端选择了不同的填充契约。Go 的 base32.StdEncoding 默认使用 RFC 4648 填充，WithPadding(base32.NoPadding) 则会关闭填充。

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

兼容的关键是把“编码格式”和“传输表示”分开：发送端可以保留无填充字符串，但在进入只接受标准输入的系统前，按长度规则恢复等号；如果接收端支持无填充，就直接使用同样的 Encoding 解码。不要把等号随意追加到任何字符串末尾。

先确认两端的填充契约

Base32 以 5 个输入字节对应 8 个输出字符。标准编码会把输出补到 8 的倍数，尾部使用 =；无填充编码只保留真正承载数据的字符。因此同一段字节可能出现两种合法表示，它们的字母数字部分相同，长度却不同。

我的经验是先把协议写成一句话：字段是否允许等号、接收方使用哪一种解码器、是否会经过 URL 或文件名层。只要这三个问题没有答案，单纯在发送端“多补几个等号”很容易把兼容问题变成新的脏数据。

用 NoPadding 生成不带等号的字符串

Go 不需要复制字母表，也不需要手工裁剪输出。基于已有编码实例调用 WithPadding(base32.NoPadding)，就能得到一个关闭填充的新编码器。这个新对象只改变填充策略，不改变 Base32 字母表。

package main

import (
    "encoding/base32"
    "fmt"
)

func encodeRawBase32(src []byte) string {
    // WithPadding 返回一个不输出等号的新 Encoding，字节内容仍按 Base32 编码。
    rawEncoding := base32.StdEncoding.WithPadding(base32.NoPadding)
    return rawEncoding.EncodeToString(src)
}

func main() {
    // 示例故意使用不是 5 的倍数的输入，方便观察两种表示的长度差异。
    src := []byte("go-base32")
    fmt.Println(encodeRawBase32(src))
}

如果协议本身允许无填充，直接传递这个结果即可。不要在发送端为了“看起来完整”再拼接 =，因为接收端可能明确约定只接受 NoPadding。

建立无填充长度判断

无填充字符串的长度除以 8 后，合法余数只有 0、2、4、5、7。余数为 1、3 或 6 时，不可能只靠追加等号恢复成合法的 RFC 4648 输入，应直接判为长度错误。

合法输入需要补的等号数量就是 8 - (len(s) % 8)；当余数为 0 时不补。这里的长度是 ASCII 字符数，Base32 字母表只包含单字节字符，所以用 Go 的 len 正好表达协议长度，不要先转成 rune 数量。

在边界层恢复等号

对方只提供标准填充解码器时，可以在协议适配层恢复等号，再把归一化后的字符串交给 base32.StdEncoding.DecodeString。适配函数应同时负责字符错误和长度错误，让上层知道是数据被截断，还是内容本身不在 Base32 字母表内。

package main

import (
    "encoding/base32"
    "fmt"
    "strings"
)

func addBase32Padding(raw string) (string, error) {
    // 只有这些余数能由等号补成完整的 8 字符块；余数 1、3、6 直接拒绝。
    switch len(raw) % 8 {
    case 0:
        return raw, nil
    case 2, 4, 5, 7:
        missing := 8 - len(raw)%8
        return raw + strings.Repeat("=", missing), nil
    default:
        return "", fmt.Errorf("非法的无填充 Base32 长度：%d", len(raw))
    }
}

func decodeForPaddedPeer(raw string) ([]byte, error) {
    // 先补齐长度，再让标准编码器检查字符和填充位置。
    padded, err := addBase32Padding(raw)
    if err != nil {
        return nil, err
    }
    decoded, err := base32.StdEncoding.DecodeString(padded)
    if err != nil {
        return nil, fmt.Errorf("标准 Base32 解码失败：%w", err)
    }
    return decoded, nil
}

这个函数只处理无填充输入。若上游有时会发送已经带等号的字符串，应先制定单独的输入约定：要么统一交给标准解码器，要么在入口处严格区分两种格式，避免把一个格式的清洗逻辑套到另一个格式上。

接收端支持 NoPadding 时不要重复补齐

如果接收端也由 Go 控制，最简单的办法是双方明确使用同一个无填充编码实例：

rawEncoding := base32.StdEncoding.WithPadding(base32.NoPadding)

// 用同一份填充契约解码，避免先补等号再交给 NoPadding 解码器。
decoded, err := rawEncoding.DecodeString(raw)
if err != nil {
    return fmt.Errorf("无填充 Base32 解码失败：%w", err)
}

不要把带 = 的输入直接交给 NoPadding 编码器，也不要把无填充输入直接假定为标准填充输入。编码器对象本身就是协议选择的一部分，最好在接口封装层命名为 rawEncoding 或 paddedEncoding，让调用方不靠猜。

把兼容逻辑放进跨系统交接流程

1. 发送前：记录字段采用 padded 还是 raw 表示；文件名、URL 路径和 JSON 字段不要各自选择一套规则。
2. 进入适配层：若对方只接受标准填充，先检查无填充长度余数，再补到 8 的倍数。
3. 交给解码器：让 StdEncoding 负责字符和填充位置检查，不要自己实现 Base32 字母表解析。
4. 失败时区分：非法余数表示输入长度本身不可能完整，DecodeString 返回错误则还要检查字符是否被篡改。
5. 落库前固定：选择保存原始无填充值、标准填充值，或解码后的字节，不能让下游凭经验决定。

跨系统联调时，最值得保留的是“同一字节输入的 padded/raw 对照样本”。只要两种字符串都能回到同一组字节，就能快速定位是填充契约不一致，还是实际传输改动了字符。

常见误区与选择速查

我通常把“是否带等号”当成接口字段的格式属性，而不是编码完成后的临时修补。这样既能避免不同服务重复实现补齐，也能让测试样本覆盖长度余数为 0、2、4、5、7 以及非法余数的边界。

相关问题

为什么无填充 Base32 的长度不是 8 的倍数？

因为去掉了只用于对齐的等号，尾部仍可能只需要 2、4、5 或 7 个有效字符。补齐后才恢复到标准编码要求的 8 字符块。

可以无条件在字符串末尾补四个等号吗？

不可以。需要根据长度余数计算缺少的数量；余数为 1、3、6 时，追加等号也不能把它变成合法的 Base32 输入。

带等号和不带等号解码出的字节会不同吗？

在它们表示同一份合法 Base32 数据、并交给匹配的编码器时，解码字节应相同。差异在传输表示和接收契约，而不是原始字节。

总结：Go 的 NoPadding 只改变 Base32 的尾部表示，不改变编码字母表。要兼容只接受等号的系统，就在边界层检查无填充长度余数、补到 8 的倍数，再交给 StdEncoding 解码；如果双方都支持无填充，则从编码到解码始终使用同一个 Encoding，不要混用。