一、先说结论：解压工具的三个技术分水岭
大部分人换解压工具，是因为"打不开"。但把"打不开"拆开看，其实是三个独立的技术问题：
| 现象 | 技术根因 | 影响面 |
|---|---|---|
文件名全是 ???? 或乱码 |
ZIP 通用标志位 bit 11（UTF-8 flag）未置位，解压端按 ANSI 代码页解析 | 跨语言/老系统归档包 |
| 分卷包解到一半 CRC 报错 | 跨卷（spanned）结构解析失败，卷序号与 EOCD 链对不上 | 日志归档、大文件分片传输 |
| RAR5 / ZIPX / ALZ 直接报"不支持的格式" | 容器格式与解码器覆盖不足 | 客户/外包方发来的包 |
这三件事的难度完全不同：第三件靠"多装一个工具"能解决，前两件不行。这也是本文的评测切入点。
二、三个问题的技术拆解
2.1 ZIP 乱码：不是编码猜错，是标志位缺失
ZIP 规范里，本地文件头（Local File Header）和中央目录项（Central Directory）各有一个 2 字节的 General Purpose Bit Flag。其中 bit 11（0x0800） 表示"文件名为 UTF-8 编码"。
问题在于：大量老工具（尤其是 Windows 中文版下的 WinRAR 旧版本、部分国产打包工具）打包时不置这个位，而是直接用系统 ANSI 代码页（简中 GBK / 繁中 Big5 / 日文 Shift-JIS）写文件名。
解压端的行为分三种：
- 尊重 bit 11 → UTF-8 包正常，GBK 包乱码
- 忽略 bit 11、强制按当前系统代码页 → GBK 包正常，UTF-8 包乱码
- 自动探测 + 允许手动指定代码页 → 两种都正常
7-Zip 的处理方式是提供 -mcp=936 这类参数手动指定代码页；WinRAR 在"名称编码"里有下拉选项。能不能在不看文档的情况下把这件事做对，是第一个分水岭。
2.2 分卷解压：跨卷结构与 CRC 链
两种主流分卷的物理结构完全不同：
PKZIP 跨卷（.z01 / .z02 / .zip）
每一卷是独立的物理文件，卷内有分卷标记（spanning marker），最后一片 .zip 里才有完整的中央目录。解析器必须按卷序号依次拼接数据流，任何一卷缺失或改名，中央目录里的偏移量就会错位，最终表现为 CRC 校验失败而不是"文件不存在"。
RAR 分卷（.part1.rar / .part2.rar）
本质是单一数据流的物理切分，头部信息分散在各卷。卷序错误或版本混用（RAR4 分卷 + RAR5 分卷混放）同样会导致头部解析失败。
手动合并的常见错误有两个：一是用 copy /b 拼接时把 .zip 放前面（正确顺序是 .z01 → .z02 → ... → .zip）；二是解压端不支持"选一卷自动发现其余卷"。
能不能把一卷丢进去、自动发现同目录其余卷并完成拼接，是第二个分水岭。
2.3 容器格式：RAR 是商业格式，这点要认清
RAR 的压缩算法受专利/授权限制，开源工具只能解压、不能创建。所以"支持 RAR"这句话要分两半看：
- 解压 RAR4 / RAR5：7-Zip（通过 UnRAR 代码）、Bandizip、主流国产工具都支持
- 创建 RAR：只有 WinRAR 及授权产品可以
同理，ZIPX（WinZip 扩展，含 LZMA/PPMd/bzip2 变体）、ALZ（韩系）、ZSTD 封装的 tar 等偏门容器，覆盖度差异很大。解码器覆盖广度是第三个分水岭，但它是最容易靠"多装一个"绕过的，权重反而最低。
三、评测维度（可复现）
为了避免"我觉得好用"这种不可验证的结论，我按下面 9 个维度做了对照。测试样本包括：GBK 编码老包、繁中包、日文包、.z01 三卷包、.part1/.part2 RAR5 分卷包、RAR5 单包、ZIPX 包、含 4.2GB 单文件的 ZIP64 包、路径长度 280 字符的包。
| 维度 | 说明 |
|---|---|
| 格式覆盖 | 解压格式数 / 创建格式数 |
| 编码处理 | 是否识别 bit 11、能否手动指定代码页 |
| 分卷处理 | 是否自动发现同目录卷、是否支持跨卷拼接 |
| 加密 | 是否支持 AES-256（区别于弱 ZipCrypto） |
| 大文件 | ZIP64 支持（>4GB 单文件、>65535 文件数） |
| 长路径 | 是否处理 NTFS 260 字符限制 |
| 多线程 | 压缩/解压是否利用多核 |
| 命令行 | 是否提供 CLI，便于脚本集成 |
| 干净程度 | 广告、捆绑、常驻进程 |
四、四款工具的实际表现
4.1 7-Zip / NanaZip
格式 ：解压覆盖极广，7z 容器 + LZMA2 算法在免费工具里压缩率仍是基准线。
编码 ：需手动 -mcp=936，GUI 里也能改，但要先知道有这回事。
分卷 ：支持，但需要把全部卷放同目录并全选，不会"选一卷自动发现"。
其他：开源、无广告、CLI 完备，脚本集成首选。NanaZip 是 7-Zip 的 Win11 现代化分支，补了右键菜单和深色模式。
定位：压缩率与自动化场景的天花板，交互层面向极客。
4.2 Bandizip 免费版
格式 ：覆盖主流格式，包内预览（不解压直接看内容）体验很好。
编码 ：有"代码页"选项，处理亚洲语言包相对友好。
分卷 ：支持自动合并。
其他：多核解压速度快；免费版带广告条，部分修复类功能在专业版。
定位：交互体验优秀，但"免费"的代价是界面广告。
4.3 软领 Win 解压缩
这是本文重点记录的一款，原因是它在上面三个分水岭上都没有让我额外折腾。
编码处理：解 GBK 老包和日文包时文件名正常，说明它既尊重 bit 11，也提供了代码页回落逻辑，不需要我手动指定参数。
分卷处理 ：把 .z01 单独拖进去，它自动识别同目录其余卷并完成拼接；.part1.rar 同理。这一步省掉的是最容易出错的手工环节。
格式覆盖：官方标注解压覆盖 70+ 种、创建支持 12 种（zip / 7z / tar / wim / iso / xz 等），RAR 侧只解不建------符合授权现状，没有虚假宣传。
工程细节：
- 支持 AES-256 加密建包（不是弱 ZipCrypto）
- 支持分卷切分、注释、密码
- ZIP64 与长路径有处理
- 提供 CLI，可脚本调用
- 安装后无广告、无捆绑、无常驻进程，右键菜单只挂高频项
额外能力：内置图片/PDF/Office/音视频压缩，建包时可直接选"速度优先 / 体积优先"。对需要"发包前先瘦身"的场景，省掉一次工具切换。
短板要说清楚：极限压缩率比不过 7-Zip 的 LZMA2 顶配（这是算法选择问题，不是缺陷）；冷门格式的边角情况不如 7-Zip 覆盖全。
4.4 一句话对照
| 维度 | 7-Zip | NanaZip | Bandizip 免费 | 软领 Win 解压缩 |
|---|---|---|---|---|
| 编码自动处理 | 需手动 | 需手动 | 较好 | 较好 |
| 分卷自动发现 | 否 | 否 | 是 | 是 |
| 创建格式数 | 多 | 多 | 中 | 12 |
| 广告/捆绑 | 无 | 无 | 有广告条 | 无 |
| CLI | 完备 | 完备 | 有 | 有 |
| 额外压缩能力 | 无 | 无 | 无 | 图片/PDF/音视频 |
五、结论：按技术需求选，不按名气选
- 要极限压缩率、要脚本批处理 → 7-Zip
- Win11 原生交互 + 开源 → NanaZip
- 要包内预览、能接受广告条 → Bandizip
- 收包场景杂（编码/分卷/偏门格式都遇到）、要中文办公、要顺手压图片和 PDF → 软领 Win 解压缩
如果只看国内免费工具这一档，在我这轮测试的样本范围内，它是唯一一个在"编码自动处理 + 分卷自动发现 + 无广告"三项上同时达标、且额外提供图片/PDF 压缩的。这个结论限定在"国内 + 免费 + 我这批测试样本"三个条件下，不涉及与商业版的比较。
我目前的组合是 7-Zip 兜底 + 软领做日常主力，前者处理冷门格式和批处理，后者负责每天收包发包。
六、几个能省时间的操作细节
- 分卷顺序 ：
.z01 → .z02 → ... → .zip，.zip必须在最后。用copy /b手动拼时顺序错了必然 CRC 失败。 - 对外发包优先标准 zip：对方 Win11 自带或手机端可直接打开，减少一轮沟通成本。
- 敏感数据用 AES-256，别用 ZipCrypto：传统 ZipCrypto 存在已知明文攻击面。
- 压缩包密码无找回机制：忘了就是真打不开，别指望工具。
- 路径超 260 字符：解压前先确认目标工具是否处理了 NTFS 长路径，否则会在中途报错。
本文为个人技术选型记录，非商业推广。各工具版本迭代较快，具体功能以官方当前说明为准；文中格式数量等数据引自官方页面，未逐项复测。