缩小258双重编码的长度

Question

在Deflate算法中，有两种方法可以编码258的长度：

1. 所有1＆＃39>的代码284 + 5个额外位

2. 代码285 + 0额外位;

乍一看，这不是最佳的，因为正确使用代码285将允许编码长度为259;

这种二元性是否有一些规范错误，由于兼容性原因没有修复，或者有一些关于它的论点 - 例如258的长度必须用较短的代码（0个额外的位）编码，因为某些原因？

Answer 1

我们可能永远不会知道。放射形式的开发者Phil Katz很多年前就去世了。

我的理论是匹配长度限制为258，因此3..258范围内的匹配长度可以适合一个字节，编码为0..255。这种格式是在1990年左右开发的，当时这可能会对汇编程序的实现产生影响。

Answer 2

在这里添加第二个答案以强调Mark猜测允许以字节编码长度有助于汇编程序实现。当时8086级汇编程序仍然很常见，使用8位寄存器可以让你使用16位以上的寄存器。

在诸如6502的8位处理器上的好处更加明显。它从长度解码开始。符号257 ... 264分别表示3..10的匹配长度。如果你取这些符号的低字节（1 ... 8），你得到的匹配长度恰好比匹配长度小2。

更复杂但相当容易计算的公式比符号265到284的匹配长度小2。比符号285的匹配长度小256.这不适合一个字节，但我们可以存储0结果证明是等价的。

zlib6502使用它具有相当大的优势。它以inflateCodes_lengthMinus2计算匹配长度。一旦确定了进入窗口的后退指针，copies the data就像这样：

    jsr copyByte
    jsr copyByte
inflateCodes_copyByte
    jsr copyByte
    dec inflateCodes_lengthMinus2
    bne inflateCodes_copyByte

它进行两次显式调用来复制一个字节，然后循环遍历长度减去2.这对于长度为1到255的工作方式是正常的。对于长度为0，它实际上将迭代256次。第一次通过循环时，0的长度递减到255，这是非零，因此循环继续255次，总共256次。

我不得不认为Phil Katz直观地理解了如何不明确地将匹配长度保持在8位之内的好处。