Go ascii85.NewDecoder 怎么流式解码分段数据

ascii85.NewDecoder 接收一个 io.Reader，会在内部保留还不够组成完整 ASCII85 数据组的输入，所以分段数据不需要先拼成一个大字符串。把各片段用 io.MultiReader 连接成同一个逻辑输入，再持续读取 NewDecoder 返回的 Reader 即可。真正决定尾部短组是否结束的是合并后数据流的最终 EOF，不是任意一个网络包或业务片段的边界。

用一个 Reader 接住所有分段

下面使用常见的 ASCII85 数据 87cURD]j7BEbo80，把它故意切成三个不对齐的片段。io.MultiReader 对外暴露一个连续 Reader，NewDecoder 不需要知道片段原来来自 HTTP 分块、消息队列还是多个文件块。

package main

import (
    "encoding/ascii85"
    "fmt"
    "io"
    "os"
    "strings"
)

func main() {
    // 片段故意没有按 5 个 ASCII85 字符对齐，模拟真实分段输入。
    parts := []io.Reader{
        strings.NewReader("87cUR"),
        strings.NewReader("D]j7B"),
        strings.NewReader("Ebo80"),
    }

    // MultiReader 把多个来源组合成一个连续的逻辑 Reader。
    encoded := io.MultiReader(parts...)
    decoded := ascii85.NewDecoder(encoded)

    // 持续消费直到合并后的 Reader 返回最终 EOF。
    if _, err := io.Copy(os.Stdout, decoded); err != nil {
        fmt.Fprintf(os.Stderr, "decode ascii85: %v\n", err)
        os.Exit(1)
    }
}

这里不应对每个片段分别调用 ascii85.Decode(..., true)。true 表示“这已经是整个输入末尾”，如果每段都这样处理，位于片段边界的未完成数据组会被错误地当成尾部短组。NewDecoder 的价值正是把这个收尾判断绑定到整个 Reader 的 EOF。

小缓冲读取也不会破坏编码组

调用方每次给多大的输出缓冲，与底层每次返回多少编码字符是两件事。NewDecoder 内部既保留未消费的编码输入，也保留一次解码后尚未交给调用方的输出。因此即使只用很小的缓冲循环读取，片段仍能正确衔接。

func drainDecoder(dst io.Writer, encoded io.Reader) error {
    decoded := ascii85.NewDecoder(encoded)
    buf := make([]byte, 7) // 小缓冲只影响每次交付量，不改变解码边界。

    for {
        n, err := decoded.Read(buf)
        if n > 0 {
            // 先处理已返回的数据，再判断本次 Read 的错误。
            if _, writeErr := dst.Write(buf[:n]); writeErr != nil {
                return fmt.Errorf("write decoded data: %w", writeErr)
            }
        }
        if errors.Is(err, io.EOF) {
            return nil
        }
        if err != nil {
            return fmt.Errorf("read ascii85 decoder: %w", err)
        }
    }
}

这种写法适合需要边读边写文件、计算哈希或传给下游解析器的场景。要点是遵守 io.Reader 契约：一次 Read 可以同时返回 n > 0 和非空错误，不能看到错误就先丢弃已经返回的数据。

片段边界、EOF 与包装符的判断

ASCII85 常以 和 ~> 包裹，但 Go 标准库的 Decode 和 NewDecoder 都要求调用方先移除它们。若包装符可能横跨片段，例如第一个片段以 结束、第二个片段以 ~ 开始，就应在协议 framing 层做跨片段识别，而不是对每个片段单独调用 TrimPrefix 或 TrimSuffix。

把错误位置与片段来源一起记录

输入含非法 ASCII85 字符时，解码器会返回 ascii85.CorruptInputError。它的数值表示错误在解码器当前输入中的字节偏移。分段系统除了记录这个偏移，还应记录请求或对象标识、片段序号、各片段累计长度以及脱敏后的局部上下文，才能把逻辑偏移还原到实际来源。

func classifyDecodeError(err error) string {
    var corrupt ascii85.CorruptInputError
    if errors.As(err, &corrupt) {
        // 只返回可审计的偏移，不把完整载荷写入日志。
        return fmt.Sprintf("invalid ascii85 at byte %d", int64(corrupt))
    }
    if errors.Is(err, io.ErrUnexpectedEOF) {
        // 上游异常截断与正常 EOF 要分开处理。
        return "encoded stream ended unexpectedly"
    }
    return fmt.Sprintf("ascii85 stream error: %v", err)
}

不要遇到错误就删除字符后重试，也不要把非法数据当成正常 EOF。对于来自外部系统的内容，保留原始输入的哈希、分段长度和错误偏移通常比保存完整明文更安全，也更利于复查。

同时限制编码输入和解码输出

流式处理减少了整体驻留内存，但不等于自动获得资源上限。下面的函数给编码输入和解码结果分别留出一个额外字节用于判断超限；只有读到真正 EOF，且两侧都没有触顶，才算完成。

func decodeLimited(dst io.Writer, src io.Reader, maxEncoded, maxDecoded int64) error {
    // 多留 1 字节：N 归零时说明编码输入已经达到或超过限制边界。
    limitedSrc := &io.LimitedReader{R: src, N: maxEncoded + 1}
    decoded := ascii85.NewDecoder(limitedSrc)

    // 同样多读 1 字节，区分“刚好允许”与“已经超出”。
    n, err := io.CopyN(dst, decoded, maxDecoded+1)
    if n > maxDecoded {
        return fmt.Errorf("decoded data exceeds %d bytes", maxDecoded)
    }
    if err != nil && !errors.Is(err, io.EOF) {
        return fmt.Errorf("decode ascii85: %w", err)
    }
    if limitedSrc.N == 0 {
        return fmt.Errorf("encoded data exceeds %d bytes", maxEncoded)
    }
    return nil
}

如果目标 Writer 已经写入部分结果后才发现错误，需要由业务决定是删除临时文件、回滚对象、丢弃缓冲区，还是把对象标记为失败。直接写正式文件时，推荐先写临时目标，成功后再原子替换，避免下游读取半成品。

上线前的检查清单

• 所有分段是否由同一个逻辑 Reader 连续提供，只有最后一个来源结束后才暴露最终 EOF。
• 外层 与 ~> 是否在协议适配层可靠移除，包括跨片段情况。
• 是否区分正常 EOF、上游读错误和 CorruptInputError，并保留片段定位信息。
• 是否同时限制编码输入、解码输出和目标存储，失败后是否清理部分结果。
• 是否用“编码组被任意切开、包装符被切开、最后短组、非法字符、底层读错误”覆盖回归测试。

常见问题

每个片段都必须是 5 个 ASCII85 字符的倍数吗？

不必。NewDecoder 会在内部保存未完成数据组，只要所有片段组成同一个连续 Reader，切分位置可以落在编码组中间。

可以把每个片段分别 Decode 后再拼接结果吗？

通常不可以。若把每个片段都当作完整输入并设置 flush=true，边界上的数据会被误判为尾部短组。应先连接 Reader，再统一解码。

NewDecoder 会自动处理 吗？

不会。官方文档要求调用方剥离这对包装符；如果它们可能跨片段，应由支持跨片段状态的 framing 适配器处理。

为什么流式解码还要限制输出大小？

流式只改变数据的读取方式，不限制总量。没有上限时，攻击者或错误上游仍可能让服务持续占用带宽、磁盘和处理时间。

最稳妥的组合是：用 io.MultiReader 把分段输入变成一个逻辑流，让 ascii85.NewDecoder 管理编码组边界，再由受限的输出复制与明确的错误处理完成收尾。这样既保留流式优势，也不会把网络分片误当成编码边界。