1.1 诞生背景：菲尔·卡茨与PKWARE
1980年代末，个人计算机开始普及，软盘容量有限，用户急需一种高效的文件压缩工具。当时流行的ARC格式由System Enhancement Associates（SEA）开发，但采用了专利加密算法，且授权费用高昂。菲尔·卡茨（Phil Katz），一位自学成才的程序员，因不满ARC的封闭生态，于1989年创建了PKWARE公司，并发布了自行设计的ZIP格式。ZIP的全称是“Zipped”，最初寓意“像拉链一样快速闭合”。卡茨将格式规范完全公开，允许任何人自由实现，这一开放性奠定了ZIP的传播基础。
1.2 PKZIP与DOS时代
PKWARE推出的PKZIP命令行工具迅速成为MS-DOS平台上的压缩标准。PKZIP采用DEFLATE算法，压缩效率显著高于ARC，且支持多文件打包与密码保护。用户只需在命令行输入“pkzip archive.zip file1.txt file2.txt”，即可生成压缩包。PKZIP的分卷功能尤其适合将大文件拆分到多张软盘，因此被广泛用于软件发行与数据备份。在1990年代初，PKZIP几乎成了“压缩”的代名词，以至于许多用户将任何压缩文件都称为“ZIP文件”。
1.3 专利之争与开放标准
1.3.1 PKWARE vs. SEVENTEEN 案（梗：压缩包里的法律纠纷）
1991年，SEA公司起诉PKWARE侵犯了ARC格式的版权与商标权。该案最终庭外和解，但PKWARE的胜诉式结局（实际上法院裁定PKZIP不侵权）激励了卡茨进一步开放ZIP规范。此后，卡茨甚至将PKZIP的源代码免费发布，以对抗SEA的封闭策略。这一系列法律纠纷被技术社区戏称为“压缩包里的法律纠纷”——当你以为打开的是文件，其实打开的是诉讼信。最终，ZIP凭借开放与免费成为行业标准，而ARC逐渐销声匿迹。
1.4 现代扩展：Info-ZIP与开源生态
1990年代后期，一群志愿者组建了Info-ZIP项目，开发出完全独立的ZIP实现（zip/unzip命令行工具）。Info-ZIP的代码被移植到几乎所有操作系统，包括Unix/Linux、Windows、macOS。随后，7-Zip、WinRAR等工具纷纷兼容ZIP格式，使其成为跨平台事实标准。开源社区还贡献了AES加密扩展、ZIP64（突破4GB大小限制）等功能，让ZIP从DOS时代的“老古董”顺利融入现代计算环境。
2.1 数据压缩算法
2.1.1 DEFLATE：核心压缩引擎
ZIP默认采用的DEFLATE算法由菲尔·卡茨发明，结合了LZ77（滑动窗口匹配）与哈夫曼编码。它能在压缩率与速度之间取得良好平衡。DEFLATE支持从1（最快）到9（最佳压缩）的级别，级别越高，压缩后体积越小但耗时越长。几乎所有ZIP实现都默认使用DEFLATE，因此“ZIP压缩”通常就是指DEFLATE压缩。
2.1.2 存储模式（无压缩）与BZIP2可选支持
ZIP支持一种“存储”模式，即不对文件进行任何压缩，仅打包。这适用于已经压缩过的媒体文件（如JPEG、MP4），避免二次压缩带来的性能浪费。此外，部分现代ZIP工具（如WinZip 12+）支持BZIP2算法，后者比DEFLATE压缩率更高，但速度较慢。不过BZIP2并非ZIP标准的强制部分，兼容性有限。
2.1.3 分卷压缩（ZIP Split）
分卷压缩允许将一个大压缩包分割成多个固定大小的文件，例如每卷1.44MB以适应软盘，或每卷100MB用于邮件附件。分卷文件的命名通常为“archive.zip”、“archive.z01”、“archive.z02”等。解压时需要所有分卷在同一文件夹中，否则会报错。这种机制被戏称为“文件碎尸术”——只有凑齐全部碎片才能复原。
2.2 文件结构
2.2.1 本地文件头与中央目录
ZIP文件的物理结构由三部分组成：每个文件的本地文件头（包含文件名、压缩方法、大小、CRC-32校验值等）、实际压缩数据、以及位于文件末尾的中央目录。中央目录列出了所有文件的索引，这是解压时快速定位的关键。这种设计允许“流式”生成——先写入文件头和数据，最后写入目录，因此ZIP非常适合网络传输（发送端无需事先知道文件总大小）。
2.2.2 签名与校验（CRC-32的玄学）
每个ZIP条目都包含一个4字节的CRC-32校验码，用于验证文件完整性。CRC-32是一个简单的循环冗余校验，但它“玄学”之处在于：误码撞上相同CRC的概率约为1/4e9，但实际中因文件修改或传输错误导致校验不一致时，解压工具通常会提示“CRC失败”。不过，一些用户发现即使CRC错误，文件仍可能部分可读，于是诞生了“无视CRC强行解压”的邪道技术。
2.2.3 结尾记录（EOCD，常被吐槽的寻址难点）
ZIP文件末尾必须存在一个“End of Central Directory Record”（EOCD）签名（0x06054b50）。EOCD记录了中央目录的偏移量和大小。然而，EOCD本身只有22字节固定长度，且位于文件最后几个字节。若文件末尾存在注释字段，则EOCD位置会变化，导致一些简易解压器难以定位。更头疼的是，某些工具会在注释中写入随机数据，使得“寻找EOCD”成了破解谜题。因此，ZIP维护者后来引入了“ZIP64 EOCD定位器”来缓解此问题，但旧格式仍残留着“EOCD去哪儿了”的吐槽文化。
2.3 加密与安全
2.3.1 传统ZipCrypto（请勿用于保护重要秘密）
经典ZIP加密（ZipCrypto）使用基于流密码的算法，其密钥生成算法（PKWARE传统加密）已被证明不安全。攻击者只需知道加密文件中的少量明文（例如已知文件头或公共文件），即可在数分钟内破解密码。因此，技术社区流传着一条铁律：“用ZIP传统加密保护重要秘密，等同于告诉全世界你的密码是123456”。
2.3.2 AES-256加密（WinZip时代的升级）
为弥补安全缺陷，WinZip在2003年引入了AES-256加密扩展。它基于AEAD模式，提供强加密认证。但AES加密的ZIP文件并非标准ZIP，需要WinZip或7-Zip等兼容工具才能正确解压。Windows原生资源管理器不支持AES-加密ZIP，导致部分用户误以为文件损坏——实际上是加密方式不兼容。
2.3.3 已知漏洞与“伪加密”梗
ZIP格式存在一个“伪加密”技巧：将本地文件头的加密标志位设为1，但实际数据未加密。这样，当系统检测到加密位但无法解密时，会提示输入密码；但用7-Zip等工具忽略此标志即可正常解压。一些用户利用此特性制作“密码门”式的加密包——看似需要密码，实则只需点击“解压并忽略”。这演变为网络资源分享中的“伪加密”梗，常用来调侃那些为彰显“高端”而故意设密码分享公共文件的行为。
3.1 软件发行与更新
3.1.1 Java JAR文件：披着ZIP马甲的执行包
Java的JAR（Java Archive）文件本质就是ZIP格式，只是将扩展名改为.jar，并在内部包含一个META-INF目录存放清单文件。JAR文件可直接被Java虚拟机执行，成为Java程序分发的基础。这种“披着ZIP马甲”的设计让开发者可以轻松打包类文件、资源与元数据。
3.1.2 Android APK与Office OOXML格式
Android应用的APK安装包同样是标准ZIP格式（仅扩展名为.apk），内部包含了dex字节码、资源文件和签名。同理，Microsoft Office 2007+使用的OOXML（.docx、.xlsx、.pptx）也是ZIP容器，将XML文档、图片和样式压缩打包。这就是为什么你将一个.docx文件重命名为.zip后，可以像普通ZIP一样解压查看内部XML——这是“文件其实是个压缩包”的经典案例。
3.2 文件归档与备份
3.2.1 主流系统原生支持（Windows、macOS、Linux）
三大桌面操作系统均提供原生ZIP支持：Windows资源管理器可直接创建/解压ZIP；macOS的Finder同样支持；Linux发行版通常预装zip/unzip命令行。这种无处不在的支持让ZIP成为“无门槛”归档标准。对比之下，RAR需要安装WinRAR，7z需要7-Zip，而ZIP几乎是开箱即用。
3.2.2 合辑爱好者与“解压即玩”游戏包
对于游戏爱好者，尤其是经典DOS游戏合辑和模拟器玩家，ZIP打包的“解压即玩”包极为流行。用户只需下载一个ZIP，解压后直接双击exe即可运行，无需额外安装步骤。这种形式也被音乐发烧友用于分享无损专辑——将cue文件与flac打包成ZIP，号称“无损原汁原味”。
3.3 互联网文件传输
3.3.1 邮件附件与下载站标配
电子邮件系统大多限制附件大小（常见25MB），ZIP压缩可以有效减小体积。更重要的是，ZIP能将多个文件打包成一个附件，避免“一堆零散文件”让收件人崩溃。因此，“请将所有文件压缩成一个ZIP发我”几乎是跨公司协作的通用礼仪。下载站也普遍提供ZIP格式供用户选择。
3.3.2 压缩包里的“打包癖”与“多重嵌套”文化
部分用户有强烈的“打包癖”：明明只有一个文件，也要丢进ZIP里，理由是“显得整齐”。更极端的是“多重嵌套”文化——将文件夹压缩成ZIP，解压后得到一个同名文件夹，再打开发现里面又有一个ZIP……如此循环，被戏称为“俄罗斯套娃压缩包”。这种恶搞在技术论坛上常被用作“解压测试”，考验用户的耐心和工具链处理能力。
4.1 经典命令行工具
4.1.1 Info-ZIP套装（zip/unzip）
Info-ZIP项目最早源于1990年，为Unix系统提供了免费的zip和unzip命令。其后被移植到几乎所有平台，成为Linux和macOS的默认工具。用法简单：zip archive.zip file1 file2 创建压缩包；unzip archive.zip 解压。Info-ZIP还支持分卷、密码、注释等高级选项，是程序员的瑞士军刀。
4.1.2 7-Zip与pkzipc
7-Zip的命令行版本（7z.exe/7za）同样支持ZIP格式，且能创建AES-256加密的ZIP。pkzipc是PKWARE官方提供的商业命令行工具，功能与Info-ZIP类似，但支持更多企业级特性（如数字签名）。不过，随着开源工具普及，pkzipc的使用率已大幅下降。
4.2 图形界面软件
4.2.1 WinRAR的“虽然不是ZIP但能读ZIP”
WinRAR虽然以自家的RAR格式闻名，但对ZIP的兼容性极佳。它支持创建和编辑ZIP文件，并能处理分卷、AES加密等扩展特性。其界面上那句“虽然不是ZIP但能读ZIP”的潜台词是：你可以把ZIP扔进WinRAR，它会像处理RAR一样流畅。
4.2.2 Windows文件资源管理器内置
从Windows XP开始，资源管理器就集成了基本的ZIP功能：右键→“发送到”→“压缩(zipped)文件夹”可创建ZIP；双击ZIP文件会像浏览文件夹一样显示内容。但内置功能不支持AES加密、分卷或密码（早期版本），且解压大文件时速度较慢。尽管如此，它仍是实际使用率最高的ZIP工具——毕竟无需安装。
4.2.3 BetterZip、The Unarchiver等第三方
在macOS平台上，BetterZip和The Unarchiver是两款热门第三方工具。BetterZip允许预览文件内容而不解压；The Unarchiver则以其强大的解压能力（支持几乎全部归档格式）和简洁界面著称。此外，Bandizip（Windows）和Keka（macOS）也提供了丰富的ZIP处理功能。
4.3 编程库与开发者接口
4.3.1 zlib与minizip
zlib是实现了DEFLATE压缩算法的C语言库，也是ZIP格式的核心依赖。minizip是基于zlib的轻量级库，提供了创建和读取ZIP文件的API。许多应用（如Photoshop、Google Chrome）内部都使用zlib处理数据，而minizip则被广泛应用于嵌入式系统和游戏引擎。
4.3.2 Java java.util.zip包
Java标准库自带java.util.zip包，提供ZipOutputStream和ZipInputStream类，让Java程序员可以轻松读写ZIP文件。这使得JAR、WAR等Java归档格式天然兼容ZIP。不过，该包对Unicode文件名支持不佳（需使用ZipFile的UTF-8标志），曾引发过“编码地狱”问题。
4.3.3 Python zipfile模块（谁还没写过解压脚本？）
Python的zipfile模块是标准库的一部分，提供了简洁的API：zipfile.ZipFile('archive.zip') 即可读取。由于Python被广泛用于自动化脚本，许多开发者第一次接触ZIP编程就是写一个“递归解压所有ZIP并合并文件夹”的脚本。这也催生了“谁还没写过解压脚本？”的社区自嘲——毕竟，几乎每个Python初学者都会尝试用zipfile模块处理下载的游戏资源包。
5.1 “解压密码”之谜与网络资源分享礼仪
在网盘分享和论坛下载中，“解压密码”是一种常见现象。发帖者会在下载链接旁附带密码，有时是固定短语如“www.example.com”，有时是谐音梗如“我中了”。新手常因找不到密码而困惑，老手则形成了一套礼仪：仔细阅读帖子正文、查看文档注释、甚至暴力尝试“123456”。这种密码机制本质上是一种流量引导手段，但演变成了网络文化的一部分——“解压密码”三个字本身就是一种接头暗号。
5.2 层层嵌套的祖传压缩包（解开还是文件夹）
有些资源发布者喜欢将内容打包成“文件夹→ZIP→文件夹→ZIP”的递归嵌套。解压一次得到一个文件夹，文件夹里又是一个ZIP，再解压……如此反复，直到无限接近“宝藏”文件。这类“祖传压缩包”考验的不仅是工具链，还有用户的耐心。技术社区甚至将此列为“人格测试”：能解到第几层还保持冷静的人，适合当系统管理员。
5.3 “压缩包损坏”的玄学修复尝试
下载一个大ZIP文件时，偶尔会遇到解压到一半报错“文件损坏”。用户的第一反应通常是：重新下载。但如果断点续传失败，人们会尝试各种玄学修复：打开7-Zip的“修复”功能、用WinRAR的“保留损坏文件”选项、甚至用二进制编辑器手动定位坏块。实际上，许多损坏仅发生在文件末尾的注释区，不影响正文数据——因此“跳过错误”往往能成功解压大部分文件。这项技术被戏称为“玄学修复”，成功率全凭人品。
5.4 ZIP vs. RAR vs. 7z：压缩率之争的永久话题
在压缩爱好者论坛，ZIP、RAR、7z三者的优劣是永不停息的争论。支持者认为ZIP兼容性无敌；RAR拥护者强调高压缩率与恢复记录；7z粉丝则炫耀其LZMA2算法击败一切。实际上，对于普通文件（如txt、exe），7z通常能比ZIP多压缩10%~30%的体积。但实战中，用户选择ZIP往往是因为“对方能用Windows直接打开”。这场争论的最终共识是：压缩率再高，也比不上对方机器没装对应解压器带来的尴尬。
6.1 解压乱码（编码地狱）
ZIP文件头中的文件名使用本地系统编码存储（如CP437、CP932、UTF-8）。当文件在非兼容系统上解压时，中文文件名常显示为乱码，例如“浣犺ソ.txt”实际上应该是“你好.txt”。解决方法是使用支持编码识别的解压器（如7-Zip、Bandizip）或手动设置正确编码。WinRAR的“升级”功能也能自动检测。此问题在跨语言分享ZIP时屡见不鲜，被戏称为“编码地狱”。
6.2 文件损坏与恢复
CRC-32校验失败最常见的成因是下载不完整或存储介质错误。轻量情况下，使用WinRAR的“保留损坏文件”选项可强制提取部分数据；更严重的需要使用专用恢复工具如DiskInternals ZIP Repair。注意，恢复工具并非万能——如果文件被覆盖或物理损坏，只能烧香祈祷。
6.3 分卷合并与残缺文件处理
分卷ZIP（如.zip、.z01、.z02）若缺少某卷，解压会立即终止。可以尝试通过工具（如7-Zip）的“合并”功能将所有分卷合成一个完整ZIP，但缺少的卷无法凭空生成。实践中，接收方应要求发送方重新上传缺失卷。分卷合并的常见误区是忽视文件命名连续性——若.z01被误命名为.zip_1，工具便无法识别。
6.4 大文件（>4GB）ZIP64兼容性
ZIP标准最初限制单个文件大小不超过4GB。为解决此问题，ZIP64扩展允许文件体积达到16EB。但并非所有解压器都支持ZIP64：WinRAR和7-Zip支持良好，而Windows原生资源管理器对ZIP64的支持有限（Windows 10早期版本会报错）。用户若需打包超大型文件（如虚拟机磁盘），建议转而使用7z或RAR格式，或确保接收方安装了ZIP64兼容工具。
7.1 固态硬盘时代的压缩必要性之辩
随着NVMe SSD的普及，存储速度已接近内存，压缩和解压的CPU开销可能反而拖慢文件传输。对于日常文件，有人主张应直接拷贝原始文件，避免压缩。但在网络传输带宽仍为瓶颈的今天，压缩仍能显著加速发送。未来的趋势可能是“智能压缩”：工具自动判断文件类型，动态决定是否使用压缩。
7.2 云端归档与流式压缩
云计算时代，ZIP需要适应流式传输——在文件尚未完全上传时即可开始解压或预览。例如，Google Drive的ZIP预览功能使用流式解压，无需下载完整包。未来ZIP格式可能添加对“边下载边解压”的原生支持，减少等待时间。同时，云端服务对ZIP的加密需求也将催生更多基于密钥管理的安全方案。
7.3 后量子加密对ZIP格式的影响（正经但不失幽默的思考）
如果量子计算成为现实，当前基于Shor算法（能破解RSA）和后量子密码学的威胁将影响ZIP的AES-256加密。虽然AES-256本身被认为能抵抗量子攻击（Grover算法仅能将破解复杂度从2^256降至2^128），但ZIP传统加密的MD5密钥派生会被量子加速破解。因此，未来的ZIP标准必须升级到后量子安全的密钥交换机制。想象一下，当你的曾孙尝试解开你留下的“加密压缩包”时，可能得先跑一趟量子矿机——当然，他们更可能会笑着说：“这年头谁还单独用ZIP加密？直接上量子指纹锁不香吗？” 总之，ZIP作为长寿的封装格式，将继续在兼容性与安全性之间寻找平衡，而“解压后文件失踪”的玄学谜题，也将随技术进步被偶尔解密，但永远留存在互联网的幽默记忆中。