> Not exactly. That is what I am doing to read the 'main' zip file. But
> the zip file contains other zip files. So when I read in an entry as
> your code shows, I am still looking at a zip file. I need to be able
> to then read the entries of THAT zip file.
I did try that, and while it lets me do things like getEntry, that
still doesn't let me cleanly read in just the contents of that 1
embedded file. The methods for reading want to read an entire file
(which I don't have, since this is a piece of a larger file) or they
want an offset at which to start reading, which I don't know how to
calculate for a zip file...
Chris Uppal - 19 Nov 2005 10:46 GMT
> I did try that, and while it lets me do things like getEntry, that
> still doesn't let me cleanly read in just the contents of that 1
> embedded file.
I'm not sure if I'm understanding you correctly, but if what you want to do is
find just 1 specific entry in a "zipfile" which itself is embedded in another
zip file, then you can't do it.
Only the outermost (real) zip file can be opened as a java.util.zip.ZipFile
(and so allow random access). Embedded zip-format files can be only be treated
sequentially by using a ZipInputStream. That makes sense, if you think about
it, because it's not possible to do random access in compressed data (which the
embedded zip file is), so all you can do is iterate over it.
In theory the API could allow you to extract the bytes of the embedded zipfile
(thus decompressing them) and wrap a ZipFile object around that byte[] array,
but in fact the API does not support it.
-- chris