右键、“压缩”、等待、添加附件、发送。然后收件人下载、右键、“解压”，再等一次。我们大多数人做这些时根本不假思索——几十年来文件夹一直是这么发的。我认为是时候别再为了分享而压缩文件夹了。ZIP 格式诞生于 1989 年，当时要解决的问题是把文档塞进软盘、通过慢速调制解调器传输。如今我们的文件夹是视频项目、照片拍摄和代码仓库，这个老习惯付出的代价已经超过了它带来的好处。
我们为什么要压缩文件夹？
因为大多数分享渠道只能传单个文件。邮件附件是一个文件。聊天工具里上传的是一个文件。传统的下载链接指向一个文件。而文件夹是一棵由文件组成的树，所以必须先打包成一个文件，才能塞进这些管道。
压缩是第二个原因，在 1989 年它很重要：文本和电子表格能压缩掉很多。但对于如今人们发送的大多数文件夹，这个理由已经悄然消失了。
压缩到底让你付出了什么？
举个真实的例子：一个 40 GB 的婚礼拍摄文件夹——RAW 照片、几段 MP4 视频、一些修好的 JPEG。
- 磁盘空间，翻倍。 你需要在原文件旁边再腾出约 40 GB 给压缩包。收件人需要 40 GB 放 ZIP，再要 40 GB 来解压——一个 40 GB 的文件夹要占 80 GB，至少在他们删掉压缩包之前是这样。
- 时间，三倍。 你等它打包，再等它传输，然后收件人等它解压。在笔记本电脑上，打包和解压几十 GB 的时间可能和传输本身一样长。
- 几乎压不小。 JPEG、MP4、MOV 和大多数 RAW 格式本来就是压缩过的。把它们压缩几乎不会改变大小。你付出了时间和磁盘空间，换回来的几乎为零。
- 不到最后什么都用不了。 如果是一个大压缩包，收件人要等到最后一个字节到达并全部解压后，才能打开第一张照片。
ZIP 里会出什么问题？
成本是一回事。问题也会出现，而且往往发生在最糟糕的时刻。
长路径。 Windows 默认把文件完整路径的长度限制在 260 个字符。在 Mac 上创建的、子文件夹层级很深且命名很详细的项目文件夹，在 Windows 上解压时可能报错或丢失文件。
超大压缩包。 原始 ZIP 格式的上限是单个文件 4 GB、65,535 个条目。ZIP64 扩展取消了这些限制，但并不是每台机器上的每个工具都以同样的方式处理它。有些网盘会把大文件夹的下载拆分成好几个 ZIP 文件，收件人之后还得把它们拼回去。
文件名。 用一个工具创建、用另一个工具打开的压缩包，可能会把非拉丁字母的文件名变成乱码——西里尔字母、希腊字母、中文、带重音的字母。结构送到了，名字却没有。
垃圾文件。 macOS 访达创建的压缩包会带上 __MACOSX 文件夹和 .DS_Store 文件，让 Windows 用户摸不着头脑，最后还混进收件人的项目里。
一处出错，从头再来。 如果一次 40 GB 的下载在 95 % 时失败，压缩包就毫无用处。如果有一个字节损坏，解压可能半途而废。
这些都不稀奇。如果你发送过几 GB 以上的文件夹，很可能至少遇到过其中一种。
StrongFolder 如何把文件夹作为文件夹发送？
我们打造 StrongFolder 的出发点很简单：如果文件直接从你的浏览器传到收件人的浏览器，就没有理由先把它们打包成一个文件。
当你选择一个文件夹时，你的浏览器会读取它的目录树——每一个子文件夹和文件名。不会上传任何内容。你把链接发出去；收件人打开链接并选择保存位置。然后文件通过加密的 WebRTC 连接在两个浏览器之间直接传输，每个文件都带着它的相对路径，同样的文件夹树就出现在收件人的磁盘上。
这在实际中带来的变化：
- 不打包，不解压。 收件人一打开链接，传输就开始。
- 不额外占用磁盘空间。 收件人只需要放文件夹的空间，而不是文件夹加压缩包的空间。
- 文件逐个到达。 剩下的文件还在路上时，第一批照片已经到了收件人的磁盘上。
- 如实处理路径。 如果某个路径对 Windows 来说太长，我们会缩短文件名，并附上一个文本文件，列出所有被重命名的文件。没有任何东西会悄无声息地消失。
- 我们不设大小上限。 StrongFolder 不设大小限制。实际限制来自接收方设备的可用磁盘空间、网络速度，以及两台设备保持在线的时长。
有两个前提条件我每次都会提到。要保留结构保存整个文件夹，收件人需要在电脑上使用 Chrome、Edge、Opera 或其他 Chromium 浏览器——其他浏览器会逐个下载文件或下载为 ZIP。另外，在收件人下载完成之前，你的标签页必须保持打开，因为文件来自你的设备，而不是服务器。这就是不上传任何东西的代价。为什么发送方需要保持在线 对此有详细解释。
免费 · 在浏览器中使用 · 无需注册
什么时候 ZIP 仍然是合适的工具？
我并不反对 ZIP。它是一种出色的格式——只是不该成为每次发送前的默认步骤。以下情况我仍然会压缩：
- 我在归档。 一个文件更容易存储、校验并保存多年。
- 我需要密码。 StrongFolder 的链接没有密码。对于敏感文件，加密压缩包（例如使用 AES-256 的 7-Zip）再加上通过另一个渠道发送的密码，能增加一层保护，而且适用于任何传输方式。
- 文件夹里有成千上万个小文件。
node_modules文件夹或一堆小图片缓存打包成一个文件传得更快，因为每个文件都有自己的额外开销。 - 收件人用的是手机。 手机无法从浏览器保存文件夹树，所以文件无论如何都会逐个下载或以 ZIP 形式送达。
至于其他所有情况——拍摄素材、剪辑工程、CAD 项目、游戏模组、扫描档案——就原样发送文件夹吧。
怎样彻底告别压缩文件夹？
如果你想要分步说明，并把电子邮件、网盘和传输服务放在一起对比，请阅读 如何不压缩直接发送文件夹。对于超大文件夹，如何发送大文件 介绍了速度和设置，限制与要求 列出了所有浏览器细节。
如果哪天文件夹送到时出了问题——名字不对、子文件夹丢失，无论什么问题——请写信给我：info@strongfolder.com。文件夹是 StrongFolder 存在的理由，我想知道。