Zip Postal Codes

Zip File Format

PKZIP and Winzip use / as the directory separator character. It is up to you to convert the \ to / in element names for the ZipEntry write, and back again on read. If you don’t bother, the \ will get in the zip file, and you will have a platform-dependent zip.

Apache VFS gives you a common API for files that works both for regular files and zip file members. Normally you do your work with ZipFile, ZipEntry. ZipInputStream and ZipOutputStream or for simpler takes GZIPInputStream and GZIPOutputStream.

Writing Elements of a Zip File

Reading elements of a Zip File

Directories

Nesting

There are three approaches to the problem:

1. Put all members in the same jar/zip.
2. Use several individual jar files, and arrange to have them on the path.
3. Use a JAWS installer class to unpack a nested jar into individual jars.

• To get super-compression. You create a zip as a pure archive, turning off compression. (In Winzip you select compression:none.) Then you compress the whole thing as single file this time with compression on. The compression algorithm can then exploit repeated strings across members.
• Because you want the user to leave some jars packed for use. You bundle them up for transport as a single download.

Gotchas

• ZipOutputStream produces a slightly non-standard Zip format. ZipOutputStream puts the compressed and uncompressed size and CRC after all the members, instead of in the local header just in front of it. Unfortunately, when you come to read this file with ZipInputStream, when you do an ZipEntry.getSize() you will get 0, because ZipInputStream is a stream, and can’t look ahead to find the size. There is a second copy of the header put at the end of the file forming an index. However, ZipFile is able to use this index to randomly access the file to read individual elements. A normal zip file has the information recorded redundantly to help make it easier to read ahead and to recover a damaged zip file.
• java.util.zip has one big limitation. It only understands a few of the possible compression algorithms. It pretty well can only deal with zips created by itself. If the *.zip came from the outside world, you need to exec something like WinZip wzunzip.exe or PKWare pkunzip.exe.
• Zip format (and by extension jar format) stores file timestamps accurate only to the even second. When you archive and restore a file, it will no longer have a timestamp precisely matching the original. This is above and beyond he similar problem with Java using 1 millisecond precision and Microsoft Windows using 100 nanosecond increments. PKZIP format derives from MS DOS days and hence uses only 16 bits for time and 16 bits for date. There is defined an extended time stamp in the revised PKZIP format, but Java does not use it.

  Inside zip files, dates and times are stored in local time in 16 bits each using an old MS DOS format. Bit 0 is the least signicant bit. The format is little-endian. There was not room in 16 bit to accurately represent time even to the second, so the seconds field contains the seconds divided by two, giving accuracy only to the even second.

  To make matters worse, Standard tools like WinZip or PKZIP will always round the time up to the next even second when they restore, thereby possibly making the file one second younger. The JDK (i.e. javaToDosTime in ZipEntry rounds the time down, thereby making the file one second older.

  PKZIP/MSDOS DOSTIME 16-bit Packed Time format field hour minute seconds/2 values 0…23 0…59 0…29 width 5 bits 6 bits 5 bits position 15…11 10…5 4…0

  PKZIP/MSDOS16-bit DOSDATE Packed Date format field year month day values 1980⇒0 1…12 1…31 width 7 bits 4 bits 5 bits position 15…9 8…5 4…0

• Sun’s early jar files had no compression. Compression is optional in Sun’s zip and jar classes.

GZIP vs Zip

encryption

• AES, (Advanced Encryption Standard) 128 bit.
• AES 256-bit, slower but more secure.
• Zip 2.0, weak encryption, primarily to discourage casual snoops.

Learning More