【译】Apk签名方案基础之Zip格式
一、结构
位于归档文件结尾的中央目录记录的结尾标示了一个压缩文件，也方便了新文件地添加。如果中央目录记录的结尾如果指向一个非空归档文件，归档文件内每一个文件或目录的名字都应该在中央目录条目中被指定，同时由一些关于条目的元数据，偏移位置，指示真实条目数据。这允许可以相对快速地执行归档文件的文件清单，因为不需要通过读取整个归档文件来获取文件列表。压缩文件内的条目也包含这些信息，出于冗余处理目的，也存在于本地文件头。因为压缩文件可会追加新文件，只有在文件结尾中央目录内指定的文件才是有效地。只是扫描压缩文件本地文件头是无效地，因为中央目录可能会声明一些文件已经被删除或者更新。
举个例子，在一个压缩文件内存在文件A，B，C，如果需要删除文件B删除，更新文件C，那么只需要在压缩文件结尾新增文件C，并且新增仅仅列出文件A和文件C的中央文件目录。在首次设计zip文件时，通常使用软盘转移文件，写操作相当耗时。如果你有一个很大的zip文件，通常需要扫描多个磁盘，却只需要更新几个文件，而不是读取重写所有文件，读取旧的中央目录，新增文件更新中央目录会很很多。
中央目录内文件条目顺序并不合归档文件内文件顺序一致。
在本地文件头内会有关于zip归档文件内每个文件的信息，比如注解，文件大小和文件名。之后是扩展字段，可能会有压缩数据或加密数据。扩展字段是zip文件格式扩展性的关键，支持zip64格式，WinZip-compatible AES加密，文件属性，higher-resolution NTFS 或者 Unix 文件时间戳。其他扩展属性也可能通过扩展字段实现。按照规范，如果zip工具无法识别扩展字段则会忽略。
zip格式使用指定4字节签名来标示各种文件结构。每个文件都通过一个指定签名做区分。中央目录结尾应该由特别签名表示。中央目录内每个条目都由4字节中央文件头签名开始。
在zip规范中没有BOF或者EOF标记。按照惯例，zip文件内是第一个文件是一个zip条目。这个可以被本地文件头签名轻松区分。这不是必须的，因为在zip规范中没有指定。最显著地是，一个自提取归档文件忽悠一个可执行文件头。
工具要正确读取zip归档必须要读取中央目录记录尾部签名，然后获取中央目录。不应该从zip文件头部开始扫描所有文件条目，因为只有中央目录表面了一个没有被删除的文件块的起始位置。扫描会导致负面的效果，因为格式并没有禁止在文件块之间存入其他数据，也没有说文件数据流不能包含签名。然而，当工具尝试去受损的归档文件内恢复数据就很有可能扫描归档文件获取本地文件头签名，但是更加困难地是，将文件压缩大小存储在文件块末尾可能会使后续处理更加困难。
大多数签名都是由短整形0x4b50结尾，以小端顺序存储，作为ASCII字符串则是"PK"，意为Phil Katz。因此，当zip文件在文本编辑器中查看时，文件的头两个字节就是"PK"，zip规范也支持在多文件系统张使用。原来使用多张软盘来存储大zip文件。现在在发送邮件时，这个功能可以发送归档文件的一部分，或者使可传输或卸载的多媒体工具。
Dos Fat 文件系统的时间戳分辨率是两秒，zip文件记录模仿了这个做法。作为结果，zip归档内文件的内置时间解析采用2秒，不过扩展字段可以提供更加精确地时间戳。zip格式没有时区的概念，所以时间戳只有在已知创建时所用的时区才是有意义的。
在2017年9月份，PKWARE发布了一个zip规范版本用来存储utf-8编码地文件名字符串，最后在zip上添加Unicode兼容性。
二、文件头
用小端字节序在头部存储了多个字节值，所有length字段都以字节为单位计算长度。
Xnip2019-05-19_14-50-04.jpg
扩展字段可以包含任何可选的数据，比如系统指定属性。它是以块作为区分，每一个都有一个16位ID code，长度位16位长。
随后跟随了压缩数据。
Data descriptor
如果general-purpose 标记字段的0x08偏移位置被设置了，那么CRC-32和文件大小在头部被写入是都是不可知的。本地文件头的字段都是用0填充得。之后CRC-32和文件大小都是以一个12字节的结构在压缩数据之后马上进行添加。
Xnip2019-05-19_15-04-30.jpg
Central directory file header
中央目录条目是本地头的扩展形式。
Xnip2019-05-19_15-07-49.jpg
End of central directory record (EOCD)
在所有中央目录条目之后，是中央目录(EOCD)记录的末尾，它标志着ZIP文件的末尾:
Xnip2019-05-19_15-40-17.jpg
这种顺序允许一次性创建ZIP文件，将中央目录存储于归档文件末尾也是为了方便地在多个部分地归档中移除文件。
