Go base32.Encoding.WithPadding 怎么生成无填充编码

在 Go 中生成无填充 Base32，直接从现有编码器派生一个新对象：

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

// 新对象会省略末尾的等号，原来的 StdEncoding 不受影响。
text := rawBase32.EncodeToString([]byte("Go"))
fmt.Println(text) // I5XQ

WithPadding(base32.NoPadding) 不会修改 base32.StdEncoding，而是返回一个补位规则不同的新 *base32.Encoding。后续编码和解码都要使用这个新对象，否则最常见的现象就是编码结果仍出现 =，或者无填充文本在解码时被报告格式不完整。

官方文档：https://pkg.go.dev/encoding/base32

最小写法：WithPadding(base32.NoPadding)

项目里通常把无填充 Encoding 保存成包级变量，避免每次调用时重复声明，也能让编码端与解码端清楚地共享同一规则。

package main

import (
    "encoding/base32"
    "fmt"
)

var rawBase32 = base32.StdEncoding.WithPadding(base32.NoPadding)

func main() {
    src := []byte("Go")

    // 编码时使用派生后的无填充对象，而不是 StdEncoding。
    encoded := rawBase32.EncodeToString(src)
    fmt.Println(encoded)

    // 解码端也使用同一个对象，保证补位规则一致。
    decoded, err := rawBase32.DecodeString(encoded)
    if err != nil {
        fmt.Println("decode failed:", err)
        return
    }
    fmt.Printf("%s\n", decoded)
}

示例中的 Go 使用标准补位编码时是 I5XQ====，使用无填充 Encoding 后是 I5XQ。字符表仍然是 A-Z 与 2-7，变化只发生在尾部补位。

第一层检查：为什么结果里仍然有等号

如果已经写了 WithPadding，结果里却仍有 =，先检查真正执行 EncodeToString 的接收者。下面这两行看起来只差变量名，行为却不同：

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

// 错误示例：这里仍调用原始 StdEncoding，所以结果保留等号。
padded := base32.StdEncoding.EncodeToString([]byte("Go"))

// 正确示例：调用 WithPadding 返回的新 Encoding。
unpadded := rawBase32.EncodeToString([]byte("Go"))

fmt.Println(padded, unpadded)

源码中 WithPadding 的接收者是值类型 Encoding。方法先复制现有 Encoding，修改副本的 padChar，再返回指向副本的指针。因此不能只调用一次方法却丢弃返回值，也不能期待全局的 StdEncoding 被改变。

第二层检查：输出长度和尾块是否符合预期

Base32 每 5 个输入字节形成 8 个输出字符。完整的 5 字节块本来就不需要等号，因此某些输入即使使用 StdEncoding，结果也可能看不到补位；判断配置是否生效，最好选择长度不是 5 的倍数的测试数据。

禁用补位后，最后 1、2、3、4 个输入字节分别产生 2、4、5、7 个 Base32 字符，不再补齐到 8 个字符。也就是说，无填充文本每组尾部合法的字符数余量是 0、2、4、5 或 7；余量为 1、3、6 的文本没有足够位数还原完整字节，解码时会失败。

EncodedLen 会跟随 Encoding 的补位规则。带补位时，输出长度按 8 字符块向上取整；无填充时，只计算实际需要的字符。因此自己预分配目标切片时，也应该调用新对象的 rawBase32.EncodedLen(len(src))。

src := []byte("Go")

// 长度必须从无填充 Encoding 计算，避免沿用带补位的容量假设。
dst := make([]byte, rawBase32.EncodedLen(len(src)))
rawBase32.Encode(dst, src)

fmt.Println(string(dst))

第三层检查：解码端是否使用同一规则

无填充不是解码器自动猜测出来的格式。带补位的 StdEncoding 会期待不足 8 字符的尾块带有正确数量的 =；无填充 Encoding 则把输入结尾当作消息结尾，并根据现有字符数还原尾块。

因此协议应明确规定“是否补位”，而不是在失败后随意尝试两套解码器。若双方都能控制，直接共享同一 Encoding 定义；若接收外部数据，则先根据协议字段或接口文档选择规则，并把 CorruptInputError 当作输入格式错误处理。

流式编码别漏掉 Close

base32.NewEncoder 以 5 字节为块工作。最后不足 5 字节的数据会暂存在编码器内部，只有 Close 才会刷新这个尾块。禁用补位只是让刷新后的尾块不添加等号，并不会取消关闭要求。

var buf bytes.Buffer
encoder := base32.NewEncoder(rawBase32, &buf)

// Write 可能把不足 5 字节的尾部暂存在编码器内部。
if _, err := encoder.Write([]byte("Go")); err != nil {
    return err
}

// 即使使用 NoPadding，也必须关闭编码器以刷新最后一个尾块。
if err := encoder.Close(); err != nil {
    return err
}

fmt.Println(buf.String())
return nil

若省略 Close，短输入可能得到空字符串，长输入也可能缺失最后一段。这种现象容易被误判为 NoPadding 配置问题，实际是缓冲尾块没有写出。

用回解比较做反向确认

最稳妥的确认方式不是只检查结果里有没有等号，而是完成一次“编码—解码—字节比较”。它同时验证了 Encoding 选择、补位规则和数据完整性。

func verifyNoPadding(src []byte) error {
    enc := base32.StdEncoding.WithPadding(base32.NoPadding)

    // 先生成无填充文本，再用相同 Encoding 回解。
    text := enc.EncodeToString(src)
    if strings.ContainsRune(text, '=') {
        return fmt.Errorf("unexpected padding in %q", text)
    }

    decoded, err := enc.DecodeString(text)
    if err != nil {
        return fmt.Errorf("decode no-padding base32: %w", err)
    }
    if !bytes.Equal(decoded, src) {
        return fmt.Errorf("round trip mismatch")
    }
    return nil
}

测试数据应覆盖空输入、1 到 4 字节尾块、完整 5 字节块和多个完整块加尾块。这样既能检查输出长度，也能暴露流式关闭或解码器配置不一致的问题。

发布前速查清单

• 保存了 WithPadding(base32.NoPadding) 的返回值。
• 所有编码调用都使用派生后的 Encoding。
• 解码端遵循同一补位规则和同一字母表。
• 预分配长度通过新对象的 EncodedLen 计算。
• 流式编码器在写完后调用了 Close。
• 使用回解和 bytes.Equal 验证原始字节没有变化。

常见问题

Go 的 base32 有没有 RawStdEncoding？

没有像 encoding/base64 那样预定义的 RawStdEncoding。Base32 需要通过 base32.StdEncoding.WithPadding(base32.NoPadding) 自己派生。

WithPadding 会修改 StdEncoding 吗？

不会。它返回一个新的 *Encoding，原来的 base32.StdEncoding 仍使用等号补位。

NoPadding 会改成 HexEncoding 的字母表吗？

不会。NoPadding 只改变补位字符。要使用扩展十六进制字母表，应从 base32.HexEncoding 调用 WithPadding(base32.NoPadding)。

无填充 Base32 一定更适合所有接口吗？

不一定。是否补位属于协议约定。只有接收方明确支持无填充形式时才应禁用补位；对外部标准或已有接口，优先遵守其文档而不是单方面缩短字符串。

最小方案只有一行，但排查时要抓住两个对象：StdEncoding 仍是带补位规则，WithPadding(base32.NoPadding) 返回的新 Encoding 才是无填充规则。编码、解码、长度计算和流式写入统一使用后者，才能得到稳定且可回解的结果。