为什么 Ascii85 编码不允许动态压缩？答案

【问题标题】：Why doesn't Ascii85 encoding allow for dynamic compression?为什么 Ascii85 编码不允许动态压缩？
【发布时间】：2016-09-13 06:12:50
【问题描述】：

根据维基百科：

[Ascii85 使用] ASCII 字符 33 (!) 到 117 (u) 包括（表示 base-85 数字 0 到 84），以及字母 z（作为表示 32 位 0 的特殊情况值）。

[btoa] 4.2 版为一组所有 ASCII 空格字符添加了“y”例外

虽然 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 回车换行0D 00 0A 00

可以编码为（79 字节）

<[00;FF;20;2D;09;0D000A00]><~vxyz{|vxyz{|vxyz{|vxyz{|vxyz{|vxyz{|vxyz{|vxyz{|~>

使用这种压缩的编码方法有什么优点吗？为什么各种 Ascii85 规范在压缩方面没有更具侵略性？

【问题讨论】：

标签： encoding compression ascii ascii85 base85

【解决方案1】：

因为您通常会在使用 ASCII85 编码之前使用压缩程序，这比建议的 ad hoc 编码做得更好。

【讨论】：

如果您使用预压缩数据进行编码，那么为什么还要使用z 和y 优化呢？但无论如何，我的理解是 Ascii85 经常用于编码 uncompressed 明文。如果您有特殊字符运行的特殊情况，为什么不让它们与手头的二进制文件相关？
你不会打扰他们。

【解决方案2】：

在某些应用程序中，无需扫描整个字符串即可找到编码字符串的第 N 个八位字节是很有用的。压缩会干扰这一点。然而，在其他应用中，某些形式的压缩可能是有用的。如果可以使用超过 85 个不同的字符，base-85 编码将允许使用主集之外的字符进行轻松压缩。即使一个被限制为一组精确的 85 个字符，五个 base-85 字符的序列数也大于一个、两个、三个和四个 base-256 字节序列的组合数，因此会有空间使用一些特殊的字符组合来表示，例如运行某些字符值。最大的问题是这样做会失去在编码数据流中执行随机搜索的能力。

【讨论】：