| |
 |
|
|
Science Forum Index » Compression Forum » Query in Gzip file format.
Page 1 of 1
|
| Author |
Message |
| Guest |
 Posted: Thu Mar 06, 2008 9:04 pm |
|
|
|
|
Dear,
I gone through Rfc 1952(Gzip file format).I have one question, After
decompressing one member in Gzip file wheather next member will start
at next byte boundary or from next bit onwards. |
|
|
| Back to top |
|
| Thomas Pornin |
| Posted: Fri Mar 07, 2008 8:59 am |
|
|
|
Guest
|
According to <lokaresa@gmail.com>:
Quote: I gone through Rfc 1952(Gzip file format).I have one question, After
decompressing one member in Gzip file wheather next member will start
at next byte boundary or from next bit onwards.
At next byte boundary. The Gzip format is byte oriented. The "compressed
blocks" customarily use the Deflate compression algorithm (RFC 1951)
which may not fill completely the last byte, which is then padded with
bits equal to 0.
--Thomas Pornin |
|
|
| Back to top |
|
| Guest |
| Posted: Sun Mar 09, 2008 7:47 pm |
|
|
|
|
On Mar 7, 5:59 pm, Thomas Pornin <por...@bolet.org> wrote:
Quote: According to <lokar...@gmail.com>:
I gone through Rfc 1952(Gzip file format).I have one question, After
decompressing one member in Gzip file wheather next member will start
at next byte boundary or from next bit onwards.
At next byte boundary. The Gzip format is byte oriented. The "compressed
blocks" customarily use the Deflate compression algorithm (RFC 1951)
which may not fill completely the last byte, which is then padded with
bits equal to 0.
--Thomas Pornin
Thanks...
Did you mean that, after complition of final block in one member,
proceeding 32 bits are CRC32 value and next 32 bits are ISIZE
value?.If one member ends at middle of one byte, next member starts at
next byte boundary?. |
|
|
| Back to top |
|
| Thomas Pornin |
| Posted: Mon Mar 10, 2008 3:11 pm |
|
|
|
Guest
|
According to <lokaresa@gmail.com>:
Quote: Did you mean that, after complition of final block in one member,
proceeding 32 bits are CRC32 value and next 32 bits are ISIZE
value?
No. When the last Deflate block does not end on a byte boundary, it
is padded with some bits equal to zero. Then only comes the CRC32,
which is byte-aligned.
Nominally, the Gzip file format is compression-agnostic: it is a format
for storing compressed data within members with member boundaries and
CRC. It so happens that Gzip is almost always used with Deflate
compression, hence the "compressed data" in a Gzip member is a sequence
of Deflate blocks. From the point of view of the Gzip member, the
compressed data is just a bunch of _bytes_, and as such as a length
which is an integral number of bytes. Since Deflate blocks may end in
the middle of a byte, it is customary to add a few bits (i.e. not to
worry about the remaining bits) so that the Gzip member sees a sequence
of well-formed bytes.
--Thomas Pornin |
|
|
| Back to top |
|
| |
|
Page 1 of 1
All times are GMT - 5 Hours
The time now is Thu Dec 04, 2008 2:56 am
|
|