ZIP 长密码恢复：正确密码已在字典中，为什么仍未命中？
恢复模块不支持密码长度时，字典即使包含正确密码也可能未命中。指定 John 1.9.0-jumbo-1 PKZIP 构建找到了 31 字符对照，却没有命中正确的 32、51、52、127 字符候选；这些原始压缩包均能独立完整解密。
把答案直接放进字典
我们自行创建五个传统 ZipCrypto 压缩包，内容为相同的虚构文本，密码长度分别为 31、32、51、52、127 个 ASCII 字符，全部为公开测试值。不使用客户压缩包、密码或私人线索。
每份字典只放一个错误值和准确已知密码，并为各对照使用独立会话和空的 potfile，避免旧记录造成假成功。测试构建为 John the Ripper 1.9.0-jumbo-1、cygwin 64 位 x86_64 AVX2 AC OMP。另用 Python ZIP 读取器解密原文件，核对全部正文与 CRC，以排除样本损坏或已知密码本身错误。
观察到的结果与适用范围
本地查询的格式信息报告该构建的 ASCII 密码上限为 31 字符。Openwall 对相应 PKZIP 实现的资料也讨论了同类限制。结论只针对指定模块和构建，不代表所有 John 版本、所有 ZIP 加密方式或 ZIP 格式本身存在相同上限。
限制属于恢复路径。127 字符样本能用已知密码读取全部原始内容，证明它是有效的加密压缩包，不能因为一个工具未命中就认定文件或密码无效。
| 密码长度 | 已提供正确候选 | John PKZIP 是否命中 | 原文件完整校验 |
|---|---|---|---|
| 31 | 是 | 是 | 通过 |
| 32 | 是 | 否 | 通过 |
| 51 | 是 | 否 | 通过 |
| 52 | 是 | 否 | 通过 |
| 127 | 是 | 否 | 通过 |
短头部匹配为什么不是恢复成功
传统 ZIP 加密头包含很短的密码检查字段，可用于快速筛选，但无关候选也可能偶然匹配。独立长密码筛选器找到了全部五个对照的正确候选，我们仍要求读取原始成员并检查完整内容和 CRC 后，才能标记验证通过。
筛选器还必须正确处理 ZIP 标志位：根据数据描述符标志，所用检查字节来自不同字段。因此头部命中不等于独立成功证明；有已知答案的阳性对照，比假设自写代码正确更可靠。
未找到 ZIP 密码时应先检查什么
依次确认压缩格式和加密类型（ZipCrypto 与 ZIP AES 不同）、模块支持的长度与字符编码；制作同长度已知密码的非私密对照；把准确密码放进小字典并使用空结果库；命中后读取完整原始内容；若对照不命中，先查工具配置，再评价大字典的排除范围。
ASCII 对照不能证明 Unicode 支持。本实验不测定 WinRAR 或 7-Zip 的通用密码长度上限，也不测速 ZIP AES，更不证明任何长密码都能恢复。它说明特定工具限制可能让一次阴性测试失去排除意义。
下载公开对照与筛选实现
每份 ZIP 的准确测试密码和 SHA-256 指纹都在原始 JSON 报告中；不要将这些公开密码用于真实文件。下方提供五份原文件，以及可供核查的筛选代码。
代码只做候选过滤，不能取代完整解密验证。样本矩阵同时包含成功对照和指定旧模块的预期未命中，不是软件产品排名。
参考资料与进一步核查
适用范围与编辑独立性
我们同时提供密码找回服务。实验只使用自行生成的公开样本，不使用客户文件。结果仅描述指定日期、软硬件和样本条件，不能推导总体成功率、搜索排名或找回保证。