ZIP格式

.ZIP文件格式是由库尔德工人党的菲利普•卡兹创建的。在PKWARE被系统增强协会（SEA）起诉后，他创建了该格式并声称他的存档产品名为PKARC，是SEA的 ARC存档系统的衍生产品。^[2] “zip”这个名字（意思是“高速移动”）是由卡茨的朋友罗伯特•马奥尼提出的。他们想暗示他们的产品将比ARC和当时的其他压缩格式更快。已知的.ZIP文件格式规范最早版本最初是在1989年作为文件APPNOTE.TXT下的PKZIP 0.9包的一部分发布的。通过在APPNOTE.TXT中分发zip文件格式。20世纪90年代，ZIP文件格式的兼容性在公共互联网上广泛传播。^[3]。

.ZIP文件格式于1989年发布到公共领域。^{[4][5][6][7][8]}

1.1 版本历史

.ZIP文件格式规范有自己的版本号，它不一定对应于PKZIP工具的版本号，尤其是PKZIP 6或更高版本。PKWARE在不同时间增加了一些初步的特性，允许PKZIP产品使用高级特性提取归档，但是创建这种归档的PKZIP产品直到下一个主要版本才可用。其他公司或组织按照自己的步伐支持PKWARE规范。

.ZIP文件格式规范正式命名为“APPNOTE -.ZIP文件格式规范”，自20世纪90年代末在PKWARE.com网站上发布。^[9] 该规范的几个版本尚未发布。某些功能的规格如BZIP2压缩、强加密规范和其他一些东西在创建几年后由PKWARE发布。BZIP2压缩、强加密规范等一些特性的规范在创建几年后由PKWARE发布。在线规范的网址在PKWARE网站上被更改了数次。

PKWARE规范各种版本的主要进展概述：

2.0： （1993）^[1]文件条目可以用DEFLATE压缩，并使用传统的PKWARE加密

2.1： （1996） Deflate64压缩

4.5： （2001）^[10]文档的64位压缩格式

4.6： （2001） BZIP2压缩（在APPNOTE 5.2发布之前不会在线发布）

5.0： （2002年） DES, Triple DES ,RC4 RC2支持加密（在APPNOTE 5.2发布之前不会在线发布）

5.2： （2003）^{[11] [12]}AES加密支持（定义在APPNOTE 5.1中，未在线发布），支持加密的RC2-64的修正版本

6.1： （2004）^[13]文档化证书存储

6.2.0： （2004）^[14]文档中央目录加密

6.3.0： （2006）^[15]文档化的Unicode （UTF-8）文件名存储。支持散列、压缩（LZMA、PPMd+）、加密算法的扩展列表

6.3.1： （2007）^[16]修正了SHA-256/384/512的标准哈希值

6.3.2： （2007）^[17]文档压缩方法97 （WavPack）

6.3.3： （2012）^[18]根据JTC 1/SC 34 N 1621的指示，使用JTC 1参考解释性报告（RER）等方法，对文档格式进行更改，以方便参考其他标准的PKWARE应用笔记

6.3.4： （2014）^[19]更新PKWARE公司的办公地址

6.3.5： （2018）^[20]已记录的压缩方法16、96和99，DOS时间戳时期和精度，增加了密钥和解密的额外字段，以及打字错误和说明

WinZip从12.1版开始，使用扩展。zipx用于压缩方法比DEFLATE更新的ZIP文件；具体来说，BZip方法，LZMA，PPMd，Jpeg和Wavpack。当选择“最佳方法”压缩时，后两个应用于适当的文件类型。^[21][22]

1.2 标准化

2010年4月，ISO/IEC JTC 1号发起了一场投票，以确定是否应发起一个项目，创建一个与ZIP兼容的ISO/IEC国际标准ZIP格式。拟议的项目名为“文档打包”，设想了一种与ZIP兼容的“最小压缩归档格式”，适用于许多现有标准，包括开放文档、Office Open XML和EPUB。

2015年，ISO/IEC 21320-1“文档容器文件——第1部分：核心”发布，声明“文档容器文件符合ZIP文件标准”。^[23]

conforming 21320-1：2015年，要求ZIP文件格式有以下主要限制：

• ZIP归档中的文件只能以未压缩的方式存储，或者使用“deflate”压缩（即压缩方法可能包含存储的“0”或压缩后的“8”）。
• 加密功能是禁止的。
• 禁止使用数字签名功能。
• 禁止使用“修补数据”功能。
• 归档不能跨多个卷或分段。

1.3 设计

.ZIP文件是存储多个文件的归档。ZIP允许使用许多不同的方法压缩包含的文件，以及简单地存储文件而不压缩。每个文件单独存储，允许使用不同的方法压缩同一归档中的不同文件。因为ZIP归档中的文件是单独压缩的，所以可以单独提取这些文件，或者添加新的文件，而无需对整个归档进行压缩或解压缩。这种方式与压缩后的tar文件的格式形成了对比，对于压缩tar文件，这种随机访问处理是不容易实现的。

目录位于ZIP文件的末尾。目录能标识ZIP中有哪些文件，并标识该文件在ZIP中的位置。这就允许ZIP阅读器在不读取整个ZIP归档的情况下加载文件列表。ZIP归档还可以包括与ZIP归档无关的额外数据。这允许通过将程序代码添加到ZIP归档并将文件标记为可执行文件，将ZIP归档制作成自解压归档（解压包含的数据的应用程序）。将目录存储在末尾还可以通过将ZIP文件附加到无害的文件（如GIF图像文件）中来隐藏该文件。

.ZIP格式使用32位循环冗余校验算法，并包含归档目录结构的两个副本，以提供更好的数据丢失保护。

1.4 结构

ZIP文件通过中央目录记录的末端（位于归档结构末端）进行正确识别，以便于附加新文件。如果中央目录记录的结尾指示为一个非空归档，则归档中的每个文件或目录的名称、关于条目的其他元数据和指向实际条目数据的ZIP文件的偏移量都应在中央目录条目中指定。这允许相对快速地执行归档文件列表，因为不必读取整个归档文件来查看文件列表。ZIP文件中的条目也包括这个信息，为了冗余保存在在本地文件头中。由于ZIP文件可以被附加到其他ZIP文件中，所以只有在文件末尾的中央目录中指定的文件才有效。扫描ZIP文件的本地文件头是无效的（损坏的归档除外），因为中央目录可能会声明某些文件已被删除，而其他文件已被更新。

例如，我们可以从包含文件A、B、C的ZIP文件开始，然后删除文件B，更新文件C。这可以通过在原始ZIP文件的末尾添加一个新的文件C，并添加一个只列出文件A和新文件C的新的中央目录来实现。ZIP最初被设计时，通过软盘传输文件是常见的，但是写入磁盘非常耗时。如果你有一个很大的zip文件（可能跨越多个磁盘）并且只需要更新几个文件而不需要读取和重写所有文件，那么只读取旧的中央目录、添加新文件再添加更新的中央目录，这样会快得多。

中央目录中文件条目的顺序不需要与归档中文件条目的顺序一致。

ZIP归档中存储的每个条目都由本地文件头引入，该文件头包含有关文件的信息，如注释、文件大小和文件名，后面是可选的“额外”数据字段，然后是可能压缩或加密的文件数据。“Extra”数据字段是ZIP格式可扩展性的关键。“Extra”字段被用来支持ZIP64格式、WinZip兼容的AES加密、文件属性和更高分辨率的NTFS或Unix文件时间戳。通过“Extra”字段可以进行其他扩展。规范要求压缩工具忽略无法识别的额外字段。

ZIP格式使用特定的4字节“签名”来表示文件中的各种结构。每个文件条目都有一个特定的签名。中央目录记录的结尾用其特定的签名表示，中央目录中的每个条目都以4字节的中央文件头签名开始。

ZIP规范中没有BOF或EOF标记。按照惯例，ZIP文件中的第一要务是ZIP条目，ZIP条目可以通过本地文件头签名很容易地识别出来。然而情况并不一定如此，因为ZIP规范并不要求这样做——特别是自解压存档将从可执行文件头开始。

正确读取ZIP归档的工具必须扫描中央目录记录签名的结尾，然后在适当时扫描另一个指定的中央目录记录。他们不能从ZIP文件的顶部扫描条目，因为（如本节前面提到的）只有中央目录指定文件块的起始位置，并且没有被删除。扫描可能会导致误报，因为该格式不禁止块之间存在其他数据，也不禁止文件数据流包含此类签名。但是，试图从损坏的ZIP归档中恢复数据的工具很可能会扫描归档中的本地文件头签名；由于文件块的压缩大小可能存储在文件块之后，顺序处理就变得更加困难。

大多数签名以短整数0x4b50结尾，该整数以小端顺序存储。该签名结尾被视为一个ASCII字符串“PK”，是发明者菲利普·卡兹（Phil Katz）的首字母。因此，当在文本编辑器中查看ZIP时，文件的前两个字节通常是“PK”。（DOS、OS/2和Windows自解压ZIP在ZIP文件之前有一个附件，所以文件开头为“MZ”；其他操作系统的自解压ZIP之前也可以有类似的可执行代码，用于在该平台上解压归档的内容。）

.ZIP规范还支持跨多个文件系统文件传播归档。该功能最初用于跨多个软盘存储大型ZIP文件，现在用于通过电子邮件、其他传输方式或可移动介质发送ZIP归档。

DOS的FAT文件系统只有两秒钟的时间戳分辨率；ZIP文件记录模拟了这一点。因此，ZIP归档中文件的内置时间戳分辨率只有两秒，不过可以使用额外的字段来存储更精确的时间戳。ZIP格式没有时区的概念，所以时间戳只有在知道是在哪个时区创建的情况下才有意义。

2007年9月，PKWARE发布了ZIP规范的修订版，提供了使用UTF-8存储文件名的功能，最终为ZIP添加了Unicode兼容性。^[24]

1.5 文件头

报头中的所有多字节值都以小端顺序存储。所有长度字段都以字节为单位计算长度。

本地文件头

额外字段包含各种可选数据，例如操作系统特定的属性。额外字段被分成多个块，每个块都有16位的识别码和16位的长度。紧接着是压缩数据。

数据描述符

如果通用标志字段的偏移量3 （0x08）处的位被置位，则在写入文件头部时不知道CRC-32和文件大小。本地报头中的字段用零填充，并且在压缩数据之后立即以12字节的结构（可选在4字节签名之前）附加CRC-32和大小：^[24]

中央目录文件头

中央目录条目是本地标题的扩展形式：

中央目录记录的结尾（EOCD）

在所有中央目录条目之后，中央目录（EOCD）记录结束，这标志着ZIP文件的结束：

这种排序允许一次创建一个ZIP文件，但是中央目录也位于文件的末尾，以便于从多个部分（例如，“多个软盘”）归档中简单地移除文件，如前所述。

1.6 压缩方法

.ZIP文件格式规范记录了以下压缩方法：存储（无压缩）、Shrink、Reduce（1-4级）、Implode、Deflate、Deflate64、bzip2、LZMA （EFS）、WavPack和PPMd^[25]。

最常用的压缩方法是DEFLATE，这在IETF RFC 1951中有所描述。

压缩方法被提到过，但没有在规范中详细记录，包括：PKWARE数据压缩库（DCL）Implode、IBM TERSE和IBM LZ77 z架构（PFS）。“令牌化”方法是为第三方保留的，但从未添加支持。

1.7 加密

ZIP支持一个简单的基于密码的对称加密系统，该系统在ZIP规范中有文档说明，并且已知存在严重缺陷。特别是容易受到已知明文攻击，在某些情况下，由于随机数生成器的不良实现而变得更糟。^[3]

自5.2版以来，ZIP文件格式规范中记录了包括新压缩和加密（例如AES）方法在内的新功能。7-Zip和Xceed也使用WinZip开发的基于AES的标准，但是一些供应商使用其他格式。PKWARE SecureZIP还支持RC2、RC4、DES、三重DES加密方法、基于数字证书的加密和验证（X.509）以及归档头加密。^[26]

文件名加密在.ZIP文件格式规范6.2中采用并加密存储在归档文件中央目录部分的元数据，但本地标题部分仍不加密。兼容归档程序在使用中央目录加密时会伪造本地标头数据。截至规范的6.2版，本地报头中的压缩方法和压缩大小字段尚未被屏蔽。

1.8 ZIP64

原.ZIP格式对各种内容（文件的未压缩大小、文件的压缩大小和归档的总大小）有4 GiB （2³²字节）的限制，ZIP归档中的条目限制为65，535 （2¹⁶）个。在规范的4.5版（与任何特定工具的4.5版不同）中，PKWARE引入了“ZIP64”格式扩展来规避这些限制，将限制提高到16 EiB （2⁶⁴ 字节）。本质上，ZIP64使用一个文件的“普通”中央目录条目，后面是一个可选的具有更大字段的“zip64”目录条目。^[27]

Windows XP中的文件浏览器不支持ZIP64，但WindowsVista和更高版本中的浏览器支持。同样，一些扩展库支持ZIP64，如Perl中的DotNetZip、QuaZIP和IO::Compress::Zip。Python的内置zipfile从2.5开始支持ZIP64，从3.4开始将ZIP64作为默认压缩格式。^[28] OpenJDK的内置java.util.zip从Java 7版本开始支持ZIP64。^[29]自安卓6.0以来，安卓JAVA API从安卓6.0起支持ZIP64。^[30] Mac OS操作系统Sierra的归档实用程序明显不支持ZIZ64，并且在需要使用ZIZ64时会创建损坏的归档。^[31] 然而，Mac OS操作系统附带的ditto命令将会解压ZIP64文件^[32]。最新版本的Mac OS操作系统附带了支持ZI64的压缩和解压缩命令行工具：可以通过运行zip -v命令进行验证或者查找“ZIP64 _ SUPPORT”。

1.9 与其他文件格式的组合

.ZIP文件格式允许在中央目录之后的文件末尾出现最多包含65,535（2¹⁶-1）字节数据的注释。^[24] 此外，因为中央目录指定了归档文件中每个文件相对于起始位置的偏移量，所以第一个文件条目可以从零以外的偏移量开始，尽管某些工具（例如gzip）不会处理不以偏移量零开始的归档文件。

这允许在压缩归档数据之前和之后的文件中出现任意数据，并且ZIP应用程序仍然可以读取归档。这样做的一个副作用是，如果另一种格式允许任意数据在其结尾、开头或中间，就可以创建一个既可以工作的ZIP归档又可以使用的文件。WinZip支持的自解压归档（SFX）利用了这一点，因为SFX是可执行的（.exe）符合PKZIP AppNote.txt规范的文件，并且可以被兼容的ZIP工具或库读取。

.ZIP格式和JAR格式（ZIP的变体）的这个属性可以被利用来隐藏看似无害的文件中的流氓内容（例如有害的Java类），例如上传到网络的GIF图像。这种所谓的GIFAR漏洞已被证明是对Facebook等网络应用程序的有效攻击。^[33]

1.10 限制

. ZIP文件的最小大小是22字节。这样的空zip文件只包含中央目录记录的结尾（EOCD）：

[0x50,0x4B,0x05,0x06,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00]

标准ZIP的归档文件和其中的单个文件的最大大小为4,294,967,295字节（2³²-1字节，或4 GiB减去1字节）。对于ZIP64，最大大小为18,446,744,073,709,551,615字节（2⁶⁴ -1字节，或16 EiB减去1字节）。^[34]

1.11 专有扩展

额外字段

.ZIP文件格式在文件头中包含一个额外的字段功能，可用于存储现有ZIP规范未定义的额外数据，并允许不识别字段的兼容归档程序安全跳过这些字段。文件头标识 0–31保留给PKWARE使用。剩余的标识可以被第三方供应商用于专有用途。

加密争议

当WinZip 9.0公开测试版在2003年发布时，WinZip引入了自己的AES-256加密，使用了不同的文件格式，以及新规范的文档。^[35] 加密标准本身不是专有的，但是PKWARE没有更新APPNOTE.TXT包括自2001年以来的强加密规范，该规范已被PKZIP版本5.0和6.0使用。WinZip技术顾问凯文·卡尼（Kevin Kearney）和StuffIt产品经理马修·科温顿（Mathew Covington）指控PKWARE扣压SES，但PKZIP首席技术官吉姆·彼得森声称基于证书的加密仍然不完整。

在另一个有争议的举动中，PKWare于2003年7月16日申请了一项专利，描述了一种将压缩和强加密相结合来创建安全文件的方法。^[36]

最终，PKWARE和WinZip同意支持彼此的产品。2004年1月21日，PKWARE宣布支持基于WinZip的AES压缩格式。^[37] 在WinZip测试版的较高版本中能够支持基于SES的Zip文件。PKWARE最终向公众发布了Zip文件格式规范5.2版，其中记录了SES。自由软件项目7-Zip也支持ZIP文件中的AES加密（和它的POSIX移植版本p7zip一样）。

在WinZip下使用AES加密时，压缩方法始终被设置为99，实际压缩方法存储在AES额外数据字段中。^[38] 相反，强加密规范将压缩方法存储在本地头和中央目录的基本文件头字段中，除非中央目录加密用于屏蔽/加密元数据。

有成千上万可用的.ZIP工具和适用于各种编程环境的ZIP库；使用的许可证包括专有软件和自由软件。WinZip、WinRAR、Info-ZIP、7-Zip、PeaZip和B1Free Archiver是众所周知的.ZIP工具，可在各种平台上使用。其中一些工具有库或编程接口。

在开源协议下授权的一些开发库是libzip和Info-ZIP。对于Java:Java平台，标准版包含处理标准.ZIP文件的包“java.util.zip”；Zip 64文件库专门支持大文件（大于4 GB）并对ZIP文件使用随机存取；Apache Ant工具包含一个在Apache软件许可证下发布的更完整的实现。

.ZIP格式的信息压缩实现增加了对Unix文件系统功能的支持，例如用户和组标识、文件权限以及对符号链接的支持。Apache Ant的实现意识到了这些功能并可以创建具有预定义Unix权限的文件。信息压缩实现还知道如何使用内置于.ZIP压缩格式中的错误修正功能。有些程序不具有此功能并会在有错误的文件上失效。

Windows信息压缩工具也支持NTFS文件系统权限，并且在提取文件时会尝试将NTFS权限转换为Unix权限，反之亦然。这可能导致潜在的意想不到的组合。例如，在NTFS卷上创建的.exe文件不具有可执行权限。

自从Microsoft Plus!包发布于Window98，微软Windows的各版本已经包含对浏览.ZIP压缩文件的支持。微软称此功能为“压缩文件夹”。Windows压缩文件夹功能并不支持全部的ZIP特性。例如，在Windows7之前，不支持Unicode项目编码，而压缩文件夹功能不支持读写和分割和跨区归档，也不支持AES加密。

^[39]

微软办公室在2006年开始使用ZIP归档格式作为他们的Office Open XML .docx、。xlsx，.pptx等文件，这是Microsoft Office 2007的默认文件格式。

还有许多其他标准和格式使用“zip”作为其名称的一部分。例如，zip不同于gzip，后者是在IETF RFC （RFC 1952）中定义的。zip和gzip都主要使用DEFLATE算法进行压缩。同样，ZLIB格式（IETF RFC 1950）也使用DEFLATE压缩算法，但是为错误和一致性检查指定了不同的报头。其他常见的命名格式相似和具有不同本机格式的程序包括7-Zip、bzip2和rzip。