Revert "Update zstd version_needed to 20 and update appnote.txt"
This reverts commit af5b5e57ef0eef59c9333fa4826fce4cdbbcbfef.
diff --git a/THANKS b/THANKS
index 5f37ea9..7a16c62 100644
--- a/THANKS
+++ b/THANKS
@@ -32,7 +32,6 @@
Erwin Haid <erwin.haid@gmx.de>
Eun-cheol Joo
Florian Delizy <florian.delizy@gmail.com>
-Force Charlie <charlieio@outlookc.com>
François Simon <AT.GFI.Francois.SIMON@sesam-vitale.fr>
Frederik Ramm <frederik@remote.org>
gk7huki <gk7huki@gmail.com>
diff --git a/docs/appnote.txt b/docs/appnote.txt
index 64b1b3a..985f6f8 100644
--- a/docs/appnote.txt
+++ b/docs/appnote.txt
@@ -1,8 +1,8 @@
File: APPNOTE.TXT - .ZIP File Format Specification
-Version: 6.3.8
-Status: FINAL - replaces version 6.3.7
-Revised: June 15, 2020
-Copyright (c) 1989 - 2014, 2018, 2019, 2020 PKWARE Inc., All Rights Reserved.
+Version: 6.3.4
+Status: Final - replaces version 6.3.3
+Revised: October 1, 2014
+Copyright (c) 1989 - 2014 PKWARE Inc., All Rights Reserved.
1.0 Introduction
---------------
@@ -33,10 +33,10 @@
1.3 Trademarks
--------------
- 1.3.1 PKWARE, PKZIP, Smartcrypt, SecureZIP, and PKSFX are registered
- trademarks of PKWARE, Inc. in the United States and elsewhere.
- PKPatchMaker, Deflate64, and ZIP64 are trademarks of PKWARE, Inc.
- Other marks referenced within this document appear for identification
+ 1.3.1 PKWARE, PKZIP, SecureZIP, and PKSFX are registered trademarks of
+ PKWARE, Inc. in the United States and elsewhere. PKPatchMaker,
+ Deflate64, and ZIP64 are trademarks of PKWARE, Inc. Other marks
+ referenced within this document appear for identification
purposes only and are the property of their respective owners.
@@ -74,8 +74,8 @@
+1-414-289-9789 FAX
zipformat@pkware.com
- 1.5.2 Information about this format and a reference copy of this document
- is publicly available at:
+ 1.5.2 Information about this format and copies of this document are publicly
+ available at:
http://www.pkware.com/appnote
@@ -116,7 +116,7 @@
considered to be in the final form for that version of the document
and are not subject to further change until a new, higher version
numbered document is published. Newer versions of this format
- specification are intended to remain interoperable with all prior
+ specification are intended to remain interoperable with with all prior
versions whenever technically possible.
2.2 Change Log
@@ -124,7 +124,7 @@
Version Change Description Date
------- ------------------ ----------
- 5.2 -Single Password Symmetric Encryption 07/16/2003
+ 5.2 -Single Password Symmetric Encryption 06/02/2003
storage
6.1.0 -Smartcard compatibility 01/20/2004
@@ -177,51 +177,9 @@
6.3.3 -Formatting changes to support 09/01/2012
easier referencing of this APPNOTE
- from other documents and standards
+ from other documents and standards
6.3.4 -Address change 10/01/2014
-
- 6.3.5 -Documented compression methods 16 11/31/2018
- and 99 (4.4.5, 4.6.1, 5.11, 5.17,
- APPENDIX E)
-
- -Corrected several typographical
- errors (2.1.2, 3.2, 4.1.1, 10.2)
-
- -Marked legacy algorithms as no
- longer suitable for use (4.4.5.1)
-
- -Added clarity on MS DOS time format
- (4.4.6)
-
- -Assign extrafield ID for Timestamps
- (4.5.2)
-
- -Field code description correction (A.2)
-
- -More consistent use of MAY/SHOULD/MUST
-
- -Expanded 0x0065 record attribute codes (B.2)
-
- -Initial information on 0x0022 Extra Data
-
- 6.3.6 -Corrected typographical error 04/26/2019
- (4.4.1.3)
-
- 6.3.7 -Added Zstandard compression method ID
- (4.4.5)
-
- -Corrected several reported typos
-
- -Marked intended use for general purpose bit 14
-
- -Added Data Stream Alignment Extra Data info
- (4.6.11)
-
- 6.3.8 -Resolved Zstandard compression method ID conflict
- (4.4.5)
-
- -Added additional compression method ID values in use
3.0 Notations
@@ -229,7 +187,7 @@
3.1 Use of the term MUST or SHALL indicates a required element.
- 3.2 MUST NOT or SHALL NOT indicates an element is prohibited from use.
+ 3.2 MAY NOT or SHALL NOT indicates an element is prohibited from use.
3.3 SHOULD indicates a RECOMMENDED element.
@@ -248,7 +206,7 @@
although use of a file extension is not required. Use of the
extension .ZIPX is also recognized and MAY be used for ZIP files.
Other common file extensions using the ZIP format include .JAR, .WAR,
- .DOCX, .XLSX, .PPTX, .ODT, .ODS, .ODP and others. Programs reading or
+ .DOCX, .XLXS, .PPTX, .ODT, .ODS, .ODP and others. Programs reading or
writing ZIP files SHOULD rely on internal record signatures described
in this document to identify files in this format.
@@ -325,12 +283,12 @@
4.3.1 A ZIP file MUST contain an "end of central directory record". A ZIP
file containing only an "end of central directory record" is considered an
- empty ZIP file. Files MAY be added or replaced within a ZIP file, or deleted.
+ empty ZIP file. Files may be added or replaced within a ZIP file, or deleted.
A ZIP file MUST have only one "end of central directory record". Other
records defined in this specification MAY be used as needed to support
storage requirements for individual ZIP files.
- 4.3.2 Each file placed into a ZIP file MUST be preceded by a "local
+ 4.3.2 Each file placed into a ZIP file MUST be preceeded by a "local
file header" record for that file. Each "local file header" MUST be
accompanied by a corresponding "central directory header" record within
the central directory section of the ZIP file.
@@ -342,7 +300,7 @@
4.3.4 Compression MUST NOT be applied to a "local file header", an "encryption
header", or an "end of central directory record". Individual "central
- directory records" MUST NOT be compressed, but the aggregate of all central
+ directory records" must not be compressed, but the aggregate of all central
directory records MAY be compressed.
4.3.5 File data MAY be followed by a "data descriptor" for the file. Data
@@ -402,7 +360,7 @@
.ZIP archive.
Zero-byte files, directories, and other file types that
- contain no content MUST NOT include file data.
+ contain no content MUST not include file data.
4.3.9 Data descriptor:
@@ -419,8 +377,8 @@
archives, the compressed and uncompressed sizes are 8 bytes each.
4.3.9.2 When compressing files, compressed and uncompressed sizes
- SHOULD be stored in ZIP64 format (as 8 byte values) when a
- file's size exceeds 0xFFFFFFFF. However ZIP64 format MAY be
+ should be stored in ZIP64 format (as 8 byte values) when a
+ file's 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
@@ -428,8 +386,8 @@
4.3.9.3 Although not originally assigned a signature, the value
0x08074b50 has commonly been adopted as a signature value
- for the data descriptor record. Implementers SHOULD be
- aware that ZIP files MAY be encountered with or without this
+ for the data descriptor record. Implementers should be
+ aware that ZIP files may be encountered with or without this
signature marking data descriptors and SHOULD account for
either case when reading ZIP files to ensure compatibility.
@@ -569,8 +527,8 @@
zip64 extensible data sector (variable size)
4.3.14.1 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.
+ directory record" should be the size of the remaining
+ record and should not include the leading 12 bytes.
Size = SizeOfFixedFields + SizeOfVariableData - 12.
@@ -591,7 +549,7 @@
4.3.14.3 Special purpose data MAY reside in the zip64 extensible
data sector field following either a V1 or V2 version of this
record. To ensure identification of this special purpose data
- it MUST include an identifying header block consisting of the
+ it must include an identifying header block consisting of the
following:
Header ID - 2 bytes
@@ -647,13 +605,13 @@
4.4.1.2 String fields are not null terminated, since the length
is given explicitly.
- 4.4.1.3 The entries in the central directory MAY NOT necessarily
+ 4.4.1.3 The entries in the central directory may not necessarily
be in the same order that files appear in the .ZIP file.
4.4.1.4 If one of the fields in the end of central directory
- record is too small to hold required data, the field SHOULD be
+ record is too small to hold required data, the field should be
set to -1 (0xFFFF or 0xFFFFFFFF) and the ZIP64 format record
- SHOULD be created.
+ should be created.
4.4.1.5 The end of central directory record and the Zip64 end
of central directory locator record MUST reside on the same
@@ -732,7 +690,7 @@
* Early 7.x (pre-7.2) versions of PKZIP incorrectly set the
version needed to extract for BZIP2 compression to be 50
- when it SHOULD have been 46.
+ when it should have been 46.
** Refer to the section on Strong Encryption Specification
for additional information regarding RC2 corrections.
@@ -745,12 +703,12 @@
+ Files compressed using PPMd MUST set the version
needed to extract field to 6.3, however, not all ZIP
- programs enforce this and MAY be unable to decompress
+ programs enforce this and may be unable to decompress
data files compressed using PPMd if this value is set.
When using ZIP64 extensions, the corresponding value in the
zip64 end of central directory record MUST also be set.
- This field SHOULD be set appropriately to indicate whether
+ This field should be set appropriately to indicate whether
Version 1 or Version 2 format is in use.
@@ -837,7 +795,7 @@
PKWARE Proprietary Technology into Your Product" for
more information.
- Bit 14: Reserved by PKWARE for alternate streams.
+ Bit 14: Reserved by PKWARE.
Bit 15: Reserved by PKWARE.
@@ -857,23 +815,15 @@
11 - Reserved by PKWARE
12 - File is compressed using BZIP2 algorithm
13 - Reserved by PKWARE
- 14 - LZMA
+ 14 - LZMA (EFS)
15 - Reserved by PKWARE
- 16 - IBM z/OS CMPSC Compression
+ 16 - Reserved by PKWARE
17 - Reserved by PKWARE
18 - File is compressed using IBM TERSE (new)
- 19 - IBM LZ77 z Architecture
- 20 - deprecated (use method 93 for zstd)
- 93 - Zstandard (zstd) Compression
- 94 - MP3 Compression
- 95 - XZ Compression
- 96 - JPEG variant
+ 19 - IBM LZ77 z Architecture (PFS)
97 - WavPack compressed data
98 - PPMd version I, Rev 1
- 99 - AE-x encryption marker (see APPENDIX E)
- 4.4.5.1 Methods 1-6 are legacy algorithms and are no longer
- recommended for use when compressing files.
4.4.6 date and time fields: (2 bytes each)
@@ -882,10 +832,7 @@
those at which compression was started for this data.
If encrypting the central directory and general purpose bit
flag 13 is set indicating masking, the value stored in the
- Local Header will be zero. MS-DOS time format is different
- from more commonly used computer time formats such as
- UTC. For example, MS-DOS uses year values relative to 1980
- and 2 second precision.
+ Local Header will be zero.
4.4.7 CRC-32: (4 bytes)
@@ -930,7 +877,7 @@
The length of the file name, extra field, and comment
fields respectively. The combined length of any
- directory record and these three fields SHOULD NOT
+ directory record and these three fields should not
generally exceed 65,535 bytes. If input came from standard
input, the file name length is set to zero.
@@ -971,7 +918,7 @@
4.4.16 relative offset of local header: (4 bytes)
This is the offset from the start of the first disk on
- which this file appears, to where the local header SHOULD
+ which this file appears, to where the local header should
be found. 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.
@@ -979,7 +926,7 @@
4.4.17 file name: (Variable)
4.4.17.1 The name of the file, with optional relative path.
- The path stored MUST NOT contain a drive or
+ The path stored MUST not contain a drive or
device letter, or a leading slash. All slashes
MUST be forward slashes '/' as opposed to
backwards slashes '\' for compatibility with Amiga
@@ -1062,7 +1009,7 @@
The comment for this .ZIP file. ZIP file comment data
is stored unsecured. No encryption or data authentication
is applied to this area at this time. Confidential information
- SHOULD NOT be stored in this section.
+ should not be stored in this section.
4.4.27 zip64 extensible data sector (variable size)
@@ -1091,7 +1038,7 @@
header1+data1 + header2+data2 . . .
- Each header MUST consist of:
+ Each header should consist of:
Header ID - 2 bytes
Data Size - 2 bytes
@@ -1124,10 +1071,6 @@
0x0017 Strong Encryption Header
0x0018 Record Management Controls
0x0019 PKCS#7 Encryption Recipient Certificate List
- 0x0020 Reserved for Timestamp record
- 0x0021 Policy Decryption Key Record
- 0x0022 Smartcrypt Key Provider Record
- 0x0023 Smartcrypt Policy Key Data Record
0x0065 IBM S/390 (Z390), AS/400 (I400) attributes
- uncompressed
0x0066 Reserved for IBM S/390 (Z390), AS/400 (I400)
@@ -1257,9 +1200,9 @@
4.5.6.2. No word alignment or padding is performed.
- 4.5.6.3. A well-behaved PKZIP/OpenVMS program SHOULD NOT produce
- more than one sub-block with the same TagX value. Also, there MUST
- NOT be more than one "extra" block of type 0x000c in a particular
+ 4.5.6.3. A well-behaved PKZIP/OpenVMS program should never produce
+ more than one sub-block with the same TagX value. Also, there will
+ never be more than one "extra" block of type 0x000c in a particular
directory record.
4.5.7 -UNIX Extra Field (0x000d):
@@ -1355,7 +1298,7 @@
4.5.9 -PKCS#7 Store for X.509 Certificates (0x0014):
This field MUST contain information about each of the certificates
- files MAY be signed with. When the Central Directory Encryption
+ files may be signed with. When the Central Directory Encryption
feature is enabled for a ZIP file, this record will appear in
the Archive Extra Data Record, otherwise it will appear in the
first central directory record and will be ignored in any
@@ -1444,7 +1387,7 @@
This field MAY contain information about each of the certificates
used in encryption processing and it can be used to identify who is
- allowed to decrypt encrypted files. This field SHOULD only appear
+ allowed to decrypt encrypted files. This field should only appear
in the archive extra data record. This field is not required and
serves only to aid archive modifications by preserving public
encryption key data. Individual security requirements may dictate
@@ -1462,7 +1405,7 @@
Value Size Description
----- ---- -----------
- Version 2 bytes Format version number - MUST be 0x0001 at this time
+ Version 2 bytes Format version number - must 0x0001 at this time
CStore (var) PKCS#7 data blob
See the section describing the Strong Encryption Specification
@@ -1475,7 +1418,8 @@
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
+
+ Value Size Description
----- ---- -----------
(MVS) 0x0065 2 bytes Tag for this "extra" block type
TSize 2 bytes Size for the following data block
@@ -1498,57 +1442,6 @@
"T4MV" for TargetFour
(var) TSize-4 Attribute data (see APPENDIX A)
- 4.5.17 -Policy Decryption Key Record Extra Field (0x0021):
-
- The following is the layout of the Policy Decryption Key "extra" block.
- TData is a variable length, variable content field. It holds
- information about encryptions and/or encryption key sources.
- Contact PKWARE for information on current TData structures.
- Information in this "extra" block may aternatively be placed
- within comment fields. Refer to the section in this document
- entitled "Incorporating PKWARE Proprietary Technology into Your
- Product" for more information.
-
- Value Size Description
- ----- ---- -----------
- 0x0021 2 bytes Tag for this "extra" block type
- TSize 2 bytes Size for the following data block
- TData TSize Data about the key
-
- 4.5.18 -Key Provider Record Extra Field (0x0022):
-
- The following is the layout of the Key Provider "extra" block.
- TData is a variable length, variable content field. It holds
- information about encryptions and/or encryption key sources.
- Contact PKWARE for information on current TData structures.
- Information in this "extra" block may aternatively be placed
- within comment fields. Refer to the section in this document
- entitled "Incorporating PKWARE Proprietary Technology into Your
- Product" for more information.
-
- Value Size Description
- ----- ---- -----------
- 0x0022 2 bytes Tag for this "extra" block type
- TSize 2 bytes Size for the following data block
- TData TSize Data about the key
-
- 4.5.19 -Policy Key Data Record Record Extra Field (0x0023):
-
- The following is the layout of the Policy Key Data "extra" block.
- TData is a variable length, variable content field. It holds
- information about encryptions and/or encryption key sources.
- Contact PKWARE for information on current TData structures.
- Information in this "extra" block may aternatively be placed
- within comment fields. Refer to the section in this document
- entitled "Incorporating PKWARE Proprietary Technology into Your
- Product" for more information.
-
- Value Size Description
- ----- ---- -----------
- 0x0023 2 bytes Tag for this "extra" block type
- TSize 2 bytes Size for the following data block
- TData TSize Data about the key
-
4.6 Third Party Mappings
------------------------
@@ -1576,12 +1469,8 @@
0x7075 Info-ZIP Unicode Path Extra Field
0x756e ASi UNIX
0x7855 Info-ZIP UNIX (new)
- 0xa11e Data Stream Alignment (Apache Commons-Compress)
0xa220 Microsoft Open Packaging Growth Hint
0xfd4a SMS/QDOS
- 0x9901 AE-x encryption structure (see APPENDIX E)
- 0x9902 unknown
-
Detailed descriptions of Extra Fields defined by third
party mappings will be documented as information on
@@ -1589,7 +1478,7 @@
PKWARE does not guarantee the accuracy of any published
third party data.
- 4.6.2 Third-party Extra Fields MUST include a Header ID using
+ 4.6.2 Third-party Extra Fields must include a Header ID using
the format defined in the section of this document
titled Extensible Data Fields (section 4.5).
@@ -1600,9 +1489,9 @@
Note: As stated above, the size of the entire .ZIP file
header, including the file name, comment, and extra
- field SHOULD NOT exceed 64K in size.
+ field should not exceed 64K in size.
- 4.6.3 In case two different programs appropriate the same
+ 4.6.3 In case two different programs should appropriate the same
Header ID value, it is strongly recommended that each
program SHOULD place a unique signature of at least two bytes in
size (and preferably 4 bytes or bigger) at the start of
@@ -1617,8 +1506,8 @@
The following is the layout of the ZipIt extra block
for Macintosh. The local-header and central-header versions
- are identical. This block MUST be present if the file is
- stored MacBinary-encoded and it SHOULD NOT be used if the file
+ are identical. This block must be present if the file is
+ stored MacBinary-encoded and it should not be used if the file
is not stored MacBinary-encoded.
Value Size Description
@@ -1648,8 +1537,8 @@
FileType Byte[4] four-byte Mac file type string
Creator Byte[4] four-byte Mac creator string
fdFlags beShort attributes from FInfo.frFlags,
- MAY be omitted
- 0x0000 beShort reserved, MAY be omitted
+ may be omitted
+ 0x0000 beShort reserved, may be omitted
4.6.6 -ZipIt Macintosh Extra Field (short, for directories) (0x2805):
@@ -1665,9 +1554,9 @@
(Mac2c) 0x2805 Short tag for this extra block type
TSize Short total data size for this block (12)
"ZPIT" beLong extra-field signature
- frFlags beShort attributes from DInfo.frFlags, MAY
+ frFlags beShort attributes from DInfo.frFlags, may
be omitted
- View beShort ZipIt view flag, MAY be omitted
+ View beShort ZipIt view flag, may be omitted
The View field specifies ZipIt-internal settings as follows:
@@ -1727,7 +1616,7 @@
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
+ 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 File Comment
@@ -1735,8 +1624,8 @@
the comment field has not changed since the Unicode Comment extra field
was created. This can happen if a utility changes the File 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 File Comment field in the header SHOULD be used instead.
+ check fails, this Unicode Comment extra field should be ignored and
+ the File Comment field in the header should be used instead.
The UnicodeCom field is the UTF-8 version of the File Comment field
in the header. As UnicodeCom is defined to be UTF-8, no UTF-8 byte
@@ -1746,8 +1635,8 @@
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
+ 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. It is
expected that the same file comment storage method, either general
purpose bit 11 or extra fields, be used in both the Local and Central
@@ -1769,7 +1658,7 @@
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
+ 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
@@ -1777,8 +1666,8 @@
File Name field has not changed since the Unicode Path extra field
was created. This can happen if a utility renames the File Name 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.
+ 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. As UnicodeName is defined to be UTF-8, no UTF-8
@@ -1788,8 +1677,8 @@
Bit Flag, bit 11 (Language encoding flag (EFS)), can 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
+ 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. It is
expected that the same file name storage method, either general
purpose bit 11 or extra fields, be used in both the Local and Central
@@ -1806,41 +1695,15 @@
PadVal Short Initial padding value
Padding variable filled with NULL characters
- 4.6.11 -Data Stream Alignment (Apache Commons-Compress) (0xa11e):
-
- (per Zbynek Vyskovsky) Defines alignment of data stream of this
- entry within the zip archive. Additionally, indicates whether the
- compression method should be kept when re-compressing the zip file.
-
- The purpose of this extra field is to align specific resources to
- word or page boundaries so they can be easily mapped into memory.
-
- Value Size Description
- ----- ---- -----------
- 0xa11e Short tag for this extra block type
- TSize Short total data size for this block (2+padding)
- alignment Short required alignment and indicator
- 0x00 Variable padding
-
- The alignment field (lower 15 bits) defines the minimal alignment
- required by the data stream. Bit 15 of alignment field indicates
- whether the compression method of this entry can be changed when
- recompressing the zip file. The value 0 means the compression method
- should not be chnged. The value 1 indicates the compression method
- may be changed. The padding field contains padding to ensure the correct
- alignment. It can be changed at any time when the offset or required
- alignment changes. (see https://issues.apache.org/jira/browse/COMPRESS-391)
-
-
4.7 Manifest Files
------------------
- 4.7.1 Applications using ZIP files MAY have a need for additional
- information that MUST be included with the files placed into
+ 4.7.1 Applications using ZIP files may have a need for additional
+ information that must be included with the files placed into
a ZIP file. Application specific information that cannot be
stored using the defined ZIP storage records SHOULD be stored
using the extensible Extra Field convention defined in this
- document. However, some applications MAY use a manifest
+ document. However, some applications may use a manifest
file as a means for storing additional information. One
example is the META-INF/MANIFEST.MF file used in ZIP formatted
files having the .JAR extension (JAR files).
@@ -1850,9 +1713,9 @@
file type required by the defining application process. It is
placed within the same ZIP file as files to which this information
applies. By convention, this file is typically the first file placed
- into the ZIP file and it MAY include a defined directory path.
+ into the ZIP file and it may include a defined directory path.
- 4.7.3 Manifest files MAY be compressed or encrypted as needed for
+ 4.7.3 Manifest files may be compressed or encrypted as needed for
application processing of the files inside the ZIP files.
Manifest files are outside of the scope of this specification.
@@ -1874,18 +1737,18 @@
not automatically increased when codes larger than the current
code size are created (but not necessarily used). When
the decompressor encounters the code sequence 256
- (decimal) followed by 1, it SHOULD increase the code size
+ (decimal) followed by 1, it should increase the code size
read from the input stream to the next bit size. No
blocking of the codes is performed, so the next code at
- the increased size SHOULD be read from the input stream
+ the increased size should be read from the input stream
immediately after where the previous code at the smaller
- bit size was read. Again, the decompressor SHOULD NOT
+ bit size was read. Again, the decompressor should not
increase the code size used until the sequence 256,1 is
encountered.
5.1.3 When the table becomes full, total clearing is not
performed. Rather, when the compressor emits the code
- sequence 256,2 (decimal), the decompressor SHOULD clear
+ sequence 256,2 (decimal), the decompressor should clear
all leaf nodes from the Ziv-Lempel tree, and continue to
use the current code size. The nodes that are cleared
from the Ziv-Lempel tree are then re-used, with the lowest
@@ -2226,9 +2089,9 @@
16, 17, 18, 0, 8, 7, 9, 6, 10, 5, 11, 4, 12, 3, 13, 2, 14, 1, 15
- The Huffman codes SHOULD be built as described in the Implode algorithm
+ The Huffman codes should be built as described in the Implode algorithm
except codes are assigned starting at the shortest bit length, i.e. the
- shortest code SHOULD be all 0's rather than all 1's. Also, codes with
+ shortest code should be all 0's rather than all 1's. Also, codes with
a bit length of zero do not participate in the tree construction. The
codes are then used to decode the bit lengths for the literal and
distance tables.
@@ -2336,7 +2199,7 @@
Central Header records will be set to 6.3 to indicate the minimum
ZIP format version supporting this feature.
- 5.8.4 File data compressed using the LZMA algorithm MUST be placed
+ 5.8.4 File data compressed using the LZMA algorithm must be placed
immediately following the Local Header for the file. If a standard
ZIP encryption header is required, it will follow the Local Header
and will precede the LZMA compressed file data segment. The location
@@ -2348,7 +2211,7 @@
[data descriptor 1]
[local header file 2]
- 5.8.5 The encryption header and data descriptor records MAY
+ 5.8.5 The encryption header and data descriptor records may
be conditionally present. The LZMA Compressed Data Segment
will consist of an LZMA Properties Header followed by the
LZMA Compressed Data as shown:
@@ -2358,7 +2221,7 @@
5.8.6 The LZMA Compressed Data will be stored as provided by the
LZMA compression library. Compressed size, uncompressed size and
- other file characteristics about the file being compressed MUST be
+ other file characteristics about the file being compressed must be
stored in standard ZIP storage format.
5.8.7 The LZMA Properties Header will store specific data required
@@ -2379,19 +2242,19 @@
byte will store the minor number.
5.8.8.2 LZMA Properties Size - this field defines the size of the
- remaining property data. Typically this size SHOULD be determined by
+ remaining property data. Typically this size should be determined by
the version of the SDK. This size field is included as a convenience
- and to help avoid any ambiguity arising in the future due
+ and to help avoid any ambiguity should it arise in the future due
to changes in this compression algorithm.
5.8.8.3 LZMA Property Data - this variable sized field records the
required values for the decompressor as defined by the LZMA SDK.
- The data stored in this field SHOULD be obtained using the
+ The data stored in this field should be obtained using the
WriteCoderProperties() in the version of the SDK defined by
the "LZMA Version Information" field.
5.8.8.4 The layout of the "LZMA Properties Data" field is a function of
- the LZMA compression algorithm. It is possible that this layout MAY be
+ the LZMA compression algorithm. It is possible that this layout may be
changed by the author over time. The data layout in version 4.3 of the
LZMA SDK defines a 5 byte array that uses 4 bytes to store the dictionary
size in little-endian order. This is preceded by a single packed byte as
@@ -2404,11 +2267,11 @@
Refer to the LZMA documentation for a more detailed explanation of
these fields.
- 5.8.9 Data compressed with method 14, LZMA, MAY include an end-of-stream
+ 5.8.9 Data compressed with method 14, LZMA, may include an end-of-stream
(EOS) marker ending the compressed data stream. This marker is not
required, but its use is highly recommended to facilitate processing
- and implementers SHOULD include the EOS marker whenever possible.
- When the EOS marker is used, general purpose bit 1 MUSY be set. If
+ and implementers should include the EOS marker whenever possible.
+ When the EOS marker is used, general purpose bit 1 must be set. If
general purpose bit 1 is not set, the EOS marker is not present.
5.9 WavPack - Method 97
@@ -2431,13 +2294,13 @@
5.9.3 An implementation note for storing digital sample data when using
WavPack compression within ZIP files is that all of the bytes of
- the sample data SHOULD be compressed. This includes any unused
+ the sample data should be compressed. This includes any unused
bits up to the byte boundary. An example is a 2 byte sample that
uses only 12 bits for the sample data with 4 unused bits. If only
12 bits are passed as the sample size to the WavPack routines, the 4
unused bits will be set to 0 on extraction regardless of their original
state. To avoid this, the full 16 bits of the sample data size
- SHOULD be provided.
+ should be provided.
5.10 PPMd - Method 98
---------------------
@@ -2479,87 +2342,6 @@
(Model restoration method << 12)
-5.11 AE-x Encryption marker - Method 99
--------------------------------------------
-
-5.12 JPEG variant - Method 96
--------------------------------------------
-
-5.13 PKWARE Data Compression Library Imploding - Method 10
------------------------------------------------------------
-
-5.14 Reserved - Method 11
--------------------------------------------
-
-5.15 Reserved - Method 13
--------------------------------------------
-
-5.16 Reserved - Method 15
--------------------------------------------
-
-5.17 IBM z/OS CMPSC Compression - Method 16
--------------------------------------------
-
-Method 16 utilizes the IBM hardware compression facility available
-on most IBM mainframes. Hardware compression can significantly
-increase the speed of data compression. This method uses a variant
-of the LZ78 algorithm. CMPSC hardware compression is performed
-using the COMPRESSION CALL instruction.
-
-ZIP archives can be created using this method only on mainframes
-supporting the CP instruction. Extraction MAY occur on any
-platform supporting this compression algorithm. Use of this
-algorithm requires creation of a compression dictionary and
-an expansion dictionary. The expansion dictionary MUST be
-placed into the ZIP archive for use on the system where
-extraction will occur.
-
-Additional information on this compression algorithm and dictionaries
-can be found in the IBM provided document titled IBM ESA/390 Data
-Compression (SA22-7208-01). Storage requirements for using CMPSC
-compression are as follows.
-
-The format for the compressed data stream placed into the ZIP
-archive following the Local Header is:
-
- [dictionary header]
- [expansion dictionary]
- [CMPSC compressed data]
-
-If encryption is used to encrypt a file compressed with CMPSC, these
-sections MUST be encrypted as a single entity.
-
-The format of the dictionary header is:
-
- Value Size Description
- ----- ---- -----------
- Version 1 byte 1
- Flags/Symsize 1 byte Processing flags and
- symbol size
- DictionaryLen 4 bytes Length of the
- expansion dictionary
-
-Explanation of processing flags and symbol size:
-
-The high 4 bits are used to store the processing flags. The low
-4 bits represent the size of a symbol, in bits (values range
-from 9-13). Flag values are defined below.
-
- 0x80 - expansion dictionary
- 0x40 - expansion dictionary is compressed using Deflate
- 0x20 - Reserved
- 0x10 - Reserved
-
-
-5.18 Reserved - Method 17
--------------------------------------------
-
-5.19 IBM TERSE - Method 18
--------------------------------------------
-
-5.20 IBM LZ77 z Architecture - Method 19
------------------------------------------
-
6.0 Traditional PKWARE Encryption
----------------------------------
@@ -2578,7 +2360,7 @@
encryption.
6.1.2 PKZIP encrypts the compressed data stream. Encrypted files
- MUST be decrypted before they can be extracted to their original
+ must be decrypted before they can be extracted to their original
form.
6.1.3 Each encrypted file has an extra 12 bytes stored at the start
@@ -2645,7 +2427,7 @@
end decrypt_byte
After the header is decrypted, the last 1 or 2 bytes in Buffer
- SHOULD be the high-order word/byte of the CRC for the file being
+ should be the high-order word/byte of the CRC for the file being
decrypted, stored in Intel low-byte/high-byte order. Versions of
PKZIP prior to 2.0 used a 2 byte CRC check; a 1 byte CRC check is
used on versions after 2.0. This can be used to test if the password
@@ -2735,10 +2517,10 @@
7.1.7 Version 6.3 introduces support for encrypting data using the Blowfish
and Twofish algorithms. These are symmetric block ciphers developed
by Bruce Schneier. Blowfish supports using a variable length key from
- 32 to 448 bits. Block size is 64 bits. Implementations SHOULD use 16
+ 32 to 448 bits. Block size is 64 bits. Implementations should use 16
rounds and the only mode supported within ZIP files is CBC. Twofish
supports key sizes 128, 192 and 256 bits. Block size is 128 bits.
- Implementations SHOULD use 16 rounds and the only mode supported within
+ Implementations should use 16 rounds and the only mode supported within
ZIP files is CBC. Information and source code for both Blowfish and
Twofish algorithms can be found on the internet. Consult with the author
of these algorithms for information on terms or restrictions on use.
@@ -2750,8 +2532,8 @@
Central Directory structure cannot rely on the data in the corresponding
Local Header for decompression information.
- 7.1.9 Extra Field records that MAY contain information about a file that SHOULD
- not be exposed SHOULD NOT be stored in the Local Header and SHOULD only
+ 7.1.9 Extra Field records that may contain information about a file that should
+ not be exposed should not be stored in the Local Header and should only
be written to the Central Directory where they can be encrypted. This
design currently does not support streaming. Information in the End of
Central Directory record, the Zip64 End of Central Directory Locator,
@@ -2762,11 +2544,11 @@
7.1.10 Older ZIP compatible programs not familiar with the Central Directory
Encryption feature will no longer be able to recognize the Central
- Directory and MAY assume the ZIP file is corrupt. Programs that
+ Directory and may assume the ZIP file is corrupt. Programs that
attempt streaming access using Local Headers will see invalid
information for each file. Central Directory Encryption need not be
used for every ZIP file. Its use is recommended for greater security.
- ZIP files not using Central Directory Encryption SHOULD operate as
+ ZIP files not using Central Directory Encryption should operate as
in the past.
7.1.11 This strong encryption feature specification is intended to provide for
@@ -2853,10 +2635,10 @@
VData VSize-4 Password validation data
VCRC32 4 bytes Standard ZIP CRC32 of password validation data
- 7.2.4.1 IVData - The size of the IV SHOULD match the algorithm block size.
+ 7.2.4.1 IVData - The size of the IV should match the algorithm block size.
The IVData can be completely random data. If the size of
the randomly generated data does not match the block size
- it SHOULD be complemented with zero's or truncated as
+ it should be complemented with zero's or truncated as
necessary. If IVSize is 0,then IV = CRC32 + Uncompressed
File Size (as a 64 bit little-endian, unsigned integer value).
@@ -2897,9 +2679,9 @@
derive keys. File session keys are derived from a master
session key generated from the user-supplied password.
If the Flags field in the decryption header contains
- the value 0x4000, then the ErdData field MUST be
+ the value 0x4000, then the ErdData field must be
decrypted using 3DES. If the value 0x4000 is not set,
- then the ErdData field MUST be decrypted using AlgId.
+ then the ErdData field must be decrypted using AlgId.
7.2.4.7 Reserved1 - Reserved for certificate processing, if value is
@@ -2917,7 +2699,7 @@
VCRC32 data and will be greater than 4 bytes.
7.2.4.10 VData - Random data for password validation. This data is VSize
- in length and VSize MUST be a multiple of the encryption
+ in length and VSize must be a multiple of the encryption
block size. VCRC32 is a checksum value of VData.
VData and VCRC32 are stored encrypted and start the
stream of encrypted data for a file.
@@ -2932,7 +2714,7 @@
account for a discrepancy found in the implementation of the RC2
algorithm in the cryptographic library on Windows XP SP1 and all
earlier versions of Windows. It is recommended that zero length files
- not be encrypted, however programs SHOULD be prepared to extract them
+ not be encrypted, however programs should be prepared to extract them
if they are found within a ZIP file.
7.2.5.2 A pseudo-code representation of the encryption process is as follows:
@@ -2972,9 +2754,9 @@
Masking replaces the true content of the fields for a file in the Local
Header with false information. When masked, the Local Header is not
suitable for streaming access and the options for data recovery of damaged
- archives is reduced. Extra Data fields that MAY contain confidential
- data SHOULD NOT be stored within the Local Header. The value set into
- the Version needed to extract field SHOULD be the correct value needed to
+ archives is reduced. Extra Data fields that may contain confidential
+ data should not be stored within the Local Header. The value set into
+ the Version needed to extract field should be the correct value needed to
extract the file without regard to Central Directory Encryption. The fields
within the Local Header targeted for masking when the Central Directory is
encrypted are:
@@ -2995,12 +2777,12 @@
The Base 16 value assigned as a masked file name is simply a sequentially
incremented value for each file starting with 1 for the first file.
- Modifications to a ZIP file MAY cause different values to be stored for
+ Modifications to a ZIP file may cause different values to be stored for
each file. For compatibility, the file name field in the Local Header
- SHOULD NOT be left blank. As of Version 6.2 of this specification,
+ should never be left blank. As of Version 6.2 of this specification,
the Compression Method and Compressed Size fields are not yet masked.
Fields having a value of 0xFFFF or 0xFFFFFFFF for the ZIP64 format
- SHOULD NOT be masked.
+ should not be masked.
7.3.3 Encrypting the Central Directory
@@ -3010,7 +2792,7 @@
of Central Directory record. The ZIP file comment data is never
encrypted.
- Before encrypting the Central Directory, it MAY optionally be compressed.
+ Before encrypting the Central Directory, it may optionally be compressed.
Compression is not required, but for storage efficiency it is assumed
this structure will be compressed before encrypting. Similarly, this
specification supports compressing the Central Directory without
@@ -3083,7 +2865,7 @@
0x800E SHA512
7.3.5 When the Central Directory data is signed, the same hash algorithm
- used to hash the Central Directory for signing SHOULD be used.
+ used to hash the Central Directory for signing should be used.
This is recommended for processing efficiency, however, it is
permissible for any of the above algorithms to be used independent
of the signing process.
@@ -3091,7 +2873,7 @@
The Hash Data will contain the hash data for the Central Directory.
The length of this data will vary depending on the algorithm used.
- The Version Needed to Extract SHOULD be set to 62.
+ The Version Needed to Extract should be set to 62.
The value for the Total Number of Entries on the Current Disk will
be 0. These records will no longer support random access when
@@ -3123,11 +2905,11 @@
0x0007 - reserved for future use
0x000F - reserved for future use
0x0100 - Indicates non-OAEP key wrapping was used. If this
- this field is set, the version needed to extract MUST
+ this field is set, the version needed to extract must
be at least 61. This means OAEP key wrapping is not
used when generating a Master Session Key using
ErdData.
- 0x4000 - ErdData MUST be decrypted using 3DES-168, otherwise use the
+ 0x4000 - ErdData must be decrypted using 3DES-168, otherwise use the
same algorithm used for encrypting the file contents.
0x8000 - reserved for future use
@@ -3241,7 +3023,7 @@
Decryption Header if the Central Directory is encrypted.
7.5.2 The Archive Extra Data record will be used to store the following
- information. Additional data MAY be added in future versions.
+ information. Additional data may be added in future versions.
Extra Data Fields:
@@ -3252,8 +3034,8 @@
The 0x0014 and 0x0016 Extra Data records that otherwise would be
located in the first record of the Central Directory for digital
certificate processing. When encrypting or compressing the Central
- Directory, the 0x0014 and 0x0016 records MUST be located in the
- Archive Extra Data record and they SHOULD NOT remain in the first
+ Directory, the 0x0014 and 0x0016 records must be located in the
+ Archive Extra Data record and they should not remain in the first
Central Directory record. The Archive Extra Data record will also
be used to store the 0x0019 data.
@@ -3300,23 +3082,12 @@
certificate processing method set a value of 61 into the
version needed to extract field for a file. This indicates that
non-OAEP key wrapping is used. This affects certificate encryption
- only, and password encryption functions SHOULD NOT be affected by
- this value. This means values of 61 MAY be found on files encrypted
+ only, and password encryption functions should not be affected by
+ this value. This means values of 61 may be found on files encrypted
with certificates only, or on files encrypted with both password
encryption and certificate encryption. Files encrypted with both
methods can safely be decrypted using the password methods documented.
-7.8 Additional Encryption/Decryption Data Records
------------------------------------------------------
-
- 7.8.1 Additional information MAY be stored within a ZIP file in support
- of the strong password and certificate encryption methods defined above.
- These include, but are not limited to the following record types.
-
- 0x0021 Policy Decryption Key Record
- 0x0022 Smartcrypt Key Provider Record
- 0x0023 Smartcrypt Policy Key Data Record
-
8.0 Splitting and Spanning ZIP files
-------------------------------------
@@ -3361,14 +3132,14 @@
8.3.4 The .ZIP extension is used on the last segment to support
quickly reading the central directory. The segment number
- n SHOULD be a decimal value.
+ n should be a decimal value.
8.4 Spanned Self-extracting ZIP Files
- 8.4.1 Spanned ZIP files MAY be PKSFX Self-extracting ZIP files.
- PKSFX files MAY also be split, however, in this case
- the first segment MUST be named filename.exe. The first
- segment of a split PKSFX archive MUST be large enough to
+ 8.4.1 Spanned ZIP files may be PKSFX Self-extracting ZIP files.
+ PKSFX files may also be split, however, in this case
+ the first segment must be named filename.exe. The first
+ segment of a split PKSFX archive must be large enough to
include the entire executable program.
8.5 Capacities and Markers
@@ -3376,20 +3147,20 @@
8.5.1 Capacities for split archives are as follows:
Maximum number of segments = 4,294,967,295 - 1
- Maximum .ZIP segment size = 4,294,967,295 bytes
+ Maximum .ZIP segment size = 4,294,967,295 bytes
Minimum segment size = 64K
Maximum PKSFX segment size = 2,147,483,647 bytes
- 8.5.2 Segment sizes MAY be different however by convention, all
- segment sizes SHOULD be the same with the exception of the
- last, which MAY be smaller. Local and central directory
- header records MUST NOT be split across a segment boundary.
+ 8.5.2 Segment sizes may be different however by convention, all
+ segment sizes should be the same with the exception of the
+ last, which may be smaller. Local and central directory
+ header records must never be split across a segment boundary.
When writing a header record, if the number of bytes remaining
within a segment is less than the size of the header record,
end the current segment and write the header at the start
- of the next segment. The central directory MAY span segment
+ of the next segment. The central directory may span segment
boundaries, but no single record in the central directory
- SHOULD be split across segments.
+ should be split across segments.
8.5.3 Spanned/Split archives created using PKZIP for Windows
(V2.50 or greater), PKZIP Command Line (V2.50 or greater),
@@ -3399,7 +3170,7 @@
followed immediately by the local header signature for
the first file in the archive.
- 8.5.4 A special spanning marker MAY also appear in spanned/split
+ 8.5.4 A special spanning marker may also appear in spanned/split
archives if the spanning or splitting process starts but
only requires one segment. In this case the 0x08074b50
signature will be replaced with the temporary spanning
@@ -3418,7 +3189,7 @@
------------------
9.1 In order for the .ZIP file format to remain a viable technology, this
- specification SHOULD be considered as open for periodic review and
+ specification should be considered as open for periodic review and
revision. Although this format was originally designed with a
certain level of extensibility, not all changes in technology
(present or future) were or will be necessarily considered in its
@@ -3433,7 +3204,7 @@
9.3 Periodic revisions to this specification will be published as
DRAFT or as FINAL status to ensure interoperability. We encourage
- comments and feedback that MAY help improve clarity or content.
+ comments and feedback that may help improve clarity or content.
10.0 Incorporating PKWARE Proprietary Technology into Your Product
@@ -3445,7 +3216,7 @@
PKWARE at zipformat@pkware.com or +1-414-289-9788 with regard to
acquiring such a license.
- 10.2 Additional information regarding PKWARE proprietary technology is
+ 10.2 Additional information regarding PKWARE proprietray technology is
available at http://www.pkware.com/appnote.
11.0 Acknowledgements
@@ -3494,7 +3265,7 @@
A.1 Field Definition Structure:
- a. field length including length 2 bytes Big Endian
+ a. field length including length 2 bytes
b. field code 2 bytes
c. data x bytes
@@ -3509,7 +3280,7 @@
4008 Database file and fields definition
4009 GZIP file type 2 bytes
400B IFS code page 2 bytes
- 400C IFS Time of last file status change 4 bytes
+ 400C IFS Creation Time 4 bytes
400D IFS Access Time 4 bytes
400E IFS Modification time 4 bytes
005C Length of the records in the file 2 bytes
@@ -3520,7 +3291,7 @@
B.1 Field Definition Structure:
- a. field length including length 2 bytes Big Endian
+ a. field length including length 2 bytes
b. field code 2 bytes
c. data x bytes
@@ -3633,22 +3404,6 @@
0072 Archive device UNIT 6 bytes EBCDIC
0073 Archive 1st Volume 6 bytes EBCDIC
0074 Archive 1st VOL File Seq# 2 bytes Binary
- 0075 Native I/O Flags 2 bytes
- 0081 Unix File Type 1 byte enumerated
- 0082 Unix File Format 1 byte enumerated
- 0083 Unix File Character Set Tag Info 4 bytes
- 0090 ZIP Environmental Processing Info 4 bytes
- 0091 EAV EATTR Flags 1 byte
- 0092 DSNTYPE Flags 1 byte
- 0093 Total Space Allocation (Cyls) 4 bytes Big Endian
- 009D NONVSAM DSORG 2 bytes
- 009E Program Virtual Object Info 3 bytes
- 009F Encapsulated file Info 9 bytes
- 400C Unix File Creation Time 4 bytes
- 400D Unix File Access Time 4 bytes
- 400E Unix File Modification time 4 bytes
- 4101 IBMCMPSC Compression Info variable
- 4102 IBMCMPSC Compression Size 8 bytes Big Endian
APPENDIX C - Zip64 Extensible Data Sector Mappings
---------------------------------------------------
@@ -3689,22 +3444,22 @@
languages. To address this limitation, this specification will support the
following change.
-D.2 If general purpose bit 11 is unset, the file name and comment SHOULD conform
+D.2 If general purpose bit 11 is unset, the file name and comment should conform
to the original ZIP character encoding. If general purpose bit 11 is set, the
-filename and comment MUST support The Unicode Standard, Version 4.1.0 or
+filename and comment must support The Unicode Standard, Version 4.1.0 or
greater using the character encoding form defined by the UTF-8 storage
specification. The Unicode Standard is published by the The Unicode
Consortium (www.unicode.org). UTF-8 encoded data stored within ZIP files
is expected to not include a byte order mark (BOM).
-D.3 Applications MAY choose to supplement this file name storage through the use
+D.3 Applications may choose to supplement this file name storage through the use
of the 0x0008 Extra Field. Storage for this optional field is currently
undefined, however it will be used to allow storing extended information
-on source or target encoding that MAY further assist applications with file
+on source or target encoding that may further assist applications with file
name, or file content encoding tasks. Please contact PKWARE with any
-requirements on how this field SHOULD be used.
+requirements on how this field should be used.
-D.4 The 0x0008 Extra Field storage MAY be used with either setting for general
+D.4 The 0x0008 Extra Field storage may be used with either setting for general
purpose bit 11. Examples of the intended usage for this field is to store
whether "modified-UTF-8" (JAVA) is used, or UTF-8-MAC. Similarly, other
commonly used character encoding (code page) designations can be indicated
@@ -3716,7 +3471,7 @@
D.5 General purpose bit 11 will not imply any encoding of file content or
password. Values defining character encoding for file content or
-password MUST be stored within the 0x0008 Extended Language Encoding
+password must be stored within the 0x0008 Extended Language Encoding
Extra Field.
D.6 Ed Gordon of the Info-ZIP group has defined a pair of "extra field" records
@@ -3732,42 +3487,11 @@
Extra Field) and 0x7075 (Info-ZIP Unicode Path Extra Field).
D.8 The choice of which storage method to use when writing a ZIP file is left
-to the implementation. Developers SHOULD expect that a ZIP file MAY
-contain either method and SHOULD provide support for reading data in
+to the implementation. Developers should expect that a ZIP file may
+contain either method and should provide support for reading data in
either format. Use of general purpose bit 11 reduces storage requirements
for file name data by not requiring additional "extra field" data for
each file, but can result in older ZIP programs not being able to extract
files. Use of the 0x6375 and 0x7075 records will result in a ZIP file
-that SHOULD always be readable by older ZIP programs, but requires more
+that should always be readable by older ZIP programs, but requires more
storage per file to write file name and/or file comment fields.
-
-APPENDIX E - AE-x encryption marker
------------------------------------
-
-E.1 AE-x defines an alternate password-based encryption method used
-in ZIP files that is based on a file encryption utility developed by
-Dr. Brian Gladman. Information on Dr. Gladman's method is available at
-
- http://www.gladman.me.uk/cryptography_technology/fileencrypt/
-
-E.2 AE-x uses AES with CTR (counter mode) and HMAC-SHA1. It defines
-encryption using key sizes of 128 bits or 256 bits. It does not
-restrict support for decrypting 192 bits.
-
-E.3 This method uses the standard ZIP encryption bit (bit 0)
-of the general purpose bit flag (section 4.4.4) to indicate a
-file is encrypted.
-
-E.4 The compression method field (section 4.4.5) is set to 99
-to indicate a file has been encrypted using this method.
-
-E.5 The actual compression method is stored in an extra field
-structure identified by a Header ID of 0x9901. Information on this
-record structure can be found at http://www.winzip.com/aes_info.htm.
-
-E.6 Two versions are defined for the 0x9901 structure.
-
- E.6.1 Version 1 stores the file CRC value in the CRC-32 field
- (section 4.4.7).
-
- E.6.2 Version 2 stores a value of 0 in the CRC-32 field.
diff --git a/lib/zip_algorithm_zstd.c b/lib/zip_algorithm_zstd.c
index 0c7712e..1bd25d4 100644
--- a/lib/zip_algorithm_zstd.c
+++ b/lib/zip_algorithm_zstd.c
@@ -197,7 +197,7 @@
compress_allocate,
deallocate,
general_purpose_bit_flags,
- 20,
+ 63,
start,
end,
input,
@@ -210,7 +210,7 @@
decompress_allocate,
deallocate,
general_purpose_bit_flags,
- 20,
+ 63,
start,
end,
input,
