Archive-Unzip-Burst
view release on metacpan or search on metacpan
unzip-6.0/proginfo/extrafld.txt view on Meta::CPAN
Value Size Description
----- ---- -----------
Version 2 bytes Format version number - must 0x0001 at this time
CStore (var) PKCS#7 data blob
-MVS Extra Field (PKWARE, 0x0065):
================================
The following is the layout of the MVS "extra" block.
Note: Some fields are stored in Big Endian format.
All text is in EBCDIC format unless otherwise specified.
Value Size Description
----- ---- -----------
(MVS) 0x0065 2 bytes Tag for this "extra" block type
TSize 2 bytes Size for the following data block
ID 4 bytes EBCDIC "Z390" 0xE9F3F9F0 or
"T4MV" for TargetFour
(var) TSize-4 Attribute data
-OS/400 Extra Field (0x0065):
===========================
The following is the layout of the OS/400 "extra" block.
Note: Some fields are stored in Big Endian format.
All text is in EBCDIC format unless otherwise specified.
Value Size Description
----- ---- -----------
(OS400) 0x0065 2 bytes Tag for this "extra" block type
TSize 2 bytes Size for the following data block
ID 4 bytes EBCDIC "I400" 0xC9F4F0F0 or
"T4MV" for TargetFour
(var) TSize-4 Attribute data
-Info-ZIP Unicode Path Extra Field:
=================================
Stores the UTF-8 version of the entry path as stored in the
local header and central directory header.
(Last Revision 20070912)
Value Size Description
----- ---- -----------
(UPath) 0x7075 Short tag for this extra block type ("up")
TSize Short total data size for this block
Version Byte version of this extra field, currently 1
NameCRC32 Long CRC-32 checksum of standard name field
UnicodeName variable UTF-8 version of the entry file name
Currently Version is set to the number 1. If there is a need
to change this field, the version will be incremented. Changes
may not be backward compatible so this extra field should not be
used if the version is not recognized.
The NameCRC32 is the standard zip CRC32 checksum of the File Name
field in the header. This is used to verify that the header
File Name field has not changed since the Unicode Path extra field
was created. This can happen if a utility renames the entry but
does not update the UTF-8 path extra field. If the CRC check fails,
this UTF-8 Path Extra Field should be ignored and the File Name field
in the header should be used instead.
The UnicodeName is the UTF-8 version of the contents of the File
Name field in the header, without any trailing NUL. The standard
name field in the Zip entry header remains filled with the entry
name coded in the local machine's extended ASCII system charset.
As UnicodeName is defined to be UTF-8, no UTF-8 byte order mark
(BOM) is used. The length of this field is determined by
subtracting the size of the previous fields from TSize.
If both the File Name and Comment fields are UTF-8, the new General
Purpose Bit Flag, bit 11 (Language encoding flag (EFS)), should be
used to indicate that both the header File Name and Comment fields
are UTF-8 and, in this case, the Unicode Path and Unicode Comment
extra fields are not needed and should not be created. Note that,
for backward compatibility, bit 11 should only be used if the native
character set of the paths and comments being zipped up are already
in UTF-8. The same method, either general purpose bit 11 or extra
fields, should be used in both the Local and Central Directory Header
for a file.
Utilisation rules:
1. This field shall never be created for names consisting solely of
7-bit ASCII characters.
2. On a system that already uses UTF-8 as system charset, this field
shall not repeat the string pattern already stored in the Zip
entry's standard name field. Instead, a field of exactly 9 bytes
(70 75 05 00 01 and 4 bytes CRC) should be created.
In this form with 5 data bytes, the field serves as indicator
for the UTF-8 encoding of the standard Zip header's name field.
3. This field shall not be used whenever the calculated CRC-32 of
the entry's standard name field does not match the provided
CRC checksum value. A mismatch of the CRC check indicates that
the standard name field was changed by some non-"up"-aware
utility without synchronizing this UTF-8 name e.f. block.
-Info-ZIP Unicode Comment Extra Field:
====================================
Stores the UTF-8 version of the entry comment as stored in the
central directory header.
(Last Revision 20070912)
Value Size Description
----- ---- -----------
(UCom) 0x6375 Short tag for this extra block type ("uc")
TSize Short total data size for this block
Version 1 byte version of this extra field, currently 1
ComCRC32 4 bytes Comment Field CRC32 Checksum
UnicodeCom Variable UTF-8 version of the entry comment
Currently Version is set to the number 1. If there is a need
to change this field, the version will be incremented. Changes
may not be backward compatible so this extra field should not be
used if the version is not recognized.
The ComCRC32 is the standard zip CRC32 checksum of the Comment
field in the central directory header. This is used to verify that
the comment field has not changed since the Unicode Comment extra
field was created. This can happen if a utility changes the Comment
field but does not update the UTF-8 Comment extra field. If the CRC
check fails, this Unicode Comment extra field should be ignored and
the Comment field in the header used.
The UnicodeCom field is the UTF-8 version of the entry comment field
in the header. As UnicodeCom is defined to be UTF-8, no UTF-8 byte
order mark (BOM) is used. The length of this field is determined by
subtracting the size of the previous fields from TSize. If both the
File Name and Comment fields are UTF-8, the new General Purpose Bit
Flag, bit 11 (Language encoding flag (EFS)), can be used to indicate
both the header File Name and Comment fields are UTF-8 and, in this
case, the Unicode Path and Unicode Comment extra fields are not
needed and should not be created. Note that, for backward
compatibility, bit 11 should only be used if the native character set
of the paths and comments being zipped up are already in UTF-8. The
same method, either bit 11 or extra fields, should be used in both
the local and central directory headers.
-Extended Timestamp Extra Field:
==============================
The following is the layout of the extended-timestamp extra block.
(Last Revision 19970118)
Local-header version:
Value Size Description
----- ---- -----------
(time) 0x5455 Short tag for this extra block type ("UT")
TSize Short total data size for this block
Flags Byte info bits
(ModTime) Long time of last modification (UTC/GMT)
(AcTime) Long time of last access (UTC/GMT)
(CrTime) Long time of original creation (UTC/GMT)
Central-header version:
Value Size Description
----- ---- -----------
(time) 0x5455 Short tag for this extra block type ("UT")
TSize Short total data size for this block
Flags Byte info bits (refers to local header!)
(ModTime) Long time of last modification (UTC/GMT)
The central-header extra field contains the modification time only,
or no timestamp at all. TSize is used to flag its presence or
absence. But note:
If "Flags" indicates that Modtime is present in the local header
field, it MUST be present in the central header field, too!
This correspondence is required because the modification time
value may be used to support trans-timezone freshening and
updating operations with zip archives.
The time values are in standard Unix signed-long format, indicating
the number of seconds since 1 January 1970 00:00:00. The times
are relative to Coordinated Universal Time (UTC), also sometimes
( run in 4.183 seconds using v1.01-cache-2.11-cpan-364913b4093 )