为什么 Ascii85 编码不允许动态压缩？
Why doesn't Ascii85 encoding allow for dynamic compression?
根据维基百科：
[Ascii85 uses] the ASCII characters 33 (!) through 117 (u) inclusive (to represent the base-85 digits 0 through 84), together with the letter z (as a special case to represent a 32-bit 0 value).
[btoa] Version 4.2 added a "y" exception for a group of all ASCII space characters
虽然 0 数据可能很常见，但使用 z 来压缩 0 似乎是一种并不总是有用的任意优化。
同样，较少使用的y仅在原始字节包含相邻的space时才有用。 space 的 Unicode 编码实际上是 20 00 所以 0x20202020 在 Unicode 文本中并不常见。
二进制数据确实经常有相邻的 00，但它也经常包含相邻的 FF。
文本数据确实经常包含相邻的 space，但它也经常包含相邻的制表符或相邻的换行符。
频率分析和使用 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
Note the presence of spaces 20, hyphens 2D, tabs 09 and Unicode Carriage Return-Line Feeds 0D 00 0A 00
可以编码为（79 字节）
<[00;FF;20;2D;09;0D000A00]><~vxyz{|vxyz{|vxyz{|vxyz{|vxyz{|vxyz{|vxyz{|vxyz{|~>
使用这种压缩的编码方法是否有优点？为什么各种 Ascii85 规范在压缩方面没有更具侵略性？
因为您通常会在使用 ASCII85 编码之前使用压缩程序，这比建议的临时编码要好得多。
对于某些应用程序来说，无需扫描整个字符串即可找到编码字符串的第 N 个八位字节非常有用。压缩会干扰这一点。然而，还有一些其他应用程序可以使用某些形式的压缩。如果可以使用超过 85 个不同的字符，则 base-85 编码将允许使用主要集之外的字符轻松进行压缩。即使限制为一组恰好 85 个字符，五个 base-85 字符的序列数也大于 1、2、3 和 4 个 base-256 字节的序列组合数，因此会有空间使用一些特殊的字符组合来表示，例如某些字符值的运行。最大的问题是这样做会丧失在编码数据流中执行随机查找的能力。
根据维基百科：
[Ascii85 uses] the ASCII characters 33 (!) through 117 (u) inclusive (to represent the base-85 digits 0 through 84), together with the letter z (as a special case to represent a 32-bit 0 value).
[btoa] Version 4.2 added a "y" exception for a group of all ASCII space characters
虽然 0 数据可能很常见，但使用 z 来压缩 0 似乎是一种并不总是有用的任意优化。
同样，较少使用的y仅在原始字节包含相邻的space时才有用。 space 的 Unicode 编码实际上是 20 00 所以 0x20202020 在 Unicode 文本中并不常见。
二进制数据确实经常有相邻的 00，但它也经常包含相邻的 FF。
文本数据确实经常包含相邻的 space，但它也经常包含相邻的制表符或相邻的换行符。
频率分析和使用 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 00Note the presence of spaces
20, hyphens2D, tabs09and Unicode Carriage Return-Line Feeds0D 00 0A 00
可以编码为（79 字节）
<[00;FF;20;2D;09;0D000A00]><~vxyz{|vxyz{|vxyz{|vxyz{|vxyz{|vxyz{|vxyz{|vxyz{|~>
使用这种压缩的编码方法是否有优点？为什么各种 Ascii85 规范在压缩方面没有更具侵略性？
因为您通常会在使用 ASCII85 编码之前使用压缩程序，这比建议的临时编码要好得多。
对于某些应用程序来说，无需扫描整个字符串即可找到编码字符串的第 N 个八位字节非常有用。压缩会干扰这一点。然而，还有一些其他应用程序可以使用某些形式的压缩。如果可以使用超过 85 个不同的字符，则 base-85 编码将允许使用主要集之外的字符轻松进行压缩。即使限制为一组恰好 85 个字符，五个 base-85 字符的序列数也大于 1、2、3 和 4 个 base-256 字节的序列组合数，因此会有空间使用一些特殊的字符组合来表示，例如某些字符值的运行。最大的问题是这样做会丧失在编码数据流中执行随机查找的能力。