A requirement on a producer or consumer, strictly to be followed for compliance to this Standard shall shall not is required to is, is to is not permitted is not allowed A permission expressed by the Standard might need not is permitted to is allowed is not required to A recommendation expressed by the Standard, it need not be followed should should not it is recommended that is recommended A capability or possibility open to a producer or a consumer of the Standard can cannot is able to it is possible to is possible
Relationship —The kind of connection between a source part and a target part in a package. Relationships make the connections between directly discoverable without looking at the content in the parts, and without altering the parts themselves. (See also Package Relationships.) Relationships part — A part containing an XML representation of relationships. Sequential delivery — A communication in which all of part n is delivered to a consumer before part n+1. Simple ordering — A defined ordering for laying out the parts in a package in which, when the package is delivered in a purely linear fashion, all of the bytes for the first part arrive first, then all of the bytes for the second part, and so on. Simultaneous creation and consumption — A style of communication between a producer and a consumer in highly pipelined environments where streaming creation and streaming consumption occur simultaneously. Stream — A linearly ordered sequence of bytes. Streaming consumption — An access style in which parts of a physical package may be processed by a consumer before all of the bits of the package have been delivered through the pipe. Streaming creation — A generating style in which a producer may dynamically add parts to a package after other parts have been added. Thumbnail — A Image that is a graphical representation of a part or the package as a whole. Well-known part — A part with a well-known relationship, which enables the part to be found without knowing the location of other parts. ZIP Archive — A ZIP file as defined in the ZIP file format specification. A ZIP archive contains ZIP items. ZIP Item — A ZIP item is an atomic set of data in a ZIP archive that becomes a file when the archive is uncompressed. When a user unzips a ZIP based package, the user sees an organized set of files and folders.
Data descriptor Yes Optional Optional Archive decryption header No No No Archive extra data record No No No Central directory structure: File header Yes (partially, details below) Yes (partially, details below) Yes Central directory structure: Digital signature Yes (ignore the signature data) Optional Optional Zip64 end of central directory record V1 (from spec version 4.5) Yes (partially, details below) Yes (partially, details below, used only when needed) Optional Zip64 end of central directory record V2 (from spec version 6.2) No No No Zip64 end of central directory locator Yes (partially, details below) Yes (partially, details used only when needed) Optional End of central directory record Yes (partially, details below) Yes (partially, details used only when needed) Yes Table C–2, “Support for record components”, specifies the requirements for package production, consumption, and editing in regard to individual record components described in the ZIP Appnote.txt. Table –. Support for record components Record Field Supported on Consumption Supported on Production Pass through on editing Local File Header file header signature Yes Yes Yes Version needed to extract Yes (partially, see Table Yes (partially, see Table C–3) Yes (partially, see Table C–3)
General purpose bit flag Yes (partially, see Table Yes (partially, see Table C–5) Yes (partially, see Table C–5) Compression method Yes (partially, see C–4) Yes (partially, see Table C–4) Yes (partially, see Table C–4) Last mod file time Yes Yes Yes Last mod file date Yes Yes Yes Crc-32 Yes Yes Yes Compressed size Yes Yes Yes Uncompressed size Yes Yes Yes File name length Yes Yes Yes Extra field length Yes Yes Yes File name (variable size) Yes Yes Yes Extra field (variable size) Yes (partially, see Table Yes (partially, see Table C–6) Yes (partially, see Table C–6) Central directory File header Central file header signature Yes Yes Yes version made by: high byte Yes Yes (0 = MS-DOS is default publishing value) Yes Version made by: low byte Yes Yes (partial, always 4.5) Yes
Version needed to extract (see Table C–3 for details) Yes (partially, see C–3) Yes (1.0, 1.1, 2.1, 4.5) Yes General purpose bit flag Yes (partially, see Table Yes (partially, see Table C–5) Yes (partially, see Table C–5) Compression method Yes (partially, see Table Yes (partially, see Table C–4) Yes (partially, see Table C–4) Last mod file time (Pass through, no interpretation) Yes Yes Yes Last mod file date (Pass through, in interpretation) Yes Yes Yes Crc-32 Yes Yes Yes Compressed size Yes Yes Yes Uncompressed size Yes Yes Yes File name length Yes Yes Yes Extra field length Yes Yes Yes File comment length Yes Yes (always set to 0) Yes Disk number start Yes (partial — no multi disk archives) Yes (always 1 disk) Yes (partial — no multi disk archives) Internal file attributes Yes Yes Yes
External file attributes (Pass through, no interpretation) Yes Yes (MS DOS default value) Yes Relative offset of local header Yes Yes Yes File name (variable size) Yes Yes Yes field (variable size) Yes (partially, see Table Yes (partially, see Table C–6) Yes (partially, see C–6) File comment (variable size) Yes Yes (always set to empty) Yes end of central directory V1 (from spec version 4.5, only used when needed) Zip64 end of central directory signature Yes Yes Yes Size of zip64 end of central directory Yes Yes Yes Version made by: high byte (Pass through, no interpretation) Yes Yes (0 = MS-DOS is default publishing value) Yes Version made by: low byte Yes Yes (always 4.5) Yes Version needed to extract (see Table C–3 for details) Yes (4.5) Yes (4.5) Yes (4.5) Number of this disk Yes (partial — no multi disk archives) Yes (always 1 disk) Yes (partial — no multi disk archives)
Number of the disk with the of the central directory Yes (partial — no multi disk archives) Yes (always 1 disk) Yes (partial — no multi disk archives) Total number of entries in the central directory on this disk Yes Yes Yes Total number of entries in the central directory Yes Yes Yes Size of the central directory Yes Yes Yes Offset of start of central directory with respect to the starting disk number Yes Yes Yes Zip64 extensible data sector Yes No Yes Zip64 end of central directory locator (only used when needed) Zip64 end of central dir locator signature Yes Yes Yes Number of the disk with the start of the zip64 end of central directory Yes (partial — no disk archives) Yes (always 1 disk) Yes (partial — no multi disk archives) Relative offset of the zip64 end of central directory record Yes Yes Yes
Total number of disks Yes (partial — no multi disk archives) Yes (always 1 disk) Yes (partial — no multi disk archives) End of central directory record End of central dir signature Yes Yes Yes Number of this disk Yes (partial — no disk archives) Yes (always 1 disk) Yes (partial — no multi disk archives) Number of the disk with the start of the central directory Yes (partial — no disk archive) Yes (always 1 disk) Yes (partial — no disk archive) Total number of entries in the central directory on this disk Yes Yes Yes Total number of entries in the central directory Yes Yes Yes Size of the central directory Yes Yes Yes Offset of start of central directory with respect to the starting disk number Yes Yes Yes ZIP file comment length Yes Yes Yes ZIP file comment Yes No Yes
13 Used when encrypting the Central Directory to indicate selected data values in the Local Header are masked to hide their actual values. See the section describing the Strong Encryption Specification for details. Ignore Bits set to 0 Yes 14 Reserved by PKWARE Ignore Bits set to 0 Yes 15 Reserved by PKWARE Ignore Bits set to 0 Yes Table C–6, “Support for Extra field (variable size), PKWARE-reserved”, specifies the detailed production, consumption, and editing requirements for the Extra field entries reserved by PKWARE and described in the ZIP Appnote.txt. –. Support for Extra field (variable size), PKWARE-reserved ID Field description Supported on Consumption Supported on Production Pass through on editing 0x0001 ZIP64 extended information extra field Yes Yes Optional 0x0007 AV Info Ignore No Yes 0x0008 Reserved for future Unicode file name data (PFS) Ignore No Yes 0x0009 OS/2 Ignore No Yes 0x000a NTFS Ignore No Yes 0x000c OpenVMS Ignore No Yes 0x000d Unix Ignore No Yes 0x000e Reserved for file stream and fork descriptors Ignore No Yes 0x000f Patch Descriptor Ignore No Yes 0x0014 PKCS#7 Store for X.509 Certificates Ignore No Yes 0x0015 X.509 Certificate ID and Signature for individual file Ignore No Yes 0x0016 X.509 Certificate ID for Central Directory Ignore No Yes 0x0017 Strong Encryption Header Ignore No Yes 0x0018 Record Management Controls Ignore No Yes
O1.6 A format designer might allow fragment identifiers in the value of the Target attribute of the <Relationship> element. 9.3.3.2 × O1.7 Producers might generate relationship markup that uses the versioning and extensibility mechanisms defined in Part 5: "Markup Compatibility" to incorporate elements and attributes drawn from other XML namespaces. 9.3.5 × Physical Packages –. Physical packages conformance requirements ID Rule Reference Package Implementer Format Designer Format Producer Format Consumer M2.1 The Content stream shall not be mapped to a part by the package implementer. 10.1.2.1 ×A M2.2 The package implementer define a physical package format with a mapping for the required components package, part name, part content type and part contents. 10.1.1 ×
M3.17 A “No” for a field in a table in Annex C indicates the package implementer shall not use this record or field during consumption or production of packages. Annex C × M3.18 A “Partially, details below” value for a record in a table in Annex C indicates that the record contains fields that might not be supported by package implementers during production or consumption. See the details in the corresponding table to determine requirements. C × M3.19 The value “Only used when needed” associated with a record in a table in Annex C indicates that the package implementer shall use the record only when needed to store data in the ZIP archive. Annex C × M3.20 The value “Only used when needed” associated with a record in a table in Annex C indicates that the package implementer shall use the record only when needed to store data in the ZIP archive. Annex C × M3.21 The package implementer shall ensure that all 64-bit stream record sizes and offsets have the high-order bit = 0. Annex C × Notes: A: Only relevant if supporting the interleaving strategy specified in the Open Packaging Conventions. Table –. ZIP physical mapping recommendations ID Rule Reference Package Implementer Format Designer Format Producer Format Consumer S3.1 Package implementers should restrict part naming to accommodate file system limitations when naming parts to be stored as ZIP items. 10.2.5 × Table –. ZIP physical mapping optional requirements
M6.29 When validating digital signatures, consumers shall verify the content type and the digest contained in each <Reference> descendant element of the <SignedInfo> element, and validate the signature calculated using the <SignedInfo> element. 13.5 × M6.30 13.5 × M6.31 Streaming consumers that maintain signatures shall be able to cache the parts necessary for detecting and processing signatures. 13.5.1 × M6.32 The package implementer shall not use the Markup Compatibility namespace, as specified in Annex H, “Standard Namespaces and Content Types,” within the package-specific <Object> element. The package implementer shall consider the use of the Markup Compatibility namespace within the package-specific <Object> element to be an error. 13.6.2 ×
O6.11 The package implementer might create relationships XML that contains content from several namespaces, along with versioning instructions as defined in Part 4: "Markup Compatibility". 13.2.4.26 × O6.12 Format designers might specify an application-specific package part format that allows for the embedding of versioned or extended content that might not be fully understood by all present and future implementations. Producers might create such embedded versioned or extended content and consumers might encounter such content. 13.6.2 × × × Pack URI Table –. Pack URI conformance requirements ID Rule Reference Package Implementer Format Designer Format Producer Format Consumer M7.1 The authority component contains an embedded URI that points to a package. The package implementer shall create an embedded URI that meets the requirements defined in RFC 3986 for a valid URI. B.1 × M7.2 B.1 ×