根据维基百科：
[Ascii85使用] ASCII字符33（！）到117（u）包括（表示基数-85位0到84），以及字母z（作为表示32位0的特殊情况）值）。
[btoa]版本4.2添加了＆＃34; y＆＃34;一组所有ASCII空格字符的异常
虽然0数据可能很常见，但使用z来压缩0似乎是一种永远无法使用的任意优化。
同样，如果原始字节包含相邻空格，则y的使用频率较低。空间的Unicode编码实际上是20 00，因此0x20202020在Unicode文本中并不常见。
二进制数据通常具有相邻的00，但它通常也包含相邻的FF。
文本数据通常包含相邻的空格，但它通常还包含相邻的制表符或相邻的换行符。
似乎频率分析，使用9或10个字符（Ascii字符118-126 / 127，或v到~ / DEL ）来表示9/10最常见的32位值，可能会导致更好的压缩。
压缩字符到32位值的映射可能位于<[和]>之间的编码字符串的开头。对于4位重复字节的32位值，32位值可以缩写为重复的十六进制值。
例如：
二进制数据（192字节）：
00 00 00 00 FF FF FF FF 20 20 20 20 2D 2D 2D 2D 09 09 09 09 0D 00 0A 00
00 00 00 00 FF FF FF FF 20 20 20 20 2D 2D 2D 2D 09 09 09 09 0D 00 0A 00
00 00 00 00 FF FF FF FF 20 20 20 20 2D 2D 2D 2D 09 09 09 09 0D 00 0A 00
00 00 00 00 FF FF FF FF 20 20 20 20 2D 2D 2D 2D 09 09 09 09 0D 00 0A 00
00 00 00 00 FF FF FF FF 20 20 20 20 2D 2D 2D 2D 09 09 09 09 0D 00 0A 00
00 00 00 00 FF FF FF FF 20 20 20 20 2D 2D 2D 2D 09 09 09 09 0D 00 0A 00
00 00 00 00 FF FF FF FF 20 20 20 20 2D 2D 2D 2D 09 09 09 09 0D 00 0A 00
00 00 00 00 FF FF FF FF 20 20 20 20 2D 2D 2D 2D 09 09 09 09 0D 00 0A 00请注意是否存在空格
20，连字符2D，制表符09和Unicode载体返回Feed0D 00 0A 00
可编码为（79字节）
<[00;FF;20;2D;09;0D000A00]><~vxyz{|vxyz{|vxyz{|vxyz{|vxyz{|vxyz{|vxyz{|vxyz{|~>
使用此类压缩的编码方法是否有价值？为什么各种Ascii85规范在压缩方面更具侵略性？
答案 0 :(得分：3)
有些应用程序能够找到编码字符串的第N个八位字节而不必扫描整个字符串。压缩会干扰这一点。然而，存在某些形式的压缩可能有用的其他应用。如果一个人可以使用超过85个不同的字符，则base-85编码将允许使用主要集合之外的字符轻松压缩。即使一个被限制为一组精确的85个字符，五个base-85个字符的序列数大于一个，两个，三个和四个base-256字节的序列组合数，因此会有空间使用一些特殊的字符组合来表示例如运行某些字符值。最大的问题是，这样做会丧失在编码数据流中执行随机搜索的能力。
答案 1 :(得分：2)
因为在使用ASCII85编码之前通常会使用压缩程序，这可以比建议的ad hoc编码做得好得多。