Ok, I think I've decoded (inflated? ;-)) the RFCs.
rfc1951 (Deflate) says:
Each block of compressed data begins with 3 header bits
containing the following data:
first bit BFINAL
next 2 bits BTYPE
BFINAL is set if and only if this is the last block of the data
set.
BTYPE specifies how the data are compressed, as follows:
00 - no compression
01 - compressed with fixed Huffman codes
10 - compressed with dynamic Huffman codes
11 - reserved (error)
...
rfc1950 (ZLIB) says:
A zlib stream has the following structure:
0 1
+---+---+
|CMF|FLG| (more-->)
+---+---+
(if FLG.FDICT set)
0 1 2 3
+---+---+---+---+
| DICTID | (more-->)
+---+---+---+---+
+=====================+---+---+---+---+
|...compressed data...| ADLER32 |
+=====================+---+---+---+---+
CMF (Compression Method and flags)
This byte is divided into a 4-bit compression method and a 4-
bit information field depending on the compression method.
bits 0 to 3 CM Compression method
bits 4 to 7 CINFO Compression info
CM (Compression method)
This identifies the compression method used in the file. CM = 8
denotes the "deflate" compression method with a window size up
to 32K. This is the method used by gzip and PNG (see
references [1] and [2] in Chapter 3, below, for the reference
documents). CM = 15 is reserved. It might be used in a future
version of this specification to indicate the presence of an
extra field before the compressed data.
CINFO (Compression info)
For CM = 8, CINFO is the base-2 logarithm of the LZ77 window
size, minus eight (CINFO=7 indicates a 32K window size). Values
of CINFO above 7 are not allowed in this version of the
specification. CINFO is not defined in this specification for
CM not equal to 8.
...
So, the first observation is that it really wouldn't be that heinous to
use rfc1951, if we wanted to do that -- as long as we restricted CM to
8 (deflate). I still think we were correct in specifying rfc1950,
however, so let's do some experiments...
Running a test with the Deflater/Inflater classes in JDK1.4
(java.util.zip), I get the following results:
grw$ java DeflateTest
def_wrap.length=8
78 9c 3 0 0 0 0 1
def_nowrap.length=2
3 0
In the first case, the 'nowrap' argument to the Deflater is false (so
the ZLIB header and footer are added). In the second case, the 'nowrap'
argument is true, so we just get the deflated data. Note that I was
deflating zero-length data in these tests, so all we are seeing are the
headers etc.
So, it looks to me like the JDK classes do what we need, even if the
documentation is a bit confusing (ie one could argue that the 'nowrap'
behavior should be the default).
-Greg
On Feb 7, 2005, at 3:59 PM, Scott Cantor wrote:
>> In Java, It looks like one can use Deflater with the constructor that
>> takes the 'nowrap' parameter.
>
> Maybe, but there's some worrisome language in there about dummy bytes
> and
> GZIP. The hardest part is finding something anybody can be confident
> in.
>
> zlib might have been a better choice, but it's very much a tactical
> decision
> and if Sun changed the class (a stretch I admit), then what?
>
> Got to be some kind of "official" benchmark for what's intended
> somewhere,
> clearly. zlib itself might be a reasonable starting point, but again, I
> don't know what options/functions to use to avoid the header.
>
> -- Scott
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
>
> For additional commands, e-mail:
>
