Go ascii85.Decode 遇到不完整尾块时怎样判断输入是否截断

处理分块读取的 ASCII85 文本时，最容易误判的是“尾部还差几个字符”。ascii85.Decode 的正确判断方式不是只看输出长度，而是同时看 ndst、nsrc、flush 和 err：继续读取时用 flush=false 保留未完成尾块，确定流结束后再用 flush=true 收尾。这样，暂时没读全不会被当成损坏，真正只有一个尾字符的截断也不会被悄悄吞掉。

官方文档：https://pkg.go.dev/encoding/ascii85#Decode

先把 ndst、nsrc 和 flush 看成三种不同信号

Decode(dst, src, flush) 返回三个值。ndst 是已经写入 dst 的字节数，nsrc 是本次调用已经消费的输入位置，flush 则是“这是不是输入流最后一块”的声明。它们不能互相替代。

例如一块输入里有一个完整五字符组，后面又跟着两个字符。第一次调用如果传入 flush=false，完整组会写入 4 个字节，nsrc 停在完整组之后，两个字符仍在 src[nsrc:] 中。它们不是错误，只是下一次读取的前缀。

用 nsrc 搬移尾部，别按五字符硬切输入

网络读取或文件读取不会保证每次刚好落在 ASCII85 的五字符边界。调用方应把未消费部分搬到缓冲区前面，再追加下一次读取的数据。下面的函数用切片模拟多次读取，最后一块才打开 flush。

package main

import (
    "encoding/ascii85"
    "fmt"
)

func decodeChunks(chunks [][]byte) ([]byte, error) {
    var pending []byte
    decoded := make([]byte, 0, 64)

    for i, chunk := range chunks {
        // 把上次未消费的尾块放在新输入前面，不能直接丢弃。
        pending = append(pending, chunk...)
        flush := i == len(chunks)-1

        // 预留足够空间，额外的 4 字节覆盖最后的短块。
        dst := make([]byte, len(pending)*4/5+4)
        ndst, nsrc, err := ascii85.Decode(dst, pending, flush)
        if err != nil {
            // 非法字符和结束时的单字符尾块都必须交给上层处理。
            return nil, fmt.Errorf("ASCII85 解码失败：%w", err)
        }
        decoded = append(decoded, dst[:ndst]...)

        // nsrc 之前已消费；之后的内容留给下一轮继续拼接。
        pending = append(pending[:0], pending[nsrc:]...)
    }
    if len(pending) != 0 {
        return nil, fmt.Errorf("输入结束时仍有未处理尾部")
    }
    return decoded, nil
}

实际接入 io.Reader 时，循环条件可以改成“读到 EOF 后再调用一次 flush=true”。如果中间调用返回 err == nil 但 pending 非空，这是等待更多输入；不要因为 ndst 没有增加就报错。

真正结束读取时才用 flush=true

flush=true 会告诉解码器：src 已经是最后一段，不能再等后续字符。此时短尾块的判断才有意义。ASCII85 的短编码会根据尾部字符数产生少于 4 个字节的输出，单字符没有足够信息，才会形成明确的截断错误。

还要区分非法字符：字符不在 ASCII85 的有效范围内时，返回的是 CorruptInputError，这不是“尾块还没收齐”。错误发生后不要继续用同一段输入盲目重试，应记录输入位置并检查上游是否混入了包装符号、业务分隔符或未清理的二进制字节。官方实现要求调用者先去掉常见的 、~> 包装。

常见问题

为什么第一次 Decode 没有报错，却没有得到最后几个字节？

如果使用了 flush=false，解码器默认后面还会有输入，未完成的五字符组会被保留。检查 nsrc，把未消费部分带到下一次调用。

可以直接把每次读取的切片截成 5 的倍数吗？

不建议。读取边界和编码边界没有关系，硬切会把尾字符丢掉。应按 nsrc 搬移，或直接使用 ascii85.NewDecoder 处理流式读取。

单字符尾部一定说明网络传输损坏吗？

只有在确认已经到达真正 EOF 后才这样判断。中间块里的单字符只是暂存数据；在 flush=true 的结束调用中仍剩一个有效字符，才是格式层面的截断信号。

排查这类问题时，先确认是否真的结束读取，再看 nsrc 是否正确保留尾部，最后才根据 CorruptInputError 判断输入格式。这样能把“暂时不完整”和“确实损坏”分开处理。