发送前压缩文件：减小大小节省时间

发送前压缩文本、源代码、日志、CSV 以及 .bmp、.tiff 等未压缩图像格式——预计可缩小 3—10 倍。不要压缩 .jpg、.png、.mp4、.mp3、.docx、.xlsx、.pdf 或 .zip 文件——它们内部已经过压缩，再压缩一遍最多节省 2%—3%，却白白消耗 CPU。若需要将多个小文件合并为一个上传包，用"仅存储"（无压缩）模式的 .zip。追求最高压缩比时，7z 搭配 LZMA2 算法通常比 .zip 好 30%—40%。RAR 与 7z 压缩效果相当，但接收方需要安装 WinRAR 或 7-Zip——.zip 则是通用格式，所有系统内置支持。

压缩真正有效的场景

文本文件的压缩效果极为显著。一个 10 MB 的服务器 .log 文件，用 .zip 压缩后通常能缩小到 800 KB（约 12 倍），用 7z 则可缩小到 550 KB（约 18 倍）。压缩之所以有效，是因为日志中存在大量重复模式——时间戳、IP 地址、HTTP 状态码——压缩算法能高效利用这些规律。

同样适合压缩的类型：

源代码： .js、.py、.java、.cs、.go——通常压缩比 3—5 倍
CSV 数据： 4—10 倍，取决于内容冗余程度
JSON/XML： 5—8 倍，因为字段名重复频率高
未压缩图像： .bmp（5—10 倍）、未压缩 .tiff（4—8 倍）
数据库文件： .sql 导出文件、含空闲页的 SQLite（2—4 倍）
PSD 平铺图层： 2—3 倍（前提是内部未启用 RLE 压缩）

中等规模项目的 Git 仓库打包后通常可压缩 4—5 倍，这也是 git archive 默认输出 .tar.gz 格式的原因。

压缩毫无意义的场景

已压缩格式不会因为再压缩而变小。这些文件的底层数据已经经过 DEFLATE、H.264、JPEG DCT 量化或类似算法处理——熵值已接近理论下限。

不会从压缩中获益的文件类型：

.jpg、.jpeg、.heic： 有损压缩已经完成
.png： 内置 DEFLATE 压缩
.mp4、.mov、.mkv： 已应用 H.264 或 H.265 压缩
.mp3、.aac、.flac、.ogg： 音频已经过压缩
.pdf： 内部对象流通常已 DEFLATE 压缩
.docx、.xlsx、.pptx： 本质上是 XML 的 ZIP 存档，再次打 ZIP 毫无意义
.zip、.7z、.rar、.gz、.bz2、.xz： 已压缩存档，再次压缩徒劳
.apk、.jar、.war： 基于 ZIP 的 Java/Android 包

对这些文件进行压缩不仅浪费 CPU，有时还会因存档元数据开销导致文件略微变大。

ZIP vs 7z vs RAR 对比

| 格式 | 典型压缩比 | 速度 | 接收方兼容性 | 加密支持 | |---|---|---|---|---| | .zip（DEFLATE） | 基准 | 快 | 通用（Windows、macOS、Linux 内置） | ZIP 2.0（弱）/ AES-256（多数现代工具） | | .zip（DEFLATE64） | 比 .zip 好 5%—10% | 快 | Windows 内置、7-Zip、部分 macOS 工具 | 同 .zip | | 7z（LZMA2） | 比 .zip 好 30%—40% | 较慢 | 需要 7-Zip、Keka 或 The Unarchiver | 内置 AES-256 | | .rar（RAR5） | 比 .zip 好约 25%—35% | 中等 | 需要 WinRAR 或 7-Zip；创建不免费 | 内置 AES-256 | | .tar.gz | 与 .zip 相近 | 快 | macOS、Linux 内置；Windows 需 7-Zip | 无原生加密 | | .tar.zst（Zstandard） | 介于 .zip 和 7z 之间 | 极快 | 需要 zstd（尚未普及） | 无原生加密 |

兼容性优先选 .zip，压缩比优先选 7z，追求速度和现代效率选 Zstandard（.zst），但接收方需要支持该格式的工具。

打包用的"仅存储"模式

如果你需要在一次传输中发送 200 张 .jpg 照片，仍然希望接收方只需点击一次"下载"。这时使用压缩级别为 0（"仅存储"）的 .zip。存档大小等于所有文件大小之和加上少量目录开销，创建时几乎不消耗 CPU。

在 7-Zip 中：添加到存档 → 压缩级别 → 仅存储。在 macOS Finder 中：右键 → 压缩（默认使用 DEFLATE，对 .jpg 无效但影响也不大）。命令行：zip -0 bundle.zip *.jpg。

压缩时的加密选项

使用 AES-256 加密（不是老旧的 ZIP 2.0 加密）的密码保护 ZIP 文件，在无法保证传输信道安全时，是传输敏感内容的合理选择。WinRAR、7-Zip 和 macOS 的归档实用工具均支持 AES-256 ZIP 加密。

注意密码交换的方式：不要在发送 ZIP 文件的同一封邮件中附上密码。先发文件，再通过 Signal、iMessage 或其他独立渠道分享密码。更好的方案是使用内置密码保护功能的传输服务，由服务代为处理这些复杂性。

旧版 ZIP 2.0 加密（某些老旧工具仍以此为默认）在密码学上已被攻破——已知明文攻击可在数秒内破解。若依赖存档加密来保护安全，务必确认使用的是 AES-256。

权衡：CPU 时间 vs 节省字节数

压缩是时间与体积之间的权衡。对一个 5 GB 的文本存档使用 7z 最大压缩，可能在笔记本上需要 30 分钟，比 .zip 节省 2 GB。如果传输受大小限制（服务上限为 2 GB），这样做值得。但如果传输受时间限制且带宽充足，同样 5 GB 的文件在光纤上 90 秒就能上传完——花半小时压缩反而更费时。

经验法则：网速慢、CPU 快时压缩；网速快、CPU 资源紧张时跳过压缩。

分割超大存档

当文件超过传输服务的大小上限时，可以分割成多卷。7-Zip 和 WinRAR 均支持多卷存档（.7z.001、.7z.002 或 .part1.rar、.part2.rar）。每个分卷可单独上传，接收方下载全部分卷后解压。

这种方式有效但脆弱——任何一个分卷丢失，整个存档就无法使用。更好的方案是使用大小上限更高的服务。SwissTransfer 的 50 GB 上限在大多数实际场景下无需分割。

有损压缩作为替代方案

有时目标不是存档压缩，而是文件格式转换压缩。一个 200 MB 的 .wav 音频文件转为 320 kbps 的 .mp3 后只有 15 MB——有损，但休闲聆听几乎感觉不到差异。一张 60 MB 的未压缩 .tiff 照片转为高质量 .jpg 后只有 5 MB。4K .mov 视频用合理码率重新编码为 H.265，体积可缩小 3—5 倍。

这需要审慎使用。对于原始文件，有损转换会丢失信息；对于预览或交付成品，则是正确选择。常用工具：视频/音频用 FFmpeg，视频编码用 HandBrake，图像处理用 ImageMagick，或直接用 Photoshop、Final Cut Pro、Premiere 的导出对话框。

传输服务本身的压缩机制

大多数传输服务会对传输过程进行一定程度的压缩——TLS 压缩出于安全原因已被禁用，但 API 层的 HTTP gzip 或 brotli 偶尔会处理元数据。实际文件内容通常不会在服务端压缩，因为大多数文件已经是压缩格式。

HexaTransfer 等零知识服务根本无法在服务端压缩文件内容，因为服务端收到的是密文。压缩必须在加密之前在客户端完成——加密后的密文看起来是随机数据，不可压缩。这意味着使用端对端加密服务时，客户端压缩是唯一减小文件体积的方式。

根据内容决定，而非习惯

最常见的错误是无脑地"发送前先 ZIP"。客户收到 20 份 .pdf 文件时，ZIP 打包很方便；客户收到一个 800 MB 的 .mp4 时，ZIP 对双方都是浪费时间。根据内容做选择。

不确定时：直接发送原始文件。接收方收到后随时可以打包。若需要合并多个文件，用仅存储模式的 .zip。若内容以文本为主，用 7z 才能真正节省空间。

在 hexatransfer.com 上试试 — 免费、无需注册、最多 10 GB。