ZIP文件格式分析
刚分析完RAR文件格式，一想，干脆把ZIP文件格式也分析了吧
不过ZIP文件格式有官方文档，比较详细，这里也就是理解加翻译了一下。英文不好，菜哭。
后面有时间会加入实例分析环节。

1、ZIP简介

  ZIP文件格式是一种数据压缩和文档储存的文件格式，原名Deflate，发明者为菲尔·卡茨(Phil Katz)，他于1989年1月公布了该格式的资料。该格式最初在PKWARE，Inc .的PKZIP实用程序中实现，替代了以前由Thom Henderson发明的ARC压缩格式。ZIP通常使用后缀名“.zip”，也使用“.zipx ”(较新的压缩算法)。ZIP被许多程序用作基本文件格式，通常使用不同的名称。它的MIME格式(Multipurpose Internet Mail Extensions)为application/zip。
  目前，ZIP格式属于几种主流的压缩格式之一，其竞争者包括RAR格式以及开放源码的7z格式。从性能上比较，RAR及7z格式较ZIP格式压缩率较高，而7-Zip由于提供了免费的压缩工具而逐渐在更多的领域得到应用。Microsoft从Windows ME操作系统开始内置对zip格式的支持，即使用户的电脑上没有安装解压缩软件，也能打开和制作zip格式的压缩文件，OS X和流行的Linux操作系统也对zip格式提供了类似的支持。因此如果在网络上传播和分发文件，zip格式往往是最常用的选择。
  ZIP是一种压缩文件格式，支持无损数据压缩。一个ZIP文件可能包含一个或多个已压缩的文件或目录。ZIP文件格式允许多种压缩算法。使用压缩时，必须使用已记录的压缩算法之一。压缩方法8(Deflate)是大多数ZIP兼容应用程序默认使用的方法。

1.1、版本历史

  .ZIP文件格式规范具有其自己的版本号，该版本号不一定与PKZIP工具的版本号相对应，尤其是在PKZIP 6或更高版本中。在不同的时间，PKWARE添加了一些初步功能，这些功能允许PKZIP产品使用高级功能提取压缩文件，但是创建此类压缩文件的PKZIP产品要等到下一个主要发行版本才可用。其他公司或组织以自己的步调支持PKWARE规范。
  .ZIP文件格式规范正式命名为“ APPNOTE-.ZIP文件格式规范”，并且自1990年代末开始在PKWARE.com网站上发布。该规范的多个版本尚未发布。某些功能的规范（例如BZIP2压缩，强大的加密规范(strong encryption specification)等）是在创建后几年由PKWARE发布的。在PKWARE网站上多次更改了在线规范的URL。

各种版本的PKWARE规范的主要改进的摘要：

• 2.0 - (1993) 可以使用DEFLATE压缩文件条目，并使用传统的PKWARE加密(ZipCrypto)。
• 2.1 - (1996) Deflate64压缩。
• 4.5 - (2001) 已记录的64位zip格式。
• 4.6 - (2001) BZIP2压缩(直到APPNOTE 5.2发布时才在线发布)。
• 5.0 - (2002) SES：加密支持DES、Triple DES、RC2、RC4(直到APPNOTE 5.2发布时才在线发布)。
• 5.2 - (2003) SES(未在线发布的APPNOTE 5.1中定义)和WinZip(AE-x)的AES加密支持；SES加密支持的RC2-64的更正版本。
• 6.1 - (2004) 已记录的证书存储。
• 6.2.0 - (2004) 已记录的中心目录(Central Directory)加密。
• 6.3.0 - (2006) 已记录的Unicode(UTF-8)文件名存储。支持的哈希，压缩(LZMA，PPMd +)，加密算法的扩展列表。
• 6.3.1 - (2007) 已更正的SHA-256/384/512的标准哈希值。
• 6.3.2 - (2007) 已记录的压缩方法97(WavPack)。
• 6.3.3 - (2012) 文档格式更改，使用JTC 1/SC 34 N 1621指示的JTC 1参考解释性报告(RER)等方法，以方便从其他标准参考PKWARE应用说明。
• 6.3.4 - (2014) 更新PKWARE，Inc.官方地址。
• 6.3.5 - (2018) 已记录的压缩方法16、96和99，DOS时间戳时间和精度，为密钥和解密增加了额外字段，以及错别字和说明。
• 6.3.6 - (2019) 更正了印刷错误。

  WinZip从版本12.1开始，对于使用压缩方法比DEFLATE更新的ZIP文件使用扩展名.zipx。特别是方法BZip、LZMA、PPMd、Jpeg和Wavpack。当选择“最佳方法”压缩时，后两种将应用于适当的文件类型。

2、ZIP文件

2.1、什么是ZIP文件

  ZIP文件可以由标准.ZIP文件扩展名标识，尽管不需要使用文件扩展名。使用.ZIPX扩展名也可以用于识别ZIP文件。其他使用ZIP格式的常见文件扩展名包括.JAR、.WAR、.DOCX、.XLSX、.PPTX、.ODT、.ODS、.ODP等。读取或写入ZIP文件的程序应依靠本文档中描述的内部记录签名来标识这种格式的文件。
  ZIP文件应至少包含一个文件，并且可以包含多个文件。
  数据压缩可以用来减少放置在ZIP文件中的文件的大小，但这不是必需的。此格式支持使用多种数据压缩算法。使用压缩时，必须使用已记录的压缩算法之一。建议实验者对他们的数据进行试验，以确定哪种可用算法可以提供最佳压缩以满足他们的需求。压缩方法8(Deflate)是大多数ZIP兼容应用程序默认使用的方法。
  数据加密可以用来保护ZIP文件中的文件。在这种格式下，加密支持的加密方法包括密码和公用/专用密钥。可以单独使用或结合使用。加密可以应用于单个文件。可以通过加密ZIP文件的存储在中心目录(Central Directory)中的元数据来增加额外的安全性。
  必须使用CRC32为每个文件提供数据完整性。
  通过使用数字签名，可以包括其他数据完整性。 单个文件可以使用一个或多个数字签名进行签名。 中心目录(Central Directory)（如果签名）必须使用单个签名。
  文件可以放在未压缩或存储的ZIP文件中。本文档中使用的术语“存储”是指文件被复制到未压缩的ZIP文件中。
  放置在ZIP文件中的每个数据文件都可以进行压缩，存储，加密或与同一ZIP文件中其他数据文件的存档方式无关的数字签名。
  ZIP文件可以流式传输，分段(在固定或可移动的媒体上)或“自解压”。 自解压ZIP文件必须在ZIP文件中包含目标平台的提取代码。
  ZIP的常见用法或许还包括清单文件的使用。 清单文件将应用程序的特定信息存储在已存储在ZIP文件中的文件中。 这个清单文件应该是ZIP文件中的第一个文件。 该规范(官方文档)不提供任何有关在ZIP文件中使用清单文件的信息或指南。
  ZIP文件可以放在其他ZIP文件中。

2.2、ZIP元数据(ZIP Metadata)

  ZIP文件由元数据标识，元数据由定义的记录类型组成，这些记录类型包含维护放置在ZIP文件中的文件所需的存储信息。 每个记录类型必须使用标识记录类型的头标识来标识。 标识值以两个字节的常量标记0x4b50开头，代表字符“PK”。

2.3、.ZIP文件的常规格式

  一个ZIP文件必须包含“中心目录结束记录(End of Central Directory Record)”。 仅包含“中心目录结束记录(End of Central Directory Record)”的ZIP文件被视为空ZIP文件。 可以在ZIP文件中添加或替换文件，也可以删除文件。 一个ZIP文件必须只有一个“中心目录结束记录(End of Central Directory Record)”。 本规范中定义的其他记录可以根据需要用于支持单个ZIP文件的存储要求。
  在ZIP文件中的每个文件的前面都必须有一个该文件的“本地文件头(Local File Header)”记录。 每个“本地文件头(Local File Header)”都必须在ZIP文件的中心目录(Central Directory)部分中随附一个相应的“中心目录头(Central Directory Header)”记录。
  文件可以在ZIP文件中以任意顺序存储。 一个ZIP文件可以分割成多个卷，也可以分成用户定义的段大小。 除非本文档中为特定数据元素另外指定，否则所有值都必须以小端字节顺序存储。
  压缩不得应用于“本地文件头(Local File Header)”，“加密头(encryption header)”或“中心目录结束记录(End of Central Directory Record)”。 单个“中心目录记录(Central Directory Records)”绝不能压缩，但是所有“中心目录记录(Central Directory Records)”的总和可以压缩。
  文件数据后可以跟文件的“数据描述符(Data Descriptor)”。 数据描述符用于促进ZIP文件流传输。

2.3.1、.ZIP文件整体布局

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

[local file header 1] - 本地文件头1
[encryption header 1] - 加密头1
[file data 1] - 文件数据1
[data descriptor 1] - 数据描述符1
.
.
[local file header n] - 本地文件头n
[encryption header n] - 加密头n
[file data n] - 文件数据n
[data descriptor n] - 数据描述符n
[archive decryption header] - 压缩文档解密头
[archive extra data record] - 压缩文档扩展数据记录
[central directory header 1] - 中心目录头1
.
.
[central directory header n] - 中心目录头n
[digital signature] - 数字签名
[zip64 end of central directory record] - zip64中心目录结束记录
[zip64 end of central directory locator] - zip64中心目录结束定位器
[end of central directory record] - 中心目录结束记录

2.3.2、本地文件头(Local File Header)

  扩展区域包含各种可选数据，例如特定于OS的属性。它分为多个块，每个块具有16位ID码和16位长度。紧随其后的是压缩数据。

2.3.3、文件数据(File data)

  应将文件的压缩或存储数据紧随在本地文件头(Local File Header)后。如果文件已加密，则文件的加密头(encryption header)应放置在本地文件头(Local File Header)之后和文件数据之前。 对于.ZIP压缩文档中的每个文件，重复执行一系列的[本地文件头][加密头][文件数据][数据描述符]结构。
  0字节文件，目录和其他不包含任何内容的文件类型，不得包含文件数据。

2.3.4、数据描述符(Data descriptor)

  如果设置了通用位标志的位3，则该描述符必须存在(见下文)。 它按字节对齐，紧随压缩数据的最后一个字节。仅在无法在输出的.ZIP文件中查找时(例如，当输出.ZIP文件是标准输出或不可搜索的设备时)，才应使用此描述符。对于ZIP64(tm)格式的压缩文件，压缩和未压缩的大小均为8个字节。
  压缩文件时，当文件大小超过0xFFFFFFFF时，压缩和未压缩的大小应以ZIP64格式(作为8字节的值)存储。 但是，无论文件大小如何，都可以使用ZIP64格式。 解压缩时，如果该文件存在ZIP64扩展信息扩展区域，则压缩和未压缩的大小将为8字节的值。
  尽管最初未指定标识，但通常将值0x08074B50用作数据描述符记录的标识值。 实现者应注意，在读取ZIP文件以确保兼容性时，无论是否带有此标识标记的数据描述符，都可能会遇到ZIP文件，无论哪种情况都应说明。
  写ZIP文件时，实现者应包括标记数据描述符记录的标识值。 使用标识时，当前为数据描述符记录定义的字段将紧随标识之后。
  可扩展的数据描述符将在此APPNOTE的将来版本中发布。 此新记录旨在解决先前使用此记录的冲突，并为流文件处理提供更好的支持。
  当使用中心目录加密方法时，数据描述符记录不是必需的，但可以使用。 如果存在，并且通用位标记的位3被设置为指示其存在，则数据描述符记录的字段中的值必须设置为二进制0。

2.3.5、压缩文档解密头(Archive decryption header)

  ZIP格式规范的6.2版中引入了压缩文档解密头。 该记录的存在是对作为本文档中所述的强加密规范的一部分实现的中心目录加密功能的支持。当中心目录结构已加密时，此解密头必须位于加密数据段之前。
  加密的数据段应包含压缩文档扩展数据记录(如果存在)和加密的中心目录结构数据。 该数据记录的格式与压缩文件数据之前的加密头记录相同。 如果中心目录结构已加密，则使用“ZIP64中心目录结束记录(ZIP64 end of central directory record)”中的“中心目录的开始(Start of Central Directory)”字段确定此数据记录的开始位置。 有关压缩文档解密头记录中使用的字段的信息，请参阅“强加密规范”部分。

2.3.6、压缩文档扩展数据记录(Archive extra data record)

  ZIP格式规范的6.2版中引入了Archive Extra Data Record。 该记录可以用于支持作为本文档中所述的强加密规范的一部分实现的中心目录加密功能。当该记录存在时，该记录必须紧随中心目录数据结构之前。
  该数据记录的大小应包含在中心目录结束记录(End of central directory record)的中心目录大小(Size of the Central Directory)字段中。 如果中心目录结构已压缩，但未加密，则使用“ZIP64中心目录结束记录(ZIP64 end of central directory record)”中的“中心目录的开始(Start of Central Directory)”字段确定此数据记录的起始位置。

2.3.7、中心目录结构(Central directory structure)

1
2
3
4
5

[central directory header 1] - 中心目录头1
.
.
[central directory header n] - 中心目录头n
[digital signature] - 数字签名

中心目录头(Central directory header):

数字签名(Digital signature):

  随着本规范6.2版中中心目录加密功能的引入，中心目录结构(Central directory structure)可以以压缩并加密的方式存储。 尽管不是必需的，但在加密中心目录结构时假定它会被压缩以提高存储效率。有关中心目录加密功能的信息可以在描述强加密规范(Strong Encryption Specification)的部分中找到。数字签名记录(Digital signature)将不会被压缩或加密。

2.3.8、ZIP64中心目录结束记录(ZIP64 end of central directory record)

  存储在“ZIP64中心目录结束记录的大小(Size of ZIP64 end of central directory record)”中的值应为剩余记录的大小，并且不应包含前导的12个字节。

1

Size = SizeOfFixedFields(固定字段) + SizeOfVariableData(可变数据)- 12

  上面的记录结构定义了ZIP64中心目录结束记录的版本1。 为了支持ZIP64大文件功能，在6.2之前的版本中实现了版本1。 作为强加密规范的一部分，在版本6.2中实现的中心目录加密功能的引入定义了此记录结构的版本2。 有关此记录的版本2格式的详细信息，请参阅描述“强加密规范”的部分。
  特殊用途的数据可以位于该记录的V1或V2版本后面的ZIP64扩展数据段中。为了确保识别此特殊用途的数据，它必须包括一个由以下内容组成的识别头块：

  可能存在多个特殊用途的数据块。 每一个必须以Header ID和Data Size字段为先导字段。 当前该字段中支持的Header ID值的映射如附录C中所定义。

2.3.9、ZIP64中心目录结束定位器(ZIP64 end of central directory locator)

2.3.10、中心目录结束记录(End of central directory record)

2.4、字段解释

2.4.1、字段的一般说明

  除非另有说明，否则所有字段均为无符号数据类型，并以Intel低字节:高字节，低字节:高字节顺序存储(小端模式)。
  字符串字段不是以null结尾的，因为长度是明确指定的。
  中心目录中的条目的顺序可能不一定与文件在.ZIP文件中出现的顺序相同。
  如果中心目录结束记录的字段之一太小而无法容纳所需的数据，则应将字段设置为-1(0xFFFF或0xFFFFFFFF)，并应创建ZIP64格式的记录。
  拆分或扩展压缩文件时，中心目录结束记录和ZIP64中心目录结束定位器记录的务必驻留在同一磁盘上。

2.4.2、压缩所用的ZIP版本(Version made by) (2 bytes)

  高位字节指示文件属性信息的兼容性。 如果外部文件属性与MS-DOS兼容并且可以由DOS版本2.04g的PKZIP读取，则该值将为零。 如果这些属性不兼容，则此值将标识属性兼容的主机系统。 软件可以使用此信息来确定文本文件等的行记录格式。

当前的映射为：

1
2
3
4
5
6
7
8
9
10
11

0 - MS-DOS and OS/2(FAT/VFAT/FAT32 file systems)
1 - Amiga                     2 - OpenVMS
3 - UNIX                      4 - VM/CMS
5 - Atari ST                  6 - OS/2 H.P.F.S.
7 - Macintosh                 8 - Z-System
9 - CP/M                      10 - Windows NTFS
11 - MVS (OS/390 - Z/OS)      12 - VSE
13 - Acorn Risc               14 - VFAT
15 - alternate MVS            16 - BeOS
17 - Tandem                   18 - OS/400
19 - OS X (Darwin)            20 thru 255 - unused

  低位字节指示用于编码文件的软件支持的ZIP规范版本(本文档的版本)。 value/10表示主要版本号，value mod 10是次要版本号。

2.4.3、解压文件所需的ZIP最低版本(Version needed to extract) (2 bytes)

  解压文件所需的最低受支持ZIP规范版本，如上映射。该值基于ZIP程序必须支持的特定格式功能才能解压文件。如果将多个功能应用于文件，则必须将最低版本设置为具有最高值的功能的版本值。为了避免冲突，新功能或功能更改将使用比上次发布的值更高的版本号实现影响已发布的格式规范。

当前的最低功能版本如下所示：

• 1.0 - Default value：默认值。
• 1.1 - File is a volume label：文件是一个卷标。
• 2.0 - File is a folder (directory)：文件是一个文件夹(目录)。
• 2.0 - File is compressed using Deflate compression：使用Deflate压缩方法对文件进行压缩。
• 2.0 - File is encrypted using traditional PKWARE encryption：使用传统的PKWARE加密对文件进行加密。
• 2.1 - File is compressed using Deflate64(tm)：使用Deflate64(tm)压缩方法对文件进行压缩。
• 2.5 - File is compressed using PKWARE DCL Implode：使用PKWARE DCL Implode压缩方法对文件进行压缩。
• 2.7 - File is a patch data set：文件是补丁数据集。
• 4.5 - File uses ZIP64 format extensions：文件使用ZIP64格式扩展。
• 4.6 - File is compressed using BZIP2 compression*：使用BZIP2压缩方法对文件进行压缩。
• 5.0 - File is encrypted using DES：使用DES对文件进行加密。
• 5.0 - File is encrypted using 3DES：使用3DES对文件进行加密。
• 5.0 - File is encrypted using original RC2 encryption：使用原始RC2加密对文件进行加密。
• 5.0 - File is encrypted using RC4 encryption：使用RC4加密对文件进行加密。
• 5.1 - File is encrypted using AES encryption：使用AES加密对文件进行加密。
• 5.1 - File is encrypted using corrected RC2 encryption**：使用更正的RC2加密对文件进行加密。
• 5.2 - File is encrypted using corrected RC2-64 encryption**：使用更正的RC2-64加密对文件进行加密
• 6.1 - File is encrypted using non-OAEP key wrapping*：使用non-OAEP密钥包装对文件进行加密。
• 6.2 - Central directory encryption：中心目录加密。
• 6.3 - File is compressed using LZMA：使用LZMA压缩方法对文件进行压缩。
• 6.3 - File is compressed using PPMd+：使用PPMd+压缩方法对文件进行压缩。
• 6.3 - File is encrypted using Blowfish：使用Blowfish对文件进行加密。
• 6.3 - File is encrypted using Twofish：使用Twofish对文件进行加密。

需要解压的版本注释：
  PKZIP的7.x(7.2之前)的早期版本错误地将BZIP2压缩所需的提取版本设置为50，但应将其设置为46。
  有关RC2校正的更多信息，请参阅“强加密规范”部分。
  使用non-OAEP密钥包装的证书加密是从6.1开始的所有版本的预期操作模式。当发送要由低于6.1(5.0或6.0)的PKZIP版本打开的ZIP文件时，对OAEP密钥包装的支持只能用于向后兼容。
  使用PPMd+压缩的文件必须将解压文件所需的版本字段设置为6.3，但是，并非所有ZIP程序都强制执行此操作，并且如果设置了该值，则可能无法解压缩使用PPMd+压缩的数据文件。
  使用ZIP64扩展时，还必须在ZIP64中心目录结束记录中设置相应的值。 应该适当地设置该字段以指示使用的是版本1还是版本2格式。

2.4.4、通用位标志(General purpose bit flag) (2 bytes)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

Bit 0: 如果设置，表示文件已加密。

(压缩方法6 - Imploding)
Bit 1: 如果使用的压缩方法是类型6，Imploding。如果设置了此位，表明
       使用了8K滑动词典。如果清除了此位，表明使用了4K滑动词典。
Bit 2: 如果使用的压缩方法是类型6，Imploding。如果设置了此位，表明
       使用了3个Shannon-Fano树来编码滑动字典输出。如果清除了此位，
       则使用了2个Shannon-Fano树。

(压缩方法8和9 - Deflating)
Bit 2  Bit 1
  0      0    使用了正常（-en）压缩选项。
  0      1    使用了最大（-exx/-ex）压缩选项。
  1      0    使用了快速（-ef）压缩选项。
  1      1    使用了超快速（-es）压缩选项。

(压缩方法14 - LZMA)
Bit 1: 如果使用的压缩方法是类型14，LZMA。如果设置了此位，表明使用
       end-of-stream(EOS)标记来标记压缩数据流的结束。如果清除了
       此位，则不使用EOS标记，并且必须知道提取的压缩数据大小。
注意: 如果压缩方法是任何其他方式，则位1和2是不确定的。


Bit 3: 如果设置了此位，则本地头中的字段CRC-32，压缩大小和未压缩大小
       设置为零。正确的值将紧随压缩数据之后放入数据描述符中。
注意：用于DOS的PKZIP版本2.04g仅在压缩方法8中识别此位，对于任何压缩方法，较新版本的PKZIP均识别该位。
Bit 4: 保留用于压缩方法8，以增强deflating。
Bit 5: 如果设置此位，则表明文件是压缩的补丁数据。
注意：需要PKZIP版本2.70或更高版本。
Bit 6: 强加密功能。如果设置了此位，则必须将提取文件所需的版本设置为
       至少50，并且还必须设置位0。如果使用AES加密，则提取文件所需
       的版本必须至少为51。有关详细信息，请参见强加密规范。 
Bit 7: 目前未使用。
Bit 8: 目前未使用。
Bit 9: 目前未使用。
Bit 10: 目前未使用。
Bit 11: 语言编码标志(EFS)。 如果该位置1，则该文件的文件名和注释字
        段必须使用UTF-8编码。(请参阅附录D)
Bit 12: 由PKWARE保留，用于增强压缩。
Bit 13: 在加密中心目录时设置，以指示本地头中的选定数据值被屏蔽以隐藏
        其实际值。有关详细信息，请参见描述强加密规范的部分。 
Bit 14: 由PKWARE保留。
Bit 15: 由PKWARE保留。

2.4.5、压缩方法(Compression method) (2 bytes)

• 0 - The file is stored (no compression)：存储(无压缩)。
• 1 - The file is Shrunk：文件缩小。
• 2 - The file is Reduced with compression factor 1：待补充。
• 3 - The file is Reduced with compression factor 2：待补充。
• 4 - The file is Reduced with compression factor 3：待补充。
• 5 - The file is Reduced with compression factor 4：待补充。
• 6 - The file is Imploded：Imploding压缩算法。
• 7 - Reserved for Tokenizing compression algorithm：为Tokenizing压缩算法保留。
• 8 - The file is Deflated：Deflated压缩算法。
• 9 - Enhanced Deflating using Deflate64(tm)：加强的压缩算法Deflate64(tm)。
• 10 - PKWARE Data Compression Library Imploding (old IBM TERSE)：PKWARE DCL Implode压缩算法(旧的IBM TERSE压缩算法)。
• 11 - Reserved by PKWARE：由PKWARE预留。
• 12 - File is compressed using BZIP2 algorithm：BZIP2压缩算法。
• 13 - Reserved by PKWARE：由PKWARE预留。
• 14 - LZMA：LZMA压缩算法。
• 15 - Reserved by PKWARE：由PKWARE预留。
• 16 - IBM z/OS CMPSC Compression：IBM z/OS CMPSC压缩算法。
• 17 - Reserved by PKWARE：由PKWARE预留。
• 18 - File is compressed using IBM TERSE (new)：IBM TERSE压缩算法(新的)。
• 19 - IBM LZ77 z Architecture (PFS)：IBM LZ77 z Architecture压缩算法。
• 96 - JPEG variant：JPEG变种压缩算法。
• 97 - WavPack compressed data：WavPack压缩算法。
• 98 - PPMd version I, Rev 1：PPMd压缩算法版本1。
• 99 - AE-x encryption marker (see APPENDIX E)：AE-x加密标记(请参阅附录E)。

2.4.6、日期和时间字段(Date and Time fields) (2 bytes)

  日期和时间以标准MS-DOS格式编码。如果输入来自标准输入，则日期和时间是开始对此数据进行压缩的日期和时间。 如果加密了中心目录并且设置了通用位标志13以表示屏蔽，则存储在本地头中的值将为零。 MS-DOS时间格式不同于计算机常用的时间格式，例如UTC。 例如，MS-DOS使用相对于1980年和2秒精度的年份值。

2.4.7、CRC-32 (4 bytes)

  CRC-32算法由David Schwaderer慷慨贡献，可以在他的出色著作《 NetBIOS C程序员指南》中找到，该书由Howard W. Sams＆Co. Inc.发行。CRC的“Magic Number”为0xDEBB20E3。使用了适当的CRC预处理和后处理，这意味着所有CRC寄存器被预处理了(起始值为0xFFFFFFFF)，并且该值通过对CRC残差进行补码来进行后处理。如果设置了通用位标志的第3位，则该字段在本地头中设置为零，并将正确的值放在数据描述符和中心目录中。加密中心目录时，如果本地头不是ZIP64格式，并且设置了通用位标志13以表示屏蔽，则本地头中存储的值将为零。

2.4.8、压缩文件的大小(Compressed size) (4 bytes)

2.4.9、未压缩文件的大小(Uncompressed size) (4 bytes)

  压缩文件的大小(2.4.8)和未压缩文件的大小(2.4.9)。存在解密头时，它将被放置在文件数据的前面，并且压缩文件大小的值将包括解密头的字节。如果设置了通用位标志的位3，则这些字段在本地头中设置为零，并且正确的值放在数据描述符和中心目录中。如果压缩文件为ZIP64格式，并且此字段中的值为0xFFFFFFFF，则大小将在相应的8字节ZIP64扩展信息扩展字段中。当加密中心目录时，如果本地头不是ZIP64格式，并且设置了通用位标志的位13以表示屏蔽，则在本地头中为未压缩文件大小存储的值将为零。

2.4.10、文件名长度(File name length) (2 bytes)

2.4.11、扩展区域长度(Extra field length) (2 bytes)

2.4.12、文件注释长度(File comment length) (2 bytes)

  文件名，扩展区域字段和文件注释字段的长度。任何目录记录和这三个字段的合计长度通常不应超过65535个字节。如果输入来自标准输入，则文件名长度设置为零。

2.4.13、文件开始位置所在的磁盘编号(Disk number start) (2 bytes)

  该文件开始所在的磁盘编号。如果压缩文件为ZIP64格式，并且此字段中的值为0xFFFF，则此字段将在相应的4字节ZIP64扩展信息扩展字段中。

2.4.14、内部文件属性(Internal file attributes) (2 bytes)

  位1和位2保留供PKWARE使用。
  如果设置该字段的最低位，则表明该文件显然是ASCII或文本文件。 如果未设置，则该文件显然包含二进制数据。其余位在1.0版中未使用。
  如果设置了此字段的0x0002位，则表示每个逻辑记录之前都有4字节可变记录长度控制字段，指示记录的长度。 记录长度控制字段以小端字节序存储。 该标志独立于文本控制字符，并且如果与文本数据一起使用，则在记录的总长度中包括所有控制字符。 提供此值是为了支持大型数据传输。

2.4.15、外部文件属性(External file attributes) (4 bytes)

  外部属性的映射取决于主机系统(请参阅“Version made by”)。对于MS-DOS，低位字节是MS-DOS目录属性字节。如果输入来自标准输入，则此字段设置为0。

2.4.16、本地文件头的相对偏移(Relative offset of local header) (4 bytes)

  这是从此文件出现的第一个磁盘的开始到本地头的偏移量。 如果压缩文件为ZIP64格式，并且此字段中的值为0xFFFFFFFF，则此字段将在相应的8字节ZIP64扩展信息扩展字段中。

2.4.17、文件名(File name) (N bytes)

  文件名，带有可选的相对路径。存储的路径不得包含驱动器或设备字母或前导斜杠。为了与Amiga和UNIX文件系统兼容，所有斜杠必须为正斜杠“/”，而不是反斜杠“\”。如果输入来自标准输入，则没有文件名字段。
  如果使用中心目录加密功能，并且设置了通用位标志的位13以表示屏蔽，则存储在本地头中的文件名将不是实际的文件名。将存储由唯一的十六进制值组成的掩码值。对于压缩文件中的每个文件，此值将按顺序递增。有关检索加密文件名的详细信息，请参见“强加密规范”部分。

2.4.18、文件注释(File comment) (N bytes)

  此压缩文件的注释。

2.4.19、当前磁盘号(Number of this disk) (2 bytes)

  当前磁盘的编号，其中包含中心目录结束记录。 如果压缩文件为ZIP64格式，并且此字段中的值为0xFFFF，则此字段将在相应的4字节的ZIP64中心目录结束记录中。

2.4.20、中心目录开头所在的磁盘号(Number of the disk with the start of the central directory) (2 bytes)

  中心目录开头所在的磁盘号。 如果压缩文件为ZIP64格式，并且此字段中的值为0xFFFF，则此字段将在相应的4字节的ZIP64中心目录结束记录中。

2.4.21、该磁盘上中心目录的条目总数(Total number of entries in the central directory on this disk) (2 bytes)

  该磁盘上中心目录的条目总数。如果压缩文件为ZIP64格式，并且此字段中的值为0xFFFF，则此字段将在相应的8字节的ZIP64中心目录结束记录中。

2.4.22、中心目录的条目总数(Total number of entries in the central directory) (2 bytes)

  ZIP文件中的文件总数。如果压缩文件为ZIP64格式，并且此字段中的值为0xFFFF，则此字段将在相应的8字节的ZIP64中心目录结束记录中。

2.4.23、中心目录的大小(Size of the central directory) (4 bytes)

  整个中央目录的大小(以字节为单位)。 如果压缩文件为ZIP64格式，并且此字段中的值为0xFFFFFFFF，则此字段将在相应的8字节的ZIP64中心目录结束记录中。

2.4.24、中心目录开始位置相对于压缩文档开始位置的偏移(Offset of start of central directory with respect to the starting disk number) (4 bytes)

  中心目录开始位置相对于压缩文档开始位置的偏移。如果压缩文件为ZIP64格式，并且此字段中的值为0xFFFFFFFF，则此字段将在相应的8字节的ZIP64中心目录结束记录中。

2.4.25、.ZIP文件注释长度(.ZIP file comment length) (2 bytes)

  此.ZIP文件的注释长度。

2.4.26、.ZIP文件注释(.ZIP file comment) (N bytes)

  此.ZIP文件的注释。ZIP文件注释数据不安全地存储。目前没有加密或数据认证应用于此区域。机密信息不应存储在本节中。

2.4.27、ZIP64扩展数据段(ZIP64 extensible data sector) (N bytes)

  目前保留供PKWARE使用。

2.4.28、扩展区域(Extra field) (N bytes)

  在中心目录头(Central directory header)中。
  这应该被用于存储扩展。如果出于特殊应用或平台的需要，需要在ZIP文件中存储其他信息，则应将其存储在此处。然后，支持该规范较早版本的程序可以安全地跳过这个文件，并找到下一个文件或头。在1.0版中，该字段的长度为0。
  现有的扩展字段在随后的“可扩展数据字段(Extensible data fields)”部分中定义。

2.5、可扩展的数据字段(Extensible data fields)

  为了允许将不同的程序和不同类型的信息存储在.ZIP文件的“扩展”字段中，对于在此字段中存储数据的所有程序，必须使用以下结构：

1

header1 + data1 + header2 + data2 . . .

每个头必须包括：

注意：所有字段以Intel低字节/高字节顺序(小端字节序)存储。

头ID字段指示随后的数据块中数据的数据类型。
头ID的0到31保留供PKWARE使用。其余的ID可以由第三方供应商用于专有用途。

PKWARE定义的当前头ID的映射为：

• 0x0001 - Zip64 extended information extra field：ZIP64扩展信息扩展字段。
• 0x0007 - AV Info：AV信息。
• 0x0008 - Reserved for extended language encoding data (PFS)(see APPENDIX D)：保留用于扩展语言编码数据(PFS)（请参阅附录D）
• 0x0009 - OS/2
• 0x000A - NTFS
• 0x000C - OpenVMS
• 0x000D - UNIX
• 0x000E - Reserved for file stream and fork descriptors：保留用于文件流和派生描述符。
• 0x000F - Patch Descriptor：补丁描述符。
• 0x0014 - PKCS#7 Store for X.509 Certificates：X.509证书的PKCS#7存储。
• 0x0015 - X.509 Certificate ID and Signature for individual file：X.509证书ID和单个文件的签名。
• 0x0016 - X.509 Certificate ID for Central Directory：中心目录的X.509证书ID。
• 0x0017 - Strong Encryption Header：强加密头。
• 0x0018 - Record Management Controls：记录管理控制。
• 0x0019 - PKCS#7 Encryption Recipient Certificate List：PKCS#7加密对象证书列表。
• 0x0020 - Reserved for Timestamp record：为Timestamp记录保留。
• 0x0021 - Policy Decryption Key Record：策略解密密钥记录。
• 0x0022 - Smartcrypt Key Provider Record：Smartcrypt密钥提供者记录。
• 0x0023 - Smartcrypt Policy Key Data Record：Smartcrypt策略密钥数据记录。
• 0x0065 - IBM S/390 (Z390), AS/400 (I400) attributes - uncompressed：IBM S/390 (Z390), AS/400 (I400)属性 - 未压缩。
• 0x0066 - Reserved for IBM S/390 (Z390), AS/400 (I400) attributes - compressed：为IBM S/390 (Z390), AS/400 (I400)属性保留 - 压缩。
• 0x4690 - POSZIP 4690 (reserved)：POSZIP 4690(保留)。

2.5.1、-ZIP64扩展信息扩展字段(ZIP64 Extended Information Extra Field)(0x0001)

  以下是ZIP64扩展信息扩展块的布局。如果本地或中心目录记录中的大小或偏移量字段之一太小而无法容纳所需的数据，则将创建一个ZIP64扩展信息记录。ZIP64扩展信息记录中字段的顺序是固定的，但是该字段必须仅在相应的本地或中心目录记录字段设置为0xFFFF或0xFFFFFFFF时显示。

注意：所有字段以Intel低字节/高字节顺序(小端字节序)存储。

  本地头中的此项必须包含原始和压缩文件大小字段。如果对中心目录进行加密并且设置了通用位标志的第13位以指示屏蔽，则存储在本地头中的原始文件大小的值将为0。

2.5.2、-OS/2扩展字段(-OS/2 Extra Field)(0x0009)

以下是OS/2属性“扩展”块的布局。( 最新修订日期为09/05/95)

注意：所有字段以Intel低字节/高字节顺序(小端字节序)存储。

  压缩OS/2扩展属性结构(FEA2LIST)，然后将其完整存储在此结构中。 VarFields[]中将永远只有一个“块”数据。

2.5.3、-NTFS扩展字段(-NTFS Extra Field)(0x000A)

  以下是NTFS属性“扩展”块的布局。( 注意：目前，Mtime，Atime和Ctime值可以在任何WIN32系统上使用。)

注意：所有字段以Intel低字节/高字节顺序(小端字节序)存储。

对于NTFS，Tag1到TagN的值如下：(当前仅为NTFS定义了一组属性)

2.5.4、-OpenVMS扩展字段(-OpenVMS Extra Field)(0x000C)

以下是OpenVMS属性“扩展”块的布局。

注意：所有字段以Intel低字节/高字节顺序(小端字节序)存储。

OpenVMS扩展字段规则：
  将存在一个或多个属性，每个属性之前都带有上述TagX和SizeX值。 这些值与在OpenVMS C下的ATR.H中定义的ATR$C_XXXX和ATR$S_XXXX常数相同。这两个值都不为0。
  不执行字对齐或填充。
  行为良好的PKZIP/OpenVMS程序不应产生具有相同TagX值的多个子块。 另外，在特定的目录记录中，不得存在多个0x000C类型的“扩展”块。

2.5.5、-UNIX扩展字段(-UNIX Extra Field)(0x000D)

以下是UNIX“扩展”块的布局。

注意：所有字段以Intel低字节/高字节顺序(小端字节序)存储。

  可变长度数据字段将包含特定于文件类型的数据。当前，唯一允许的值为硬链接或符号链接“链接到”的原始文件名，以及字符和块设备节点的主要和次要设备节点号。由于设备节点不能是符号链接或硬链接，因此仅存储一组可变长度数据。链接文件将具有存储的原始文件的名称。此名称不是以NULL终止的。可以通过检查TSize -12来确定其大小。设备条目将有8个字节存储为两个4字节条目(采用小端序格式)。第一个条目将是主设备号，第二个条目是次设备号。

2.5.6、-PATCH描述符扩展字段(-PATCH Descriptor Extra Field)(0x000F)

以下是PATCH描述符“扩展”块的布局。

注意：所有字段以Intel低字节/高字节顺序(小端字节序)存储。

Actions和reactions：

Actions：

reactions：

  补丁程序支持是由PKPatchMaker(tm)技术提供的，并受美国专利和正在审理的专利保护。在产品中使用或实现当前附录中规定的某些技术方面(包括与强加密或补丁相关的方面)需要获得PKWARE的许可。

2.5.7、-X.509证书的PKCS#7存储(-PKCS#7 Store for X.509 Certificates)(0x0014)

  该字段必须包含有关可以用来签名的每个证书文件的信息。当为ZIP文件启用中心目录加密功能时，该记录将出现在“压缩文档扩展数据记录(Archive extra data record)”中，否则将出现在第一个中心目录记录中，而在任何其他记录中将被忽略。

注意：所有字段以Intel低字节/高字节顺序(小端字节序)存储。

2.5.8、-X.509证书ID和单个文件的签名(-X.509 Certificate ID and Signature for individual file)(0x0015)

  此字段包含有关使用PKCS#7存储中的哪个证书对特定文件进行签名的信息。它还包含签名数据。该字段可以出现多次，但每个证书只能出现一次。

注意：所有字段以Intel低字节/高字节顺序(小端字节序)存储。

2.5.9、-X.509证书ID和中心目录签名(-X.509 Certificate ID and Signature for central directory)(0x0016)

  此字段包含有关使用PKCS#7存储中的哪个证书来签名中心目录结构的信息。当为ZIP文件启用中心目录加密功能时，该记录将显示在“压缩文档扩展数据记录(Archive extra data record)”中，否则将出现在第一个中心目录记录中。

注意：所有字段以Intel低字节/高字节顺序(小端字节序)存储。

2.5.10、-强加密头(-Strong Encryption Header)(0x0017)

有关详细信息，请参见描述强加密规范的部分。

2.5.11、-记录管理控制(-Record Management Controls)(0x0018)

2.5.12、-PKCS＃7加密接受者证书列表(-PKCS#7 Encryption Recipient Certificate List)(0x0019)

  该字段可以包含有关加密处理中使用的每个证书的信息，并且可以用来识别允许谁解密加密文件。 该字段仅应出现在“压缩文档扩展数据记录(Archive extra data record)”中。 该字段不是必填字段，仅用于通过保留公共加密密钥数据来帮助压缩文档修改。 个别安全要求可能会要求省略此数据以阻止信息泄露。

注意：所有字段以Intel低字节/高字节顺序(小端字节序)存储。

TData:

  有关详细信息，请参见描述强加密规范的部分。

2.5.13、-MVS扩展字段(-MVS Extra Field)(0x0065)

以下是MVS扩展字段的布局。
注意:某些字段以大端格式存储。

2.5.14、-OS/400扩展字段(-OS/400 Extra Field)(0x0065)

以下是OS/400扩展字段的布局。
注意:某些字段以大端格式存储。
除非另有说明，否则所有文本均为EBCDIC格式。

2.5.15、-策略解密密钥记录扩展字段(-Policy Decryption Key Record Extra Field)(0x0021)

  以下是策略解密密钥扩展块的布局。TData是可变长度，可变内容字段。它包含有关加密和/或加密密钥源的信息。有关当前TData结构的信息，请与PKWARE联系。此扩展块中的信息也可以放在注释字段中。

2.5.16、-密钥提供者记录扩展字段(-Key Provider Record Extra Field)(0x0022)

  以下是密钥提供者扩展块的布局。TData是可变长度，可变内容字段。 它包含有关加密和/或加密密钥源的信息。有关当前TData结构的信息，请与PKWARE联系。此扩展块中的信息也可以放在注释字段中。

2.5.17、-策略密钥数据记录记录扩展字段(-Policy Key Data Record Record Extra Field)(0x0023)

  以下是策略密钥数据扩展块的布局。TData是可变长度，可变内容字段。它包含有关加密和/或加密密钥源的信息。有关当前TData结构的信息，请与PKWARE联系。此扩展块中的信息也可以放在注释字段中。

参考文献

[1] 官方文档 - APPNOTE-6.3.6.TXT