别人甩来一个网盘链接，说"东西在里面，自己下"，你点开、下载、双击，屏幕上弹出一句"文件已损坏或格式未知"；再换一个，解压出来满屏乱码文件名;还有的解到 87% 卡住不动，提示"缺少必要的卷"。这类场景在文件交换里出现的频率高得离谱，而绝大多数人处理它的方式只有一种:再装一个"万能解压工具"。我在实际处理这类问题的过程中发现，真正让人卡住的从来不是"工具不够万能"，而是对压缩包这条链路的认知缺失——它从打包那一刻起就带着版本、编码、分卷、校验四层信息，任何一环对不上，解压就会失败。这篇内容想讲清楚的就是这条链路:压缩包从网盘落到本地，中间可能出问题的地方在哪，格式怎么辨认，报错怎么逐条排查，安装包类压缩包为什么需要单独对待，以及我本地那套已经用了很久的目录约定和批量脚本。不管你是刚学会下载软件的新手，还是天天给别人擦屁股的运维，下面的东西应该都能直接拿去用。
1. 压缩包从下载到落地，中间到底断在哪一环
1.1 把"解压失败"拆成四个独立的故障域
很多人把"解压不了"当成一个笼统的问题，实际上它是四个完全不同的故障域叠加在一起的结果，混在一起看就永远找不到根因。第一个域是传输域:网盘下载、浏览器下载、邮件附件、聊天工具转发，每一层都可能把文件截断几个字节，而截断的文件在扩展名上看起来毫无异常。第二个域是封装域:打包时用了什么算法、有没有分卷、有没有加密文件名、注释里塞了什么，这些在解压前是不可见的。第三个域是解码域:解压软件版本能不能识别这个格式的版本号，字符编码和解压端的区域设置是否一致。第四个域是落地域:目标路径长度、磁盘剩余空间、杀软实时扫描、文件占用，这些跟压缩包本身无关，但报错信息往往长得一模一样。
我把这四个域画在一张纸上贴在显示器旁边，遇到问题先定位属于哪个域，效率比盲目换软件高一个数量级。举个最常见的例子:有人从网盘下载了一个 4.2 GB 的压缩包，解压到一半报"数据错误"。他第一反应是换个解压软件，换了三个还是报错，于是认定"文件坏了"。实际上用校验工具一跑，CRC 对不上，问题在传输域——下载过程中连接中断，客户端做了续传但没有对齐偏移，文件中部有一段静默损坏。这时候换一百个解压软件都没用，重新下载才是正解。
排查顺序永远是:先确认文件完整性，再确认格式与版本，最后才怀疑软件。反过来做，90% 的时间都浪费在重装工具上。
1.2 "万能解压"这个词本身就是个诱导性说法
市面上打着"万能"旗号的工具，本质上是把多个开源解压库（libarchive、7-Zip 的 SDK、unrar 的实现）打包进一个壳里，再配一个"什么都能双击"的关联列表。它确实能打开绝大多数格式，但"能打开"和"能正确还原"之间隔着一整条街。我在实测中遇到过几次典型差异:某些工具打开 RAR5 分卷时只读取第一卷，后面的分卷被静默忽略，解压"成功"了但少了三分之二的文件；某些工具对 ZIP 里的 UTF-8 文件名判断错误，全部显示成问号；还有些工具在处理带加密头的 RAR 时直接崩溃，而不是给出"需要密码"的提示。这些行为最恶劣的地方在于——它不报错，你以为成功了。
所以我现在选工具的标准不是"支持多少种格式"，而是出错时会不会明确告诉你出错了。一个会老老实实报"CRC 校验失败，第 3 个文件"的工具，价值远高于一个"什么都能解"但静默丢文件的工具。
1.3 我常备的三件套和各自的分工
长期用下来，我本地固定保留三类工具，职责划分得很清楚，互相不越界。第一类是命令行主力，负责所有批量操作和可脚本化的校验，特点是输出信息完整、退出码可靠，出错时能拿到明确的错误级别而不是一句弹窗。第二类是图形界面的兜底工具，专门用来处理需要肉眼确认的场景，比如带密码的包、需要挑选部分文件的包、需要预览目录结构的包。第三类是校验与修复专用工具，不参与解压，只负责判断"这个文件到底完不完整"和"残缺的能不能抢救一部分"。
这三类工具不要合并成一个。我见过太多人为了图省事只装一个"全家桶"，结果遇到问题时连"到底是文件坏了还是软件不认"都判断不出来。工具的价值在于交叉验证，两个独立实现给出同样的结果，你才能对结论有信心。
2. 先看清对手:格式识别是解压的第一步
2.1 扩展名是给人看的，文件头才是给程序看的
压缩包的扩展名极其不可靠。网盘为了规避某些限制会把.rar改成.rar.txt、.bin、.jpg，有些人解压完发现"打不开"其实是扩展名被改了；反过来也有把文本文件硬命名成.zip的情况。真正决定格式的是文件开头的几个字节，也就是所谓的魔数。判断方法很简单，Windows 下用 PowerShell 读前 16 个字节，Linux 和 macOS 用xxd或od，最省事的是写个十行的 Python 脚本批量扫一遍目录。
# Linux / macOS：读前 16 字节的十六进制 xxd -l 16 suspicious.rar.txt # 一次看一个目录里所有文件的头 for f in *; do printf '%-40s ' "$f"; xxd -l 8 -p "$f"; done# Windows PowerShell：等价写法 Get-ChildItem *.bin | ForEach-Object { $bytes = [System.IO.File]::ReadAllBytes($_.FullName)[0..7] "{0,-40} {1}" -f $_.Name, (($bytes | ForEach-Object { $_.ToString("x2") }) -join "") }拿到十六进制串之后对照下表，基本一眼就能定格式。这张表我打印出来夹在笔记本里很多年了，比任何"格式识别"小工具都快。
| 十六进制头 | 对应格式 | 常见变体 |
|---|---|---|
50 4B 03 04 | ZIP | 也用于 docx/xlsx/apk/jar，本质都是 ZIP |
50 4B 05 06 | 空 ZIP | 打包时没有任何文件，容易误判为损坏 |
52 61 72 21 1A 07 00 | RAR 4.x | 老式分卷.r00/.r01属于这一代 |
52 61 72 21 1A 07 01 00 | RAR 5.x 及以后 | 新式分卷.part1.rar属于这一代 |
37 7A BC AF 27 1C | 7z | 分卷命名为.7z.001 |
1F 8B | gzip | 单文件压缩，不保存目录结构 |
42 5A 68 | bzip2 | 常与 tar 组合 |
FD 37 7A 58 5A 00 | xz | .tar.xz的常见组成 |
4D 5A | PE 可执行文件 | 极可能是自解压包，需进一步判断 |
25 50 44 46 | 常被误当成压缩包 |
2.2 自解压包和被"拼接"过的压缩包
4D 5A开头的自解压包是个特殊物种。它前半段是标准的 Windows 可执行文件，后半段才是真正的压缩数据，运行时自己解压自己。很多人看到.exe就以为是安装程序，不敢点，其实完全可以用常规解压工具直接"解包"，绕开可执行文件本身。我在处理这类文件时的习惯是:一律不双击，先交给解压工具打开，看看里面到底有什么，确认没有多余的可执行脚本再决定要不要运行——这是一个成本极低但能避掉很多麻烦的习惯。
还有一种更隐蔽的情况:文件被"拼接"过。常见做法是把一个压缩包追加到一张图片后面，生成一个既能当图片看、又能当压缩包用的文件。这种文件用图片查看器可以正常打开，用解压工具也能正常列出内部结构。扩展名可能是.jpg，但魔数检查会显示它同时含有FF D8 FF的 JPEG 头和50 4B 03 04的 ZIP 头。判断它其实不需要特殊工具，只要能读到文件头部再往后扫一遍即可。
2.3 不同格式在"目录结构"上的根本差异
这里有个容易被忽略的知识点:不是所有压缩格式都保存目录结构。gzip、bzip2、xz 这类是单文件流压缩，它们只负责把一段字节流变小，不关心文件名、不关心权限、不关心目录层级。所以.tar.gz才是真正的"打包+压缩"两步走:tar 先把目录树打成一个连续的大文件，gzip 再把这个大文件压小。理解了这一点，你就明白为什么tar -xzf的-z是"先解压缩"，而-x是"拆包"，两个动作是分离的。
而 ZIP、RAR、7z 属于归档式压缩，一个文件里就能保存完整的目录树、文件名、时间戳、权限位甚至注释。7z 更进一步，支持固实压缩——把多个文件当成一个连续数据块处理，压缩率更高，但代价是修改其中任何一个文件都要重写整块，且部分损坏时影响面更大。我在处理大体量素材包时会在意这个差异:固实压缩的包如果中间坏了几百字节，后面的文件可能全军覆没；非固实的包坏哪块就只损失哪块。
3. 网盘这一环埋的雷，比压缩算法本身更致命
3.1 分卷包的命名规则和一个最常见的误操作
大文件在网盘上传播时经常被切成多卷，命名规则因工具而异，这是最容易出错的地方。RAR 有两代命名，老式是xxx.rar配合xxx.r00、xxx.r01，新式是xxx.part1.rar、xxx.part2.rar；7z 的分卷是xxx.7z.001、xxx.7z.002；ZIP 分卷是xxx.zip配合xxx.z01、xxx.z02。这里的关键规则是:分卷必须全部齐备，且必须从第一卷开始解。从.part3.rar开始解压，某些工具会"成功"，但它只能看到第三卷里的内容，你会得到一个看起来正常但缺了大半文件的目录。
我遇到最多的误操作是"只下载了看得见的那个文件"。.part2.rar之后的分卷在网盘客户端里有时不显示缩略图、不显示大小，很多人以为那是重复文件或者垃圾文件，直接跳过。判断是否完整的简单办法是看命名序号有没有断号，以及各卷体积是否一致——除了最后一卷，其余各卷的体积在正常情况下应该完全相同，如果part2和part3差了 200 MB，那基本可以确定某一卷没下完。
分卷包解压前一定要做的一件事:把所有分卷放进同一个目录，不要分散在不同文件夹里。绝大多数解压工具不会跨目录去找分卷。
3.2 校验值怎么用才不是形式主义
压缩包内建了校验机制，这不是摆设。ZIP 的每个文件条目都有 CRC32，RAR 有文件级和卷级的校验，7z 有 CRC32 和可选的 SHA-256。这些校验值的价值在于:它能在解压之前就告诉你"这个包是坏的"，而不是让你解压 20 分钟后在最后几个文件上翻车。
命令行工具普遍支持"只测试不解压"，这是我最常用的操作之一，几 GB 的包跑一遍通常几十秒到几分钟，比解压完再发现有问题划算太多。
# RAR：测试完整性，不解压 unrar t big.part1.rar # 7z：测试完整性 7z t archive.7z.001 # ZIP：测试完整性 unzip -t archive.zip # gzip / bzip2 / xz：单文件流测试 gzip -t file.gz # tar：只列出，验证结构可读 tar -tf archive.tar.gz > /dev/null && echo "结构正常"外部校验值（发布方另外提供的 MD5、SHA-1、SHA-256）意义更大，因为它能证明"你下载到的字节"和"发布者手上的字节"完全一致。计算很简单，比对时注意大小写和是否带空格，这两个小细节造成的"校验不通过"假警报我见过很多次。
# Linux / macOS sha256sum downloaded.bin # Windows PowerShell Get-FileHash .\downloaded.bin -Algorithm SHA2563.3 "断点续传"制造的半包，以及为什么它看起来完全正常
网盘客户端和浏览器都支持断点续传，这个功能在弱网环境下是救命的，但它有一个副作用:续传时的偏移量如果和服务器端不一致，文件会被拼成"前半段来自第一次连接、后半段来自第二次连接"的缝合怪。这种文件的大小和原始文件完全一样，扩展名正常，双击也不报错，只有校验和对不上，或者解压到某个位置才开始报错。
识别这种损坏有个偏方:用十六进制查看器翻到文件中段，看有没有大片的00或者重复的固定字节序列。正常的压缩数据高度随机，出现长串重复几乎不可能。我在处理一次 6 GB 的素材包时就是靠这个发现的——文件中部有连续 40 MB 的00，那是客户端在续传时把未写入的区域补零了。这种包无论怎么修都救不回来，只能重新下载，而且重新下载时我会先清掉客户端的缓存分片。
4. 七类高频报错的逐条排查路径
4.1 "文件已损坏"和"不可预料的压缩文件末端"不是一回事
这两个提示看着像同义词，实际指向的故障完全不同。"不可预料的压缩文件末端"（unexpected end of archive）几乎百分之百是文件被截断——压缩包的中央目录在文件末尾，文件少了字节，目录就读不到。这种情况优先怀疑传输域:下载中断、复制过程被中断、U 盘拔早了、网盘同步没完成。判断方法很直接，看文件的实际大小和网盘上显示的大小是否一致，差一个字节都不行。
而"文件已损坏"或者"CRC 校验失败"通常意味着文件长度对但内容错了，可能是传输过程中的位翻转，也可能是打包时源文件就在变（比如打包一个正在被写入的日志文件）。这两种情况的处理方式也不同:截断的包基本没救，重下；CRC 错误的包可以尝试用修复功能抢救，虽然救回来的比例不高，但碰上只是末尾几个字节出问题的情况还是有机会的。
4.2 密码、加密文件名，以及"连目录都看不到"
加密分两个层级，很多人分不清。只加密数据的包，你打开时能看到完整的文件列表和目录结构，只是解压时需要密码；同时加密文件名的包（RAR5 的头加密选项、7z 的-mhe=on），你打开时连里面有几个文件都看不到，工具会直接要求输入密码。后者的安全性高得多，但也造成了一个常见困惑:有人拿到这种包，输错密码后以为是"文件损坏"，反复重装软件。
密码本身也有坑。中文密码在不同工具、不同系统上可能出现编码不一致，导致明明输对了也报错。我的做法是尽量不用中文密码，如果非用不可，先在打包端和解压端各测一次。另外，密码里如果含有!、$、&这类字符，在命令行里必须用单引号包起来，否则会被 shell 先解释掉，表现出来就是"密码错误"。
# 命令行传密码：单引号防止 shell 解释特殊字符 unrar x -p'P@ss!word&2024' archive.rar # 7z 指定密码 7z x archive.7z -p'P@ss!word&2024'4.3 中文文件名乱码:一个二十多年前的历史包袱
ZIP 格式诞生的时候没规定文件名用什么编码，Windows 上的实现用了本地代码页（简体中文环境是 CP936/GBK），而 macOS 和 Linux 上的实现默认用 UTF-8。于是同一个 ZIP，在 Windows 上打出来正常，在 Mac 上打开全是乱码，反过来也一样。RAR 和 7z 后来通过增加 Unicode 标记解决了这个问题，所以乱码几乎只出现在 ZIP 上，尤其是老版本 Windows 工具打出来的 ZIP。
解决办法有三条路。如果解压工具支持指定代码页，直接用参数指定;不支持的话，用 Python 的zipfile手动读取原始字节再重新编码，这个方案最可靠，因为它不依赖工具实现;最省事的办法是在 Windows 上解压这类包，因为绝大多数国产压缩包都是在 Windows 上打的。
import os, zipfile src = "legacy.zip" dst = "extracted" os.makedirs(dst, exist_ok=True) with zipfile.ZipFile(src) as zf: for info in zf.infolist(): # zipfile 在遇到非 UTF-8 标记时按 CP437 解码，这里还原成原始字节再用 GBK 解 try: raw = info.filename.encode("cp437") name = raw.decode("gbk") except (UnicodeEncodeError, UnicodeDecodeError): name = info.filename target = os.path.join(dst, name) if info.is_dir(): os.makedirs(target, exist_ok=True) continue os.makedirs(os.path.dirname(target) or dst, exist_ok=True) with zf.open(info) as fsrc, open(target, "wb") as fdst: fdst.write(fsrc.read()) print("done")4.4 路径长度、磁盘空间和杀软:三个最容易被误判成"包坏了"的原因
Windows 的路径长度限制是 260 个字符，这是历史遗留问题。一个嵌套了七八层的素材包，加上中文目录名，很容易超限，表现出来的症状是"解压到某个文件时失败"，报错信息通常很含糊。解决办法是把包解压到一个短路径（比如D:\x\）再移动，或者用支持长路径的工具配合系统设置里的长路径开关。
磁盘空间也常被误判。压缩包 2 GB，解压出来可能是 12 GB，文本类内容的压缩比能到 10:1 甚至更高。系统提示"磁盘空间不足"时，很多人第一反应是"包坏了"，因为报错弹窗的位置在解压进度条旁边。
杀软拦截则更隐蔽。解压出来的.dll、.exe被实时扫描拦下并被删除，解压工具认为"写入失败"，报错文本可能是"无法创建文件"。这类问题排查时先看杀软的隔离区有没有东西，比什么都快。
| 报错表现 | 最可能的原因 | 排查动作 |
|---|---|---|
| 不可预料的压缩文件末端 | 文件被截断 | 比对文件大小，重新下载 |
| CRC 校验失败（单文件） | 该文件数据损坏 | 单独重下该卷，或尝试修复 |
| 需要密码 / 密码错误 | 加密或头加密 | 确认是否启用"加密文件名" |
| 文件名乱码 | ZIP 编码页不一致 | 指定 CP936 或用脚本转换 |
| 无法创建文件 | 路径超长 / 空间不足 / 杀软 | 换短路径，查磁盘，查隔离区 |
| 缺少必要的卷 | 分卷缺失或不同目录 | 检查序号连续性，集中到同一目录 |
| 不支持该压缩方法 | 工具版本过旧 | 升级到支持 RAR5 / LZMA2 的版本 |
4.5 抢救:残缺压缩包能救回多少
必须说清楚:压缩包损坏后能修复的比例很低，尤其是固实压缩的包。但仍然值得试一次，成本只有几秒钟。RAR 系工具有一个"修复压缩文件"的功能，它会扫描整个文件，把能读出来的数据重新打包成一个新的压缩包，文件名通常带rebuilt前缀。这个新包的结构会乱，但里面的原始文件大部分是完整的，能捞出来多少算多少。ZIP 的情况稍好一些，因为有中央目录和本地文件头两份记录，中央目录坏了还能靠扫描本地头重建。
# zip 重建中央目录（适用于中央目录损坏但数据完整的情况） zip -FF broken.zip --out fixed.zip # 7z 对部分损坏的包做尽量提取，跳过错误继续 7z x broken.7z -y -bd -bso0 -bsp0 || true我在一次事故里救回过一个 3.8 GB 的素材包:中央目录完全损坏，但本地文件头还在，用zip -FF重建后捞回了大约 82% 的文件，剩下 18% 因为位于损坏区域附近而彻底丢失。这个过程有个前提——压缩时没有启用固实模式，否则一旦中间出问题，后面的数据全都无法定位。
5. 安装包类压缩包，为什么要单独对待
5.1 安装包和普通压缩包的三点本质区别
很多人把软件安装包当成"一个需要双击的压缩包"，这个理解偏差会带来一堆问题。第一，安装包里的内容是为安装过程服务的，它可能包含自解压逻辑、注册表脚本、服务注册代码，直接解压出来的文件不一定能独立运行——缺少了运行时的路径、注册项、依赖的 VC 运行库。第二，安装包是捆绑软件的重灾区，安装向导的默认勾选、隐藏的"推荐组件"、静默安装参数，都是普通压缩包里不存在的东西。第三，安装包的名字和内容经常对不上，一个叫setup.exe的文件可能只是一个下载器，真正的安装体在运行时才拉下来，这类包解压出来往往只有几百 KB。
理解了这三点，你就会明白为什么"从安装包里只拿需要的那个 dll"这种做法有时候成功有时候失败——成功的情况是那个 dll 本身没有外部依赖，失败的情况是它依赖同目录下某个被安装过程才写入的配置文件。
5.2 解包而不安装:几种常见安装器的处理方式
我在需要"看看这个安装包里到底装了什么"的时候，基本不会真的去跑安装流程，而是先解包。不同打包器的处理方式差异挺大，下面这张表是我实际用下来比较稳的对应关系。
| 打包器特征 | 识别方式 | 解包手段 |
|---|---|---|
| NSIS | 解压后出现$PLUGINSDIR、.nsi痕迹 | 直接用常规解压工具打开 |
| Inno Setup | 解压后出现embedded数据段 | 需要专用解包工具 |
| MSI | 魔数是D0 CF 11 E0 | 管理员安装方式提取文件 |
| 自解压 RAR/ZIP | MZ头 + 后续压缩数据 | 用解压工具直接打开 |
| 在线安装器 | 体积异常小，几百 KB | 内部没有安装体，解了也没用 |
MSI 的处理方式值得单独说一句，因为它不需要任何第三方工具。用管理员安装模式可以把整个安装内容展开到指定目录而不真正安装，这个命令我用了很多年，稳得很:
# 把 MSI 的内容展开到 D:\extract 而不注册任何东西 msiexec /a "installer.msi" /qb TARGETDIR="D:\extract"展开之后你会看到完整的文件树，包括那些在正常安装时才会被放进去的组件。我通常用这个方法来确认一个安装包里到底有没有多余的东西、体积都花在哪、有没有意料之外的第三方模块。
5.3 关于来源:为什么"绿色版""免安装版"风险最高
网盘上流转的软件安装包，最大的风险不在技术层面，而在来源层面。一个被重新打包过的"绿色版"，可能被塞进了主页锁定、启动项注入、浏览器插件，这些东西不会在安装界面告诉你。我在实际处理这类文件时有三条固定原则:优先从官方渠道拿原始安装包;拿到之后先算一遍校验值，和官方公布的比对;如果无法校验来源，一律先解包看结构，绝不直接双击运行。
解包看结构的成本很低，收益很高。正常情况下，一个正经的安装包内部结构应该是干净的——安装程序主体、资源文件、语言包、许可协议文本。如果解压出来发现里面有一堆名字含糊的可执行文件、批处理脚本、指向陌生地址的配置文件，那就该警惕了。这种做法不能保证百分之百安全，但能过滤掉绝大部分粗制滥造的改包。
说个实操细节:解包检查时不要只看文件名，看一眼文件的修改时间和数字签名。正规发布方的文件时间戳通常集中在构建那几天，签名信息完整;改包的时间戳往往乱七八糟，签名要么缺失要么被破坏。
6. 把流程固化下来:目录约定加批量脚本
6.1 一套用五年的目录约定
零散地处理压缩包，效率低且容易出错。我本地有一套固定的目录结构，所有下载、解压、校验都按这套约定走，好处是任何一步出问题都能快速定位，而且脚本可以直接按路径约定跑，不用每次改参数。
D:\work\ ├── 00_inbox\ # 下载完成的原始包，只读，不做任何修改 ├── 10_verify\ # 校验报告、哈希值、日志 ├── 20_extract\ # 解压目标，按包名建子目录 ├── 30_fixed\ # 修复产物（rebuilt / fixed 前缀的文件） └── 90_trash\ # 确认无用的中间产物，定期清空00_inbox设为只读是个小技巧，能防止手滑把原始包改坏。所有解压都输出到20_extract，这样即使解压失败，原始包依然完好，可以反复重试。10_verify里我会给每个包留一个同名.sha256文件，几个月后回头查"这个包当时是不是完整的"，一秒就能确认。
6.2 批量校验加批量解压，一条命令搞定一个目录
单次解压手动点几下没什么，但一次处理二三十个包的时候，图形界面就成了负担。我写了一个不长的脚本，做三件事:扫目录、按文件头判断真实格式、调用对应的工具做完整性测试。格式判断这一步是必须的，因为网盘下载的文件扩展名经常是乱的，直接按扩展名调用工具会失败。
import os, subprocess, sys MAGIC = [ (b"PK\x03\x04", "zip"), (b"Rar!\x1a\x07\x00", "rar"), (b"Rar!\x1a\x07\x01\x00", "rar5"), (b"7z\xbc\xaf'\x1c", "7z"), (b"\x1f\x8b", "gzip"), (b"\xfd7zXZ\x00", "xz"), ] def sniff(path): with open(path, "rb") as f: head = f.read(8) for magic, name in MAGIC: if head.startswith(magic): return name return None def test(path, kind): cmd = { "zip": ["unzip", "-t", "-qq", path], "rar": ["unrar", "t", "-idq", path], "rar5": ["unrar", "t", "-idq", path], "7z": ["7z", "t", path, "-bd", "-bso0"], "gzip": ["gzip", "-t", path], "xz": ["xz", "-t", path], }[kind] r = subprocess.run(cmd, capture_output=True) return r.returncode == 0 folder = sys.argv[1] for name in sorted(os.listdir(folder)): full = os.path.join(folder, name) if not os.path.isfile(full): continue kind = sniff(full) if kind is None: print(f"[SKIP] {name} 不是可识别的压缩格式") continue ok = test(full, kind) print(f"[{'OK ' if ok else 'FAIL'}] {name} ({kind})")跑完之后FAIL的那些就是需要重新下载的，SKIP的那些多半是扩展名被改过的文件，用 6.1 的魔数表再确认一次。这套流程跑顺之后，我处理一批 20 GB 的素材包从原来的两小时压缩到二十分钟，绝大部分时间花在等校验上。
6.3 几个只有踩过才记住的细节
第一个细节:解压目标目录不要和源目录在同一层且同名。有些工具会聪明反被聪明误，把解压结果写进源目录，导致源目录里既有压缩包又有解压产物，再跑一次批量脚本就会把产物当压缩包扫一遍，输出一堆无意义的报错。
第二个细节:处理带密码的批量任务时，别把密码写在脚本里。把密码放在环境变量里读取，或者交互式输入，这既是安全习惯也是工程习惯。脚本一旦泄露，里面的明文密码就是个定时炸弹。
第三个细节:大包解压前先看一眼磁盘剩余空间。我写了个小检查塞在脚本开头，剩余空间小于包体积 × 3 就直接退出。这个系数不是拍脑袋来的:文本类内容压缩比常在 5:1 到 10:1 之间，媒体类接近 1:1，取 3 倍是个能覆盖大多数场景又不会过于保守的折中值。
第四个细节:解压完成后不要马上删原始包。至少保留到内容确认可用为止。我见过一次因为原始包被删、解压出来的目录又有问题，导致一批资料彻底丢失的情况，重下花了两天。
7. 关于压缩这件事，我个人的几条经验
写到这里，前面讲的都是"怎么把已经出问题的包救回来"。但更省事的做法是从源头减少出问题的概率，这部分内容我在实际操作中体会最深。
打包给别人传文件时，我现在的默认选择是 ZIP 而不是 RAR。原因很实际:RAR 需要额外的工具才能打开，对方如果没有对应软件就得先装一个，而 ZIP 在三大操作系统上都是原生支持。牺牲一点压缩率换对方一次打开成功，这笔账很划算。如果确实需要更高压缩率，我会选 7z，并且在打包时明确关掉固实模式——压缩率会降几个百分点，但容错能力大幅提升，对方解压时遇到局部损坏不会全盘皆输。
打包时还有一个习惯:文件名只用英文字母、数字、下划线和短横线，目录层级控制在三层以内。这个习惯是被乱码问题逼出来的，一旦文件名里混进中文、日文、特殊符号，跨系统传输时就有一半概率出乱码。三层目录的限制则是因为路径长度，深层嵌套加长文件名很容易在 Windows 上撞到 260 字符的天花板。
给别人发链接的时候，我会把"文件多大、共几个分卷、校验值是多少"三件事一起发过去。这三条信息能让对方在下载完成后自己确认完整性，省掉后面"我这边打不开你那边能打开吗"的来回扯皮。这个习惯看起来啰嗦，但它把一次沟通成本从半小时降到两分钟。
最后一个经验，也是我认为最重要的一条:别迷信任何号称"万能"的工具。工具能解决的是格式兼容问题，解决不了文件本身损坏、分卷不全、密码错误、磁盘满了这些情况。真正管用的做法是把"校验—识别—解压—验证"这四步变成肌肉记忆，出了问题按顺序走一遍，绝大多数情况五分钟内就能定位到具体是哪一环。这套流程我用了很多年，比装十个解压软件都管用。
