上周排查一个 git 补丁传输问题：对方用 git format-patch --binary 导出的补丁里，二进制段被 Ascii85 编码成一长串字符，落到邮件客户端后被自动折行，git am 直接报 corrupt patch。我打开 https://base85.quan77.cn/ 把那段流粘进去重新编码，对比原始字节和三种变体的输出，十分钟内定位到是换行符被吞了。这个工具替我做的，是把「哪种 Base85 变体、膨胀率多少、哪里断了」三件事压在同一屏里看清楚，而不是挨个写脚本试。
最快出结果的路径
打开页面后不用先选变体。把二进制内容或待解码的字符串粘进输入框，工具会同时给出 Base85、Ascii85、Z85 三种输出，并标注各自的体积和字符集差异。真正省时间的动作是看输出区的长度对比：如果原始数据是 4 字节对齐的，Z85 的输出最短且不含引号、反斜杠这类在 JSON 里要转义的字符；如果数据来自 PDF 或 PostScript 流，Ascii85 的 <~ ~> 定界符才是对得上的格式。
解码方向同理，粘进去直接看哪种变体能还原出可读字节。不需要先读文档再动手，输出本身就是判断依据。
三个真实场景分别怎么用
场景一：git 二进制补丁的完整性核对。 输入是一段 GIT binary patch 后面的 Ascii85 文本，产出是解码后的字节数和前几个字节的十六进制。我拿它对比 git apply --stat 报出的文件大小，能快速确认补丁段有没有在传输中被截断。这里的关键是 Ascii85 的 z 缩写——连续四个零字节被压成单个 z，工具输出里会明确标出缩写展开后的实际长度，避免按字符数误判。
场景二：PDF 内容流的体积估算。 PDF 里的图像和字体流常用 Ascii85 包一层。把一段流粘进来，看编码前后体积差：Ascii85 的理论膨胀率是 25%，Base64 是 33%。如果一份 PDF 里 Ascii85 段占比很高，转成 Z85 能再省一点，但前提是接收端支持——Z85 是 ZeroMQ 的规范，PDF 阅读器不认。这个场景里工具的价值是给出「换编码能省多少」的实数，而不是让人凭感觉优化。
场景三：嵌入式协议里的短帧编码。 给串口或 MQTT 载荷做文本化时，Z85 的字符集排除了 "、'、\\，粘进 JSON 或 C 字符串不用转义。我拿一段 64 字节的传感器帧试过：Base64 输出 88 字符，Z85 输出 80 字符，且没有转义负担。工具在这里的用处是快速验证输入长度——Z85 要求 4 的倍数，不够时它会直接提示补零，而不是静默截断。
什么时候别用它
Base85 系列不是加密。它只是把二进制映射成可打印字符，任何人拿到编码串都能还原，别拿它当口令保护或防篡改手段。
另一个边界是长度约束。Z85 严格按 4 字节分组，输入不是 4 的倍数时必须补零，解码端要自己知道补了几个字节，否则尾部会多出垃圾。Ascii85 虽然用 z 压缩零串，但对非 4 倍数输入的处理各实现不一致，跨工具传递时容易出偏差。还有，Adobe 风格的 Ascii85 带 <~ ~> 定界符，git 用的是不带定界符的变体，混用会导致解码失败——这个工具会标出定界符差异，但最终还得看对端认哪种。
如果需求是「人眼可读的短标识」，Base58 或 Base62 更合适；如果是「URL 安全」，Base64url 才是标准答案。Base85 的定位始终是「在文本协议里塞二进制，且想少膨胀一点」。
搭配哪些工具更顺手
编码前后常要核对字节，我一般配合十六进制查看器用：先在这里解码出字节流，再粘到 hex 工具里看头部魔数，确认格式没跑偏。另外，做 Base64 与 Base85 的体积对比时，可以顺手用 Base64 编解码工具 跑同一段数据，两个结果并排放，膨胀率差多少一目了然。工具本身不保存输入，粘完刷新即清，处理敏感二进制流时这点比多数在线转换站省心。