Zip question: Where are all the extra characters coming from uponunzipping?

[laredotornado]

Hi,

I'm using Java 1.5 no Mac 10.5.6. I found this code online that
should zip a file. Although it zips the file, when I manually unzip
it at the command line, there are all these extra characters (they
appear as "^@^@^@^@^@" in vi). Thus, the unzipped version of the file
is a different size than the original file. Does anyone know how to
eliminate these extra characters?

Thanks, - Dave


========================The code=============================
byte[] buf = new byte[1024];
FileInputStream fis = new FileInputStream(filename);
fis.read(buf,0,buf.length);

CRC32 crc = new CRC32();
ZipOutputStream s = new ZipOutputStream(
(OutputStream)new FileOutputStream(zipfilename));

s.setLevel(6);

ZipEntry entry = new ZipEntry(filename);
entry.setSize((long)buf.length);
crc.reset();
crc.update(buf);
entry.setCrc( crc.getValue());
s.putNextEntry(entry);
s.write(buf, 0, buf.length);
s.finish();
s.close();

 

[Lew]

I'm using Java 1.5 no Mac 10.5.6.  I found this code online that
should zip a file.  Although it zips the file, when I manually unzip
it at the command line, there are all these extra characters (they
appear as "^@^@^@^@^@" in vi).  Thus, the unzipped version of the file
is a different size than the original file.  Does anyone know how to
eliminate these extra characters?

"^@" is the representation of the NUL byte (0x00). Those are filler
characters required by the file system to make the storage for the
file an exact number of blocks long. The file system's directories
report the actual file size as being somewhat smaller than the
physical size because the logical end of file occurs somewhere in the
middle of the last block of the physical storage.

You get rid of them by not reading past the logical end of the file
when decompressing.

 

[Martin Gregorie]

You get rid of them by not reading past the logical end of the file when
decompressing.

I think the OP made a more fundamental mistake: he ignored the
possibility that he didn't fill the buffer that he wrote to the ZIP file
and is consequently writing junk to his ZIP file.

Obvious fix: Use the count of bytes read, which is returned by
FileInputStream.read() in the rest of the program instead of buf.length.

 

[markspace]

byte[] buf = new byte[1024];
FileInputStream fis = new FileInputStream(filename);
fis.read(buf,0,buf.length);

This seems like a terrible idea. What happens if the file is longer
than 1024 bytes? I think perhaps this code doesn't really do a good job
creating a zip file. Basically it's broken.

Try reading the docs of for ZipOutputStream. I'm sure you could do a
better job than the code you posted.

entry.setSize((long)buf.length);

And here, I think you have problems if the file is less than 1024 bytes.
"Broken as intended."

 

[EJP]

"^@" is the representation of the NUL byte (0x00). Those are filler
characters required by the file system to make the storage for the
file an exact number of blocks long.

If you're implying that the read() method will read those from the file
system you are mistaken. THey are put there by *Java* when the array is
initialized.

 

[Lew]

If you're implying that the read() method will read those from the file
system you are mistaken. THey are put there by *Java* when the array is
initialized.

I was corrected on this point yesterday long since.

 

[EJP]

I was corrected on this point yesterday long since.

No you weren't. You were corrected on the point that the OP ignored the
value returned by read(). That's quite a different issue.

 

[Lew]

No you weren't. You were corrected on the point that the OP ignored the
value returned by read(). That's quite a different issue.

Yes, I was.


There was no mention of ignoring the value returned by 'read()' in that
corrective paragraph. His mention of using that value was not a correction of
anything I said, but an answer that contributed to the OP.

They are put there by *Java* when the array is initialized.

That's pretty much the same point.

I stand thoroughly corrected on that point.

 

[Lew]

[...]
I stand thoroughly corrected on that point.

(I didn't quote of other parts of your conversation with "EJP" because
as I see, none of that conversation actually explicitly included what
was really important: the text from your original post).

As for the above quote...

I agree, and I hesitate to belabor the point. ...

I stand even more thoroughly corrected.