go标准库不提供base85编码支持，因其非ietf标准、实现不统一且使用场景窄；推荐使用tmthrgd/ascii85等第三方包进行adobe风格ascii85编码。
Go 标准库不提供 base85 编码支持，也没有官方或广泛认可的 Base85 实现 —— 所以直接用 encoding/base64 或第三方包硬套 base85 名字，大概率会出错或编码结果不兼容。
为什么 Go 没有内置 base85？
Base85（也称 Ascii85）是一种比 Base64 更紧凑的二进制编码方案，常见于 PDF、PostScript 和 Git 的 packfile 中。但它不是 IETF 标准，不同实现（如 Adobe vs. Zlib vs. Git）在起始/结束标记、空字节处理、换行策略上存在差异。Go 选择不纳入有歧义、使用场景窄、且易误用的编码方式。
如果你看到某个 Go 包声称“支持 Base85”，请重点确认它遵循的是：
-
ascii85（Adobe 风格，含/ <code>~>标记） -
z85（ZeroMQ 风格，完全不同的字符表和规则） - 还是仅是“用 85 个字符做 baseN 编码”的自定义变种
如何对文件内容做 Ascii85（Adobe 风格）编码？
推荐使用社区维护较久、测试覆盖较全的 github.com/Comcast/gots 中的 ascii85 子包，或更轻量的 github.com/tmthrgd/ascii85（无依赖、纯函数式）。
以 tmthrgd/ascii85 为例，实操步骤如下：
- 运行
go get github.com/tmthrgd/ascii85 - 读取文件用
os.ReadFile，避免逐块处理引入边界错误 - 调用
ascii85.Encode（注意：它不加换行、不加头尾，符合 RFC 1924 前身但非完整 Adobe 格式） - 若需严格 Adobe 兼容（如生成可嵌入 PDF 的数据），得手动拼接
+ 编码结果 + <code>~>，并确保输入长度是 4 字节对齐（不足补\x00，编码后需截去对应数量的u字符）
示例片段：
data, _ := os.ReadFile("input.bin")
encoded := ascii85.Encode(data)
fmt.Print("")
z85 编码更适合命令行或跨语言调试场景
ZeroMQ 的 z85 更简洁、无标记、无换行、字符全部可打印且 URL 安全（不含空格、+/=），适合日志埋点或 CLI 工具输出。它的 Go 实现有 github.com/jedisct1/go-z85。
关键差异点：
-
z85.Encode要求输入字节数必须是 4 的倍数，否则 panic —— 你得自己 pad（例如用bytes.PadRight或手动补\x00） - 解码时若遇到非法字符（如
q、v不在 z85 字符表中），会返回 error，不静默跳过 - 编码后长度恒为
len(src)/4*5，而 Ascii85 可变长（因 4→5 压缩但含压缩优化逻辑）
所以如果你只是想快速把一段配置文件转成“看着像密文”的字符串用于调试，z85 比 Ascii85 更省心。
文件编码后体积和可读性的真实情况
Base85 类编码对小文件（10KB 的二进制块上，压缩率约比 Base64 高 20%。
但要注意：
- 所有 Base85 变种都不被浏览器、主流 JSON/YAML 解析器原生识别，不能直接当字符串字段存配置
- Git 的
git pack-objects用的是自定义 Ascii85（带换行、无头尾标记），和上述两个 Go 包均不完全兼容 - 如果你只是想“趣味转换”，建议先用 Python 的
base64.a85encode(..., pad=True)对照验证 Go 输出，避免字符表错位
Ascii85/z85 的真正门槛不在编码本身，而在确认上下游系统接受哪一种、是否允许 padding、是否要换行 —— 这些细节不匹配，解码端就直接失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
