Go ASCII85 文本外层分隔符怎样严格剥离后再解码

我第一次把 Adobe 风格的 ASCII85 文本接进 Go 服务时，真正容易出错的地方不在编码公式，而在文本外层的 和 ~>。Go 的 encoding/ascii85.Decode 只负责解码正文，官方文档明确要求调用方先把这两个符号剥离。

因此，单个完整文本块最稳妥的做法是：先去掉允许的首尾空白，严格检查 与 ~> 是否成对出现，再把中间正文交给 ascii85.Decode。缺少任一分隔符时直接返回包络错误，正文非法时再返回标准库的解码错误。

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

我先把 Adobe 包络和 ASCII85 正文分开

Adobe、PostScript 和 PDF 场景里，ASCII85 数据经常写成 。这里其实有两层责任：

• 包络层：判断输入是不是一个完整的单块文本，并剥离前缀和后缀。
• 编码层：把剥离后的 ASCII85 字符转换成原始字节，并报告正文中的非法字符。

标准库的 Decode 不会替调用方处理第一层。它还会忽略正文中的空格和控制字符，所以“分隔符是否存在”和“正文能否解码”不能混成一个判断。Encode 同样不会自动添加 、~>，这对需要输出 Adobe 风格文本的代码也很重要。

三种处理方式，差别在失败边界

我把常见写法放在一起比较后，发现它们不是“代码长短”的差别，而是对坏输入的态度不同。

如果输入来自文件格式或网络请求，我会选择第三种。它把“格式不完整”和“正文损坏”拆成两个可观察的错误分支，后续日志和调用方处理都更直接。

用一个严格函数剥离单个 Adobe 文本块

下面的函数只承诺处理一个完整文本块。它允许输入两端有空白，但要求去掉空白后以 开始、以 ~> 结束；正文里的再次包络也视为格式错误，不把它交给解码器猜测。

package main

import (
    "bytes"
    "encoding/ascii85"
    "errors"
    "fmt"
)

var errInvalidAdobeFrame = errors.New("ascii85: invalid Adobe frame")

func decodeAdobeFrame(input []byte) ([]byte, error) {
    // 只允许文本块外侧存在空白，真正的包络仍要完整保留并检查。
    frame := bytes.TrimSpace(input)
    if len(frame) ")) {
        return nil, errInvalidAdobeFrame
    }

    // Decode 不识别 Adobe 包络，所以这里只把中间正文切出来。
    body := frame[2 : len(frame)-2]
    if bytes.Contains(body, []byte("")) {
        return nil, errInvalidAdobeFrame
    }

    // flush=true 表示正文到这里结束，末尾不满四字节的块也要处理。
    decoded := make([]byte, ascii85.MaxEncodedLen(len(body)))
    nDst, nSrc, err := ascii85.Decode(decoded, body, true)
    if err != nil {
        // nSrc 能帮助日志定位正文中大致出错的字节位置。
        return nil, fmt.Errorf("decode ascii85 at source byte %d: %w", nSrc, err)
    }
    if nSrc != len(body) {
        // 对单块输入，成功后应当消费完整正文；否则不要返回半成品。
        return nil, fmt.Errorf("ascii85 body not fully consumed: %d/%d", nSrc, len(body))
    }
    return decoded[:nDst], nil
}

这里没有用 strings.Trim 逐个删除字符，因为那会让“删掉了什么”变得不明显。bytes.TrimSpace 只处理两端空白，随后由 HasPrefix 和 HasSuffix 负责确认协议边界。真正的正文切片从索引 2 开始，到末尾前 2 个字节结束，长度变化是确定的。

flush、ndst 和 nsrc 要一起看

ascii85.Decode 返回三个结果：写入目标的字节数 ndst、从输入正文消费的字节数 nsrc，以及错误。ASCII85 按 4 个原始字节为一组编码，末尾可能只有一个不完整组；单个完整文本块已经到达末尾时，应传入 flush=true，告诉解码器不要等待下一块。

decoded[:nDst] 才是有效结果，不能把预分配的整个切片都返回。nsrc 主要用于定位错误和确认正文是否完整消费；在本例的单块契约下，解码无错但没有消费完整正文也不应被当成成功。

包络错误和正文错误不要混为一谈

这两个错误的修复方向完全不同：

• 包络错误：输入缺少 、缺少 ~>、两者不在首尾，或正文里又出现一组包络。调用方应检查上游拼接、字段截断或格式版本。
• 正文错误：包络完整，但 ASCII85 字符本身非法。此时标准库会返回 ascii85.CorruptInputError，可以保留它作为底层原因。

例如，调用方可以只对底层解码错误做类型判断，而不会把缺失后缀误报成“ASCII85 字符损坏”。

var decoded []byte
decoded, err := decodeAdobeFrame(input)
if err != nil {
    // 包络错误没有统一的标准库类型，先按消息或自定义哨兵区分。
    if errors.Is(err, errInvalidAdobeFrame) {
        return fmt.Errorf("reject malformed Adobe frame: %w", err)
    }
    var corrupt ascii85.CorruptInputError
    if errors.As(err, &corrupt) {
        // 保留正文中的损坏位置，方便调用方记录原始输入来源。
        return fmt.Errorf("reject corrupt ASCII85 body: %w", err)
    }
    return err
}

_ = decoded // 这里交给后续业务使用，不在包络层改变数据语义。

需要注意，当前函数把底层错误包在 fmt.Errorf 中，所以 errors.As 仍能取到 CorruptInputError。如果你的协议不需要区分两类错误，也可以只返回原始错误，但日志会少一层上下文。

什么时候改用 NewDecoder

严格单块函数不是所有场景的最佳选择。输入已经是一个内存中的完整字符串时，它能给出最清楚的包络失败边界；如果数据来自长文件、管道或持续连接，则更适合使用 ascii85.NewDecoder 处理 io.Reader。

但流式方案仍然不替你定义 Adobe 包络规则。若协议要求首尾必须是 、~>，就需要在流式读取层先识别包络，或由更高层的帧解析器切出正文后再交给解码器。不要因为换成 NewDecoder 就默认完成了格式校验。

我的选择规则

一句话总结：把包络当成协议，把 ASCII85 当成编码。单块输入先校验并剥离 、~>，正文再交给 Decode(..., true)；只有输入边界真的变成流时，才把方案切换到 NewDecoder。

几个容易继续追问的问题

为什么不直接对完整字符串调用 Decode？

因为官方契约要求调用方先剥离 Adobe 分隔符。完整文本的包络判断也无法替代正文解码，两个责任应当分开。

正文中有空格是不是一定错误？

不一定。Decode 会忽略空格和控制字符；是否允许它们应由你的上层协议决定。本例只严格约束外层包络，没有额外禁止正文空白。

为什么要检查 nsrc？

本例的输入契约是一个完整单块。检查 nsrc 可以避免在未来更换读取方式或拼接逻辑后，误把只消费了一部分正文当成成功。

什么时候必须使用 NewDecoder？

当输入不能一次性放入内存、需要持续从 io.Reader 读取，或者编码数据本身就是长流时，再考虑 NewDecoder。它解决的是流式读取，不会自动替你完成 Adobe 包络协议。