为什么 Ascii85 编码不允许动态压缩?



根据维基百科:

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

[btoa]4.2版增加了一个";y";一组所有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回车换行符0D 00 0A 00

可以编码为(79字节)

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

使用这种压缩的编码方法有优点吗?为什么各种Ascii85规格在压缩方面不更具攻击性?

因为在使用ASCII85进行编码之前,通常会使用压缩程序,它可以比建议的特殊编码做得更好。

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

最新更新