#Betterzip huffman code code

In short, it is possible to construct an entirely valid dynamic block header that is 2286 bits in length.

#Betterzip huffman code code

The code lengths code must also be complete, but that can be achieved by assigning shorter codes to unused lengths.

It is possible to construct the code lengths code to, for example, have the lengths 4, 5, 8, and 9 all be 7-bit codes, and then use only those in the list of lengths to construct complete literal/length and distance codes. I limited the literal/length code lengths to 286 and the distance code lengths to 30, since a compliant inflator will reject values above that.Ģ286 is the lowest possible upper bound, since there is no constraint in the deflate format that the header be constructed to be optimal. There are still 19 initial code lengths even if 16, 17, and 18 are not used, since those are stored first. A 16 symbol would replace 21 to 42 bits with 9 bits, a 17 symbol would replace 21 to 70 bits with 10 bits, and an 18 symbol would replace 77 to 966 bits with 14 bits (where all symbols are assumed to be seven bits). I deliberately did not add possible extra bits for symbols 16, 17, or 18, because the use of any of those codes, including their extra bits, would reduce the length of the header, not increase it. Executables code all literal byte values, resulting in larger dynamic headers to describe codes for all of those values. The bimodal shape is probably executables vs. Here is another for (an application distribution):

Here is a histogram of dynamic header block lengths from a gzipped source distribution of linux, linux-3.1.6.tar.gz: In practice you will never see one near as long as 286 bytes. (See calculation notes below for details.) An upper bound on the length of a dynamic block header can be readily computed from the reference you already provided.