Go base32 StdEncoding 和 HexEncoding 有什么区别

Go 的 encoding/base32 预置了两个经常被放在一起比较的编码器：StdEncoding 和 HexEncoding。它们都属于 Base32，输入相同的字节时也遵循相同的 5 位分组思路，但使用的 32 个字符不同，所以生成的文本不能混用。

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

选择可以先按互操作对象判断：对接按 RFC 4648 标准 Base32 书写的协议，使用 StdEncoding；对接明确要求 Extended Hex Alphabet、尤其是 DNS 相关约定时，使用 HexEncoding。如果协议还规定了是否带 =，就要把 padding 规则和编码器一起固定下来。

两种 Encoding 的核心差异是字母表

StdEncoding 的字母表是 ABCDEFGHIJKLMNOPQRSTUVWXYZ234567，也就是 26 个大写字母加数字 2 到 7。HexEncoding 的字母表是 0123456789ABCDEFGHIJKLMNOPQRSTUV，它把数字放在前面，并使用字母 A 到 V。

因此，两者不是“同一串结果的两种显示格式”。同一段输入经过两个编码器后，文本字符的取值空间可能完全不同。只要协议的一端选定了编码器，另一端就必须选择相同的字母表；不能看到字符串像 Base32，就自行猜测是哪一种。

用同一输入看出编码结果为什么不同

Go 代码不需要自己实现 Base32 的位运算，直接调用对应的 Encoding 即可。下面使用同一段字节分别编码，再用各自的解码器还原；示例重点是比较编码器选择，不把输出字符串当成固定业务值。

package main

import (
	"fmt"
	"log"

	"encoding/base32"
)

func main() {
	input := []byte("go-base32")

	// 同一份输入分别交给两个字母表，便于观察文本表示的差异。
	stdText := base32.StdEncoding.EncodeToString(input)
	hexText := base32.HexEncoding.EncodeToString(input)
	fmt.Println("StdEncoding:", stdText)
	fmt.Println("HexEncoding:", hexText)

	// 解码时继续使用产生文本的同一个 Encoding，保持协议两端一致。
	stdBytes, err := base32.StdEncoding.DecodeString(stdText)
	if err != nil {
		log.Fatal(err)
	}
	hexBytes, err := base32.HexEncoding.DecodeString(hexText)
	if err != nil {
		log.Fatal(err)
	}
	fmt.Println("Std 解码:", string(stdBytes))
	fmt.Println("Hex 解码:", string(hexBytes))
}

这段代码中，两次解码都能回到 go-base32，原因不是两个编码器可以互换，而是每个文本都交给了与它匹配的 Encoding。如果把 stdText 改交给 HexEncoding.DecodeString，解码器会按照另一套字符索引解释输入，结果就不再是可靠的互操作路径。

互操作时不要让消费方猜字母表

生产系统里更容易出错的地方不是调用 API，而是协议文档只写了“使用 Base32”，却没有写明是标准字母表还是 Extended Hex Alphabet。消费方收到一串大写字母和数字后，无法仅凭“看起来像 Base32”稳定判断它的来源。

可以把生产方与消费方的组合固定成下面的规则：同一行使用相同的编码器才是兼容组合；跨行组合属于字母表不匹配，不能依赖偶然得到的解码结果。

package main

import (
	"encoding/base32"
	"fmt"
)

func roundTrip(enc *base32.Encoding, name string, input []byte) {
	// 编码和解码共用 enc，name 只用于日志中标明当前协议选择。
	text := enc.EncodeToString(input)
	decoded, err := enc.DecodeString(text)
	if err != nil {
		// 解码失败时保留编码器名称，便于定位两端配置是否错配。
		fmt.Printf("%s 解码失败: %v\n", name, err)
		return
	}
	fmt.Printf("%s 成功: %q -> %q\n", name, text, decoded)
}

func main() {
	payload := []byte("service-id-42")

	// 选择标准 Base32 时，协议双方都传递 StdEncoding 这一约定。
	roundTrip(base32.StdEncoding, "StdEncoding", payload)
	// 选择 Base32hex 时，协议双方都传递 HexEncoding 这一约定。
	roundTrip(base32.HexEncoding, "HexEncoding", payload)
}

实际项目中可以把编码器选择放进协议配置或版本化字段，而不是让调用方在多个位置各自选择。日志里记录 StdEncoding 或 HexEncoding 这样的可读名称，也比只记录一串不可解释的 token 更容易排查跨服务配置不一致。

padding 规则要和字母表一起约定

除了字母表，encoding/base32 默认还使用 = 作为 padding。某些协议会要求去掉尾部 padding，这时要通过 WithPadding(base32.NoPadding) 得到对应的编码器。注意：去掉 padding 并不会把 StdEncoding 变成 HexEncoding，它们仍然是两个独立维度。

package main

import (
	"encoding/base32"
	"fmt"
)

func main() {
	input := []byte("abcde")

	// WithPadding 返回带新 padding 规则的编码器，不改变原始 StdEncoding。
	stdPadded := base32.StdEncoding.EncodeToString(input)
	stdUnpadded := base32.StdEncoding.WithPadding(base32.NoPadding).EncodeToString(input)
	fmt.Println("带 padding:", stdPadded)
	fmt.Println("无 padding:", stdUnpadded)

	// 解码端也要按协议选择相同的 padding 规则。
	enc := base32.StdEncoding.WithPadding(base32.NoPadding)
	decoded, err := enc.DecodeString(stdUnpadded)
	if err != nil {
		// 错误通常说明文本格式或两端约定没有对齐。
		panic(err)
	}
	fmt.Println("还原:", string(decoded))
}

发布接口或配置文件至少应同时记录 alphabet 和 padding 两个字段。例如，StdEncoding + StdPadding 与 StdEncoding + NoPadding 都使用标准字母表，却不是同一种线上文本格式。消费方只有拿到完整组合，才能正确选择解码器。

发布前按这五项固定选择

1. 确认协议原文：如果只写 Base32，先补充是标准字母表还是 Extended Hex Alphabet。
2. 选定 Go 对象：标准 Base32 使用 base32.StdEncoding，Base32hex 使用 base32.HexEncoding。
3. 记录 padding：默认使用 =，明确无填充时使用 WithPadding(base32.NoPadding)。
4. 成对测试：用生产方生成的文本交给消费方的同一组合解码，并覆盖跨组合的拒绝或错误处理。
5. 保留可读日志：记录编码方案名称和协议版本，不要只保留无法判断字母表的结果字符串。

一句话总结：StdEncoding 与 HexEncoding 的本质差异在 32 字符字母表，padding 又是另一条格式约定。先按协议选择编码器，再让两端使用相同的字母表和 padding，才能保证 Base32 文本稳定互通。

相关问题

StdEncoding 和 HexEncoding 编码后的字符串长度会不同吗？

在输入和 padding 规则相同的情况下，二者都属于 Base32，编码长度规律相同；差异主要体现为字符内容，而不是因为 HexEncoding 使用了更多或更少的位。

能不能先用 StdEncoding 编码，再用 HexEncoding 解码？

不应这样设计。解码器会按自己的字母表解释字符，跨字母表使用可能产生解码错误或错误字节，协议两端应固定同一种 Encoding。

只写“Base32”时，Go 应该默认选择哪个？

不要把默认选择当成协议事实。应回到对接方文档确认；如果协议确实采用 RFC 4648 的标准 Base32，再使用 StdEncoding。

关闭 padding 后还能使用 HexEncoding 吗？

可以。padding 规则与字母表相互独立，可以对 HexEncoding 同样调用 WithPadding(base32.NoPadding)，但双方必须使用同一组合。