EVALUATION
To support ZIP64 format, items listed below need to be updated in implementation (collected from the http://www.pkware.com/documents/casestudies/APPNOTE.TXT)
(1)LOC
compressed size: (4 bytes)
uncompressed size: (4 bytes)
If an archive is in ZIP64 format
and the value in this field is 0xFFFFFFFF, the size will be
in the corresponding 8 byte ZIP64 extended information
extra field.
(2)Data descriptor:
crc-32 4 bytes
compressed size 4 bytes
uncompressed size 4 bytes
When compressing files, compressed and uncompressed sizes
should be stored in ZIP64 format (as 8 byte values) when a
files size exceeds 0xFFFFFFFF. However ZIP64 format may be
used regardless of the size of a file. When extracting, if
the zip64 extended information extra field is present for
the file the compressed and uncompressed sizes will be 8
byte values.
(3)Central directory
No explicit Zip64 notes here, specified in (6)
(4)Zip64 end of central directory record
zip64 end of central dir signature 4 bytes (0x06064b50) 0
size of zip64 end of central directory record 8 bytes 4
version made by 2 bytes 12 version needed to extract 2 bytes 14
number of this disk 4 bytes 16
number of the disk with the start of the central directory 4 bytes 20
total number of entries in the central directory on this disk 8 bytes 24
total number of entries in the central directory 8 bytes 32
size of the central directory 8 bytes 40
offset of start of centraldirectory with respect to the starting disk number 8 bytes
zip64 extensible data sector (variable size)
The value stored into the "size of zip64 end of central
directory record" should be the size of the remaining
record and should not include the leading 12 bytes.
Size = SizeOfFixedFields + SizeOfVariableData - 12.
(5)Zip64 end of central directory locator
zip64 end of central dir locator signature 4 bytes (0x07064b50)
number of the disk with the start of the zip64 end of central directory 4 bytes
relative offset of the zip64 end of central directory record 8 bytes
total number of disks 4 bytes
(6) -Zip64 Extended Information Extra Field (0x0001):
The following is the layout of the zip64 extended
information "extra" block. If one of the size or
offset fields in the Local or Central directory
record is too small to hold the required data,
a Zip64 extended information record is created.
The order of the fields in the zip64 extended
information record is fixed, but the fields will
only appear if the corresponding Local or Central
directory record field is set to 0xFFFF or 0xFFFFFFFF.
Note: all fields stored in Intel low-byte/high-byte order.
Value Size Description
----- ---- -----------
(ZIP64) 0x0001 2 bytes Tag for this "extra" block type
Size 2 bytes Size of this "extra" block
Original Size 8 bytes Original uncompressed file size
Compressed Size 8 bytes Size of compressed data
Relative Header Offset 8 bytes Offset of local header record
Disk Start Number 4 bytes Number of the disk on which this file starts
This entry in the Local header must include BOTH original
and compressed file size fields. If encrypting the
central directory and bit 13 of the general purpose bit
flag is set indicating masking, the value stored in the
Local Header for the original file size will be zero.
(7) version needed to extract (2 bytes) --->[sherman: should we change it?]
When using ZIP64 extensions, the corresponding value in the
zip64 end of central directory record should also be set. This field should be set appropriately to indicate whether
Version 1 or Version 2 format is in use.
---------------------------------------------------------------
Whether or not we have zip64 end recorder & locator is decided by
(8)-(13) below, but we actually only look at the last 4
I. End of central directory record:
end of central dir signature 4 bytes (0x06054b50)
number of this disk 2 bytes
number of the disk with the start of the central directory 2 bytes
total number of entries in the central directory on this disk 2 bytes
total number of entries in the central directory 2 bytes
size of the central directory 4 bytes
offset of start of central directory with respect to the starting disk number 4 bytes
.ZIP file comment length 2 bytes
.ZIP file comment (variable size)
----------------------------------------------------------------
(8) number of this disk: (2 bytes) --->[sherman: do nothing]
The number of this disk, which contains central
directory end record. If an archive is in ZIP64 format
and the value in this field is 0xFFFF, the size will
be in the corresponding 4 byte zip64 end of central
directory field.
(9) number of the disk with the start of the central
directory: (2 bytes) --->[sherman: do nothing]
The number of the disk on which the central
directory starts. If an archive is in ZIP64 format
and the value in this field is 0xFFFF, the size will
be in the corresponding 4 byte zip64 end of central
directory field.
(10) total number of entries in the central dir on
this disk: (2 bytes)
The number of central directory entries on this disk.
If an archive is in ZIP64 format and the value in
this field is 0xFFFF, the size will be in the
corresponding 8 byte zip64 end of central
directory field.
(11) total number of entries in the central dir: (2 bytes)
The total number of files in the .ZIP file. If an
archive is in ZIP64 format and the value in this field
is 0xFFFF, the size will be in the corresponding 8 byte
zip64 end of central directory field.
(12) size of the central directory: (4 bytes)
The size (in bytes) of the entire central directory.
If an archive is in ZIP64 format and the value in
this field is 0xFFFFFFFF, the size will be in the
corresponding 8 byte zip64 end of central
directory field.
(13) offset of start of central directory with respect to
the starting disk number: (4 bytes)
Offset of the start of the central directory on the
disk on which the central directory starts. If an
archive is in ZIP64 format and the value in this
field is 0xFFFFFFFF, the size will be in the
corresponding 8 byte zip64 end of central
directory field.
|
Java