解锁 PDF

受密码保护的 PDF 到底存了什么

加密的 PDF 在它的 trailer 里保留一个 /Encrypt 字典，描述这份文件当初是怎么被保护的：普通密码情形下是 /Filter /Standard，一个 40、128 或 256 位的密钥，以及一个说明用了哪套规则的修订号——RC4 是 2 和 3，AES-128 是 4，AES-256 是 6。两把密钥从两个密码派生出来，每一个字符串和流都用由它们构建的密钥加密。

这就是为什么知道密码就足够了。没有任何东西需要被攻破，也不涉及暴力破解：文件携带了重新计算密钥所需的一切，密码就是那个缺失的成分。这也是为什么这个工具帮不了一份你不知道密码的文件，以及为什么受证书保护的文件会被直接拒绝——那里的密钥根本不是从密码派生出来的，所以任何密码都不会起作用。

出来的副本里不再有加密，这也是「解锁」唯一诚实的含义：所有者密码所携带的那些限制——不许打印、不许复制、不许编辑——随之消失，因为一份没有加密的 PDF 没有任何地方保存它们。

解锁器本身，以及这个页面为什么还照常工作

解密由一套完整的 PDF 解密引擎完成，它就在这个浏览器标签页里运行。它就是真正的解密工具本身，不是简化的替代品；第一次解锁时，它作为本站的一个资源被这个页面取用——原始体积约 1.2 MB，上线传输约 340 KB。

这个构建刻意保持轻量：它不需要特殊的浏览器隔离，站点上其他任何东西都不必为它调整。每个任务都会启动一份全新的引擎副本，因为一次解密结束之后它就不能再复用；在一份 3 KB 的 AES-256 文件上实测，浏览器里加载加解密约 40 毫秒，命令行环境里约 23 毫秒。

引擎把结果报告为一个状态码，而不是这个页面能读的东西：0 表示干净，3 表示它修复了文件但给了警告，2 表示它拒绝了。只有 0 被接受。一份只能靠猜测修复的文件——看起来就像一次从未完成的下载——会被连同一句解释丢掉，而不是被转交出去。

任务与你的下载之间的三道检查

首先，副本必须不再有任何 /Encrypt 条目，这样它就不能再向你要密码。接着，副本必须能被另一个独立的 PDF 阅读器在完全没有密码的情况下打开。最后，它要报告与「用你的密码读取原件」时相同的页数、相同的首页尺寸和相同的首页文字。

这些读数会逐字符精确比对，任何不一致都会以互相矛盾的数字结束任务：「原件 12 页，副本 11 页」，或者「首页文字不同」。这种情况下不会出现下载，因为一份能打开、却不是同一份文档的文件，是唯一比报错更糟的结果。结果面板还会说出文件用的是什么——AES-256、修订 6，或者 RC4-40、修订 2——这些是从文件自己的加密字典里读出来的。

多数工具跳过的那一步：密码规范化

PDF 2.0 要求密码在派生出密钥之前先被准备好，用的是 SASLprep 规则（NFKC 加一组 Unicode 映射）。许多 PDF 阅读器和写入器跳过了这一步，这个工具所用的引擎也是，于是留下了一个陷阱：在你的 PDF 阅读器里能打开文件的密码，可能被一个原样转交它的解锁器拒绝。

在一份专门为此构建的样本上实测：一份密码是「a」、却被输入成 U+00AA（阴性序数词，NFKC 会把它折叠成「a」）的文件，被那个引擎判为密码无效（状态码 2）而拒绝，先跑一遍规范化之后就能干净地解锁（状态码 0）。所以这个工具会先试你输入的内容，再试它规范化后的形式，最后试空密码——一份文件可以完全没有用户密码——并告诉你其中哪一个起了作用、为什么。