Go base32.AppendDecode 怎样定位无填充输入的长度错误

Go 的 base32.AppendDecode 报“长度错误”时，先别急着扩大目标缓冲区。这个方法会像 append 一样自动扩容，真正容易出错的是编码方式不匹配、无填充字符串的末尾长度不合法，或者把一个 Base32 字符串切在了量子中间。稳妥做法是：先固定 Encoding，清理允许的换行，检查无填充长度余数，再接收 AppendDecode 返回的新切片；只要返回 error，就不要提交其中的部分结果。

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

先把 Padding 选择和输入格式对齐

base32.StdEncoding 默认使用 = 补齐到完整量子；如果上游约定的是短令牌、文件名或配置值，常见做法是使用 WithPadding(base32.NoPadding)。两种编码对象不要混用：把不带等号的文本交给默认编码，或者把带等号的文本交给 NoPadding，都会让排障变成“看起来像长度不对”。

package main

import "encoding/base32"

func decoderForUnpaddedToken() *base32.Encoding {
	// 明确声明输入协议不使用等号填充，避免沿用默认 StdPadding。
	return base32.StdEncoding.WithPadding(base32.NoPadding)
}

用长度余数提前定位无填充错误

Base32 每 8 个字符对应一个 5 字节量子。无填充输入的最后一组可以只留下能还原完整字节的长度，因此清除 \r 和 \n 后，长度对 8 取余为 1、3、6 都是无效形态。余数检查只能定位长度问题，不能替代字符表检查；出现 0、1 等不在标准字母表中的字符，仍要交给解码器返回具体索引。

package main

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

func decodeUnpadded(src []byte) ([]byte, error) {
	enc := base32.StdEncoding.WithPadding(base32.NoPadding)
	// 文档允许忽略 CR/LF；先清理，检查长度时不会把换行算进去。
	clean := bytes.ReplaceAll(src, []byte("\r"), nil)
	clean = bytes.ReplaceAll(clean, []byte("\n"), nil)
	// 1、3、6 个字符只携带不完整的末尾字节，提前返回更容易定位。
	switch len(clean) % 8 {
	case 1, 3, 6:
		return nil, fmt.Errorf("无填充 Base32 长度无效：len=%d，余数=%d", len(clean), len(clean)%8)
	}
	decoded, err := enc.AppendDecode(nil, clean)
	if err != nil {
		// decoded 可能是部分结果；错误时不要把它提交给业务层。
		return nil, fmt.Errorf("Base32 解码失败：%w", err)
	}
	return decoded, nil
}

这里的长度判断来自 Go 标准库解码器对末尾量子的约束。若错误文本是 illegal base32 data at input byte N，重点看 N 指向的原始字符，而不是继续增加 dst 容量。

正确理解 AppendDecode 的返回值和复用缓冲区

它的签名是 ([]byte, error)，返回的切片才是追加后的范围。传入的 dst 可能被原地扩展，也可能因为容量不足换底层数组；只读取旧变量会漏掉新结果。发生格式错误时，返回切片可能包含此前已经解出的前缀，所以要把它当作诊断信息，而不是成功数据。

package main

import "encoding/base32"

func appendTokenPrefix(prefix, encoded []byte) ([]byte, error) {
	enc := base32.StdEncoding.WithPadding(base32.NoPadding)
	// 预留容量只用于减少分配，容量不足不是 AppendDecode 的格式错误。
	dst := make([]byte, 0, len(prefix)+enc.DecodedLen(len(encoded)))
	dst = append(dst, prefix...)
	var err error
	dst, err = enc.AppendDecode(dst, encoded)
	if err != nil {
		// 业务层只接收完整成功结果，保留 err 供日志记录输入位置。
		return nil, err
	}
	return dst, nil
}

分段数据不要切在 Base32 量子中间

AppendDecode 适合把一段完整的编码文本追加解码到已有字节缓冲区，不等于它会替你保存跨调用的半个量子。如果网络或文件读取把 8 个字符拆开，逐段调用可能在第一段就得到长度错误。可以先把编码片段追加到暂存区，等一条消息收齐后统一解码；如果确实是流式输入，则使用 base32.NewDecoder 让解码器维护剩余字符。

常见问题

带等号的输入也能用 NoPadding 解码吗？

不要依赖这种混用。协议明确带等号时使用默认 StdEncoding；只有上游明确取消填充时才构造 NoPadding 编码。

目标缓冲区容量不足会导致长度错误吗？

通常不会。AppendDecode 会扩展目标切片；容量预估只是性能优化，真正需要优先检查的是输入格式和返回的 error。

能把任意分段直接循环调用 AppendDecode 吗？

不能把它当作带内部状态的流式解码器。分段边界不稳定时先累计编码文本，或者使用 NewDecoder，不要把中间错误当成最终数据。