Go base32.WithPadding 怎么兼容带等号和无填充字符串

Go 的 encoding/base32 默认使用标准填充，编码结果可能在末尾出现一个或多个 =。如果对编码实例调用 WithPadding(base32.NoPadding)，则会关闭这段填充，但 Base32 字母表和数据本身并没有改变。

因此，兼容两种字符串时，关键不是把等号简单删掉，而是让输入交给匹配的 Encoding。带等号优先使用 base32.StdEncoding，无填充输入使用 base32.StdEncoding.WithPadding(base32.NoPadding)。如果数据库里两种历史格式并存，可以在读取入口做双路尝试；新写入则固定一种协议。

不要把 StdPadding 和 NoPadding 当成两套 Base32 算法。它们使用同一字母表，差别只在最后的填充规则；兼容读取和统一写入应该分开设计。

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

先从输出末尾判断是哪种格式

默认的 base32.StdEncoding 是标准 Base32 编码实例，EncodeToString 会按标准规则补齐分组。base32.StdEncoding.WithPadding(base32.NoPadding) 返回另一个关闭填充的编码实例，适合令牌、路径片段或已经约定不带等号的字段。

两者的输入数据和字母表相同，差别集中在字符串长度和末尾字符。不要用“有没有等号”作为唯一的业务鉴权依据，它只能帮助选择解码器；真正的数据校验仍然要依赖解码错误和后续业务校验。

带等号和无填充要使用不同的 Encoding

如果协议明确规定字符串带等号，就直接使用标准编码实例；如果协议规定不带等号，就创建一个关闭填充的实例。WithPadding 返回新编码，不会把全局的 StdEncoding 改成无填充，所以可以把两种实例放在同一个包级变量中。

package main

import (
	"encoding/base32"
	"fmt"
)

var (
	// 标准协议保留 RFC 4648 的等号填充。
	standardBase32 = base32.StdEncoding
	// 兼容 URL 片段等场景时，显式关闭末尾填充。
	compactBase32 = base32.StdEncoding.WithPadding(base32.NoPadding)
)

func main() {
	data := []byte("go-token")

	// 同一组原始字节使用两种输出约定，字母表仍然相同。
	withPadding := standardBase32.EncodeToString(data)
	withoutPadding := compactBase32.EncodeToString(data)

	fmt.Println("带填充:", withPadding)
	fmt.Println("无填充:", withoutPadding)
}

这里的选择应当跟字段协议绑定，而不是跟调用方临时决定。比如数据库列原本保存带等号字符串，新接口想输出无填充字符串，可以新增一个明确的序列化函数；不要让同一个字段今天按一种格式写入、明天按另一种格式写入。

混合历史数据可以做双路解码

迁移期间最常见的情况是：旧记录带等号，新记录已经关闭填充。此时可以先用标准编码尝试，失败后再用无填充编码尝试。两次都失败时，保留原始错误上下文，方便调用方判断输入损坏，而不是静默返回空字节。

package main

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

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

func decodeCompatible(s string) ([]byte, error) {
	// 先按主协议解码，优先保留带等号格式的错误信息。
	data, standardErr := base32.StdEncoding.DecodeString(s)
	if standardErr == nil {
		return data, nil
	}

	// 历史数据可能没有填充，再交给关闭填充的编码尝试一次。
	data, compactErr := compactEncoding.DecodeString(s)
	if compactErr == nil {
		return data, nil
	}

	// 两种格式都不能解释时，返回可追踪的组合错误，不把失败伪装成空结果。
	return nil, fmt.Errorf("base32 格式不兼容: 标准格式: %w; 无填充格式: %v", standardErr, compactErr)
}

func main() {
	for _, input := range []string{
		base32.StdEncoding.EncodeToString([]byte("go-token")),
		compactEncoding.EncodeToString([]byte("go-token")),
		"not-base32!",
	} {
		data, err := decodeCompatible(input)
		if err != nil {
			fmt.Println("解码失败:", errors.Unwrap(err))
			continue
		}
		fmt.Printf("解码成功: %q\n", data)
	}
}

双路尝试适合有明确兼容窗口的输入边界。它不代表任何字符串都应该无限放宽：换行符是否允许、大小写是否允许、字段是否必须匹配某个业务长度，都要由你的协议单独决定。

把失败现象分成三层检查

遇到“带等号能解码、去掉等号就失败”时，可以按下面顺序检查：

1. 先看编码实例：确认调用的是 StdEncoding 还是 WithPadding(base32.NoPadding)，不要只看函数名。
2. 再看输入形态：记录原始字符串是否真的含有 =，长度是否来自截断、URL 参数清洗或数据库字段裁剪。
3. 最后看错误：检查 DecodeString 返回的错误，不要因为拿到了部分字节就把结果当成完整数据。

Go 官方文档说明，输入格式错误时解码可能返回部分数据和 CorruptInputError。因此“返回了非空字节”不能证明输入完整；调用方必须先处理错误，再使用结果。

新写入应该统一一种格式

兼容读取可以暂时双路，但写入最好只有一个出口。若新协议偏向可复制、可放进路径或不希望出现保留字符，可以统一使用无填充；若要与已有外部系统或标准样例保持一致，则继续使用标准填充。选择哪一种并不是性能问题，而是接口契约问题。

一个实用的迁移顺序是：

1. 读取端同时兼容旧的带填充和新的无填充。
2. 写入端只生成一种约定，并在接口文档写出是否允许 =。
3. 统计旧格式读取次数，确认兼容窗口已经收窄。
4. 迁移完成后删除不再需要的第二路解码，避免未来协议继续漂移。

一张清单记住兼容边界

常见问题

调用 WithPadding 会修改 StdEncoding 吗？

不会。它返回一个配置不同的新 Encoding，原来的标准编码实例仍然可以继续使用。

只删除末尾等号就一定等于 NoPadding 吗？

不一定。只有在输入本来就是合法的标准 Base32、且删除动作符合协议约定时，才可能得到对应的无填充表示。更稳妥的做法是让编码器按目标格式生成，读取时使用匹配的解码器。

能不能只用一个解码器自动兼容两种格式？

标准库的填充配置属于 Encoding 实例。混合格式输入通常需要按协议明确选择，或在兼容窗口内依次尝试两个实例；不要把输入预处理成无法追踪的字符串。

无填充格式是不是更安全？

不是。填充只影响表示方式，不替代鉴权、完整性校验或业务字段校验。安全边界应由完整的协议设计负责。

最后可以把原则压缩成一句话：StdPadding 负责标准表示，NoPadding 负责无填充表示；读旧数据时兼容两者，写新数据时只选一种。