把一批文件安全地交给别人，通常要连着做三件事：打包、加密、切成对方渠道能接受的大小。这三步解决的问题完全不同，混着用最容易出的两个事故是「以为加了密其实没加」和「传过去合不起来」。
下面这些操作全部在浏览器里完成，文件不上传服务器。但也正因为它们运行在页面里，能力边界和本机的 7-Zip、GPG 并不一样，哪些场景该换工具，文中会逐条说明。
一、压缩、加密、分卷各自解决什么
压缩解决两件事：把多个文件收成一个文件，以及在有冗余可挤的前提下减小体积。它不提供任何保密性，ZIP 包的文件名列表本身就是明文，别人不用解压就能看到里面有什么。
加密只解决保密性。它不减小体积（通常还会略微变大），不校验完整性，也不帮你整理目录结构。
分卷只解决「单个文件超过渠道限制」。它是对原始字节做直接切片，不压缩、不加密，切出来的 .part001 双击打不开是正常的。
顺序上，一次完整的对外传输通常是：先用文件压缩把散文件收成一个包，再用文件加密加上口令，最后用大文件分割合并切成能发的分卷。
二、ZIP 压缩率取决于文件类型，不是压缩等级
压缩工具里的「高 / 中 / 低压缩」对应 DEFLATE 的 9 / 6 / 3 级。这个参数只影响算法花多少时间去找重复模式，能挤出多少水分由文件本身决定。
- 几乎压不动的：
jpg、png、mp4、mp3、docx、xlsx、已有的zip。这些格式内部已经做过压缩或本身就是压缩容器，冗余早被榨干了。把一堆照片打包，压缩率经常只有 1% 到 3%，甚至因为ZIP的目录开销而比原始总大小略大几 KB。 - 能压很多的：
txt、log、csv、json、xml、源码、sql导出、未压缩的bmp与wav。文本里同样的字段名、缩进、时间戳前缀反复出现，日志文件压到原来的十分之一很常见。
结论很直接：给照片和视频打包时，别指望「高压缩」能省下空间，选「低压缩」还能快很多，此时打包的意义只是收成一个文件方便传。真正需要调到「高压缩」的是文本类资料。
压缩格式里的 ZIP64 是为了突破经典 ZIP 的 4 GB 单文件与条目数限制，超大文件选它，普通场景用 ZIP 兼容性更好。
解压方向要留一个心：文件解压基于浏览器端的 JSZip 实现，能可靠处理的是 ZIP。丢一个 rar 或 7z 进去，会直接提示「解压文件失败，请检查文件格式是否正确」，这不是文件坏了，是格式不支持，请改用本机解压软件。带口令的加密 ZIP 同样打不开。
三、加密强度取决于口令，不取决于算法名字
加密工具的算法下拉里有 AES、DES、TripleDES、RC4，很多人第一反应是「挑个听起来最强的」。实际决定这个文件能不能被撬开的，是你输入的那串口令。
原理是这样：口令不会直接当密钥用，而是先经过 PBKDF2 派生出固定长度的密钥（选 AES 时派生 256 位），再用这个密钥和一个随机的 16 字节 IV 做 CBC 模式加密。攻击者拿到密文后的标准打法不是去破 AES，而是猜口令：拿字典里的候选口令走一遍同样的派生流程，试着解密，看结果是不是合法数据。所以口令是 abc123 的 AES-256 文件，几秒钟就没了；口令是 20 位随机字符的文件，算法再普通也撬不开。
算法选择只有两条实用建议：
- **选
AES**。它是这里唯一还应该用于真实数据的选项。 - **不要选
DES和RC4**。DES的 56 位有效密钥长度早已可被穷举，RC4的密钥流存在统计偏差且这里没有IV参与，它们留在下拉里是为了解开历史文件，不是给新数据用的。
还有三条边界必须知道，否则会误判这个工具的定位：
- 口令下限只有 6 位，但 6 位远远不够。请至少 12 位随机字符。
- 密钥派生用的是固定盐和 1000 次迭代，按今天的标准偏弱。它足以防住「同事顺手点开你的移动硬盘」，但挡不住有针对性的离线暴力破解。要对抗后者，请用本机的 7-Zip（
AES-256加密压缩）或 GPG。 CBC模式不带认证标签，也就是说密文被改过一个字节，工具无法告诉你，只会解出一段坏数据。需要「改一比特就明确失败」的场景要用AES-GCM。
另外，加解密是把整个文件读进内存再运算的。几十 MB 没问题，几百 MB 以上标签页有崩溃风险。大文件的正确做法是先分卷、再逐卷加密，或者干脆换本机工具。
四、口令丢了，文件就是彻底丢了
这一条要单独说，因为它是唯一无法补救的失误。
加密的整个安全模型建立在「除了知道口令的人，谁都还原不出明文」之上。这里没有服务端、没有账号体系、没有密钥托管，工具本身不保存你的口令，也没有任何后门或找回入口。口令忘了，加密文件就是一段永久的随机数据，没有任何人能帮你打开，包括本站。
所以在点「开始加密」之前先安排好口令的存放：
- 存到密码管理器里，和文件本身分开保管，别写在同一台机器的同一个文件夹。
- 口令通过另一个渠道给收件人。文件走网盘，口令走电话或另一个 IM，一个渠道被人看到时不至于全盘暴露。
- 重要资料留一份未加密的离线备份，放在你自己控制的存储上。加密防的是别人看到，不是防你自己丢。
解密时还有两个高频卡点。一是算法必须和加密时一致：.encrypted 这种二进制格式的文件里没有记录算法，需要你手动选对（默认 AES）；而 Base64 输出的 .txt 格式是一段 JSON，里面存了 iv、encryptedData、algorithm、originalName，文件解密会自动读出算法和原始文件名回填。二是口令错误时的表现并不总是明确报错，可能提示「解密失败：密码错误或文件已损坏」，也可能给出一个大小对不上的坏文件，看到后者先怀疑口令和算法，而不是怀疑文件损坏。
五、分卷：顺序不能错，一片都不能少
分卷的实现是 File.slice，返回的是原文件的视图而不是数据副本，所以几个 GB 的文件也能瞬间切完且不占内存。切法有两种：按每卷大小（可选 MB 或 GB），或按分卷数量（2 到 500 卷）。会切出超过 500 卷时工具会拒绝并提示你把每卷调大。
输出的文件名是原名加 .part001、.part002，序号统一补到三位。这个补零很关键：如果只写 .part1、.part10，按文件名排序会把 part10 排到 part2 前面，合并出来的文件就是坏的。
合并成功需要同时满足两个条件，缺一个结果都是废文件：
- 一片都不能少。分卷之间没有任何冗余，缺一片就是从那个位置开始的数据全部丢失，后面的内容也无法使用。合并页会解析文件名里的
.partNNN序号并检查连续性，发现断号会提示「序号不连续，可能漏选了分卷」。 - 顺序必须完全正确。合并页按文件名做自然排序（数字按数值比较），排好后仍然可以手动上移下移。如果分卷被对方重命名过、序号丢了，工具会提示无法自动确认顺序，此时必须靠原始的分卷清单人工核对。
勾选「同时生成合并说明文件」会额外产出一份 txt，里面记录原始文件名、原始字节数、分卷数量和逐卷大小，还带上两条现成的命令行合并方法：
copy /b "data.zip.part*" "data.zip"
cat data.zip.part* > data.zip
前者是 Windows，后者是 Linux 与 macOS。注意这份说明文件本身不是数据分卷，把它一起选进合并列表会污染结果，工具会自动把文件名以「合并说明.txt」结尾的文件排除掉。
合并后强烈建议核对哈希：让对方也算一遍原始文件的 SHA-256，和你手上合并结果的值比一比。相同就说明每一个字节都对上了，这比「大小看起来差不多」可靠得多。
顺带一个渠道细节：连续触发多个下载会被浏览器判为弹窗滥用，「依次下载全部」已经在每卷之间留了间隔，首次点击时如果弹出询问，请允许「同时下载多个文件」，否则只会存下第一卷。
六、先压缩再加密，顺序反了会白做
这个顺序不是习惯问题，是数学问题。
压缩依赖数据里的冗余：重复的字符串、可预测的结构。加密的目标恰恰相反，好的加密输出在统计上接近均匀随机，任何可被利用的规律都被抹掉了。所以先加密再压缩，压缩器面对的是一段随机数据，压缩率基本为零，白花时间还多一层容器。
正确顺序是：多个文件先压成一个 ZIP，再对这个 ZIP 加密，最后按渠道限制分卷。收件人反着来：合并分卷、解密、解压。
分卷放在最后还有一个好处：加解密要整块读入内存，而分卷是零拷贝切片，把分卷放在加密之后，每一卷都是已经加密好的密文片段，中途丢一卷也不会泄露更多信息。反过来先分卷再逐卷加密也可行，而且更适合超大文件，代价是收件人要逐卷解密后再合并，步骤多一些、更容易漏。
常见问题
为什么我把一个视频压缩后，文件反而变大了？
因为 mp4 内部已经是高度压缩的编码，没有冗余可挤，而 ZIP 需要为每个条目写入文件头和中央目录记录。挤不出的水分小于新增的元数据，总大小就会略微上涨几 KB。这种情况说明打包的价值只在于「收成一个文件」，选「低压缩」即可。
加密后的文件能不能改名或改扩展名？
可以改主文件名，但别丢掉扩展名的线索。.encrypted 后缀是解密时判断「这是二进制格式」的依据，同时解密后的文件名是把 .encrypted 去掉得到的，所以 报表.xlsx.encrypted 解出来就是 报表.xlsx。如果你改成了 abc.dat，解密后拿到的文件可能没有正确扩展名，需要自己补上，否则系统不知道该用什么程序打开。
分卷里少了一片，能恢复出剩下的部分吗？
取决于文件格式，多数情况下不能。分卷是纯字节切片，没有任何纠删码或冗余，缺一片就是中间缺了一段数据。对 ZIP 这类有中央目录的格式，缺最后一片往往连目录都读不到，整个包就打不开了。唯一的办法是让对方重发缺失的那一卷，所以传输时务必先核对分卷数量再开始发。
这些操作真的不会上传我的文件吗？ 压缩、解压、加密、解密、分卷合并都在浏览器本地完成，没有上传步骤。但请把这个结论和你的风险等级对齐：涉及公司核心数据或个人敏感证件时，更稳妥的做法是用本机的离线软件处理，因为你无法在使用现场证明任何网页的行为，而这类资料一旦有泄露嫌疑，代价远大于省下的几分钟。