commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: [compress] Need API Feedback/Advice for ZipArchiveOutputStream ans ZIP64
Date Sat, 06 Aug 2011 13:53:43 GMT
On 2011-08-06, Torsten Curdt wrote:

>> The only case that isn't covered so far is compressed / non-seekable
>> output / input of unknown size.


> How does the input stream distinguish between entry data and stream
> data if the length is not know up front?

The DEFLATE algorithm signals when the stream is terminated so the input
streams knows when its done.  The data descriptor following the entry
data merely serves to verify the data that has just been read.

This already works for "normal ZIP", we just need to support the
different formats of data descriptors properly.

Actually ZipArchiveInputStream even supports non-compressed entries of
unknown size if you ask it to - but it is highly recommended that you
don't.  It does so by assuming that whenever it encounters anything that
looks like a "data descriptor", a "local file header" or a "central
directory entry" then it must have reached the next entry.  This is
neither reliable nor does it perform well, but it is required to support
some archives found in the wild (some Microsoft XPS documents IIRC).


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message