我们的做法
这个网站做的事，在技术上平平无奇。少见的是从头到尾不接收您的文件，并且把界限说得一清二楚。
四条搭建规矩
文件不离开设备
浏览器会读文件、解码、变换，还会做出一份下载。这些全在那里完成。没有哪台服务器收到任何东西，因为这个网站就是一堆静态文件。
对网络零依赖
没有从第三方加载的库，没有远程字体，没有远程图片，没有嵌入的访问统计。页面加载的东西全部来自这个域名，此外什么也不加载。
代码是拿来读的
没有压缩，也没有混淆。一件工具就是一个文件，文件名跟着它自己的名字。正是这一点，让没写过这个网站的人也查得了。
每件工具自报它的格式和它的限制
绝不写“支持所有格式”。一种浏览器打不开的格式，不会因为有人把它写在首页上就变得可行。
兼容性对照表
它是第一件工具动笔之前那轮核查的成果，而且带日期。浏览器一直在变：每次复核它都重新核对，从不照抄上一版。
兼容性核对于 July 30, 2026
浏览器打得开的图片格式
这一项决定了一件工具能不能显示您的文件、能不能在上面干活。这里没有的格式不是“快了”：它就是不在。
| Chrome、Edge | Firefox | Safari（macOS、iOS） | |
|---|---|---|---|
| JPEG（.jpg） | yes | yes | yes |
| PNG（.png），包括会动的 | yes | yes | yes |
| WebP（.webp） | yes | yes | yes |
| Safari 从第 14 版起支持，系统要 macOS Big Sur 以上。 | |||
| AVIF（.avif） | yes | yes | yes |
| Chrome 85、Firefox 93、Safari 16.1。 | |||
| GIF（.gif） | yes | yes | yes |
| BMP（.bmp） | yes | yes | yes |
| SVG（.svg） | yes | yes | yes |
| ICO（.ico） | yes | yes | yes |
| TIFF（.tif、.tiff） | no | no | yes |
| Safari 是唯一显示得出 TIFF 的浏览器。而 TIFF 的元数据到哪儿都读得了：它们在文件头里，不在图像里。 | |||
| HEIC、HEIF（iPhone 拍的照片） | no | no | yes |
| Safari 17 和 iOS 17 显示得出来。Chrome、Firefox 和 Edge 从来没有解码过它们，原因是这个编解码器上的专利。软件解码器有十兆字节开外：放弃，并且写出来。 | |||
| JPEG XL（.jxl） | partly | partly | yes |
| 2026 年 7 月 30 日更新。这一堆里最不稳定的格式：2022 年被从 Chromium 里撤掉，后来一个用 Rust 写的解码器在 2026 年 2 月回到了 Chrome 145、6 月回到了 Firefox 152，但两边都默认关闭，藏在一个开关后面。Safari 从第 17 版起默认显示它。没有哪个浏览器写得出它。只要情况还在动，本站就没有一件工具依赖它。 | |||
浏览器写得出来的格式
这一项决定了一件工具能把您的图片转成什么。这里的坑是无声的：浏览器写不出所要的格式时，会一声不吭地给出一个 PNG。所以我们的工具去核实结果的类型，而不是选择相信。
| Chrome、Edge | Firefox | Safari（macOS、iOS） | |
|---|---|---|---|
| 写出 PNG | yes | yes | yes |
| 这是规范唯一强制要求支持的格式：所以它也是那个万能的退路。 | |||
| 写出 JPEG | yes | yes | yes |
| 写出 WebP | yes | yes | no |
| Chrome 50、Edge 79、Firefox 96。Safari 没有一个版本能从画布里写出 WebP，Mac 上不行，iPhone 上也不行。这是整张对照表里最有用的一行：一个把“WebP”挂出来却不说明这一点的转换器，是在对每两个 iPhone 访客里的一个撒谎。 | |||
| 写出 AVIF | no | no | no |
| 此行于 2026 年 7 月 30 日更正。“Chrome 从第 124 版起能从画布里写出 AVIF”这个说法到处流传、被一个网站抄给另一个网站，而我们没有找到任何第一手来源：Chrome 的功能登记里没有，版本说明里没有，专门的兼容性页面上也没有。所以我们的工具不依赖它：它们在运行时实测浏览器写得出什么，而不是想当然。如果哪天有浏览器提供了这个能力，转换工具会自动把它列出来，一行代码都不用改。 | |||
工具所依赖的那些浏览器能力
| Chrome、Edge | Firefox | Safari（macOS、iOS） | |
|---|---|---|---|
| 原生加密（AES-GCM、从密码派生密钥、SHA-256） | yes | yes | yes |
| 从 2017 年起到处都有，但只在以 HTTPS 送达的页面上可用。本站正是如此。 | |||
| 原生压缩与解压（gzip、deflate） | yes | yes | yes |
| 所有浏览器都有。2026 年 7 月 30 日补上的一点有用说明：裸 deflate 这个变体，也就是做 zip 唯一用得上的那个，来得比其余的晚（Chrome 103、Firefox 113、Safari 16.4）。所以一段 2020 到 2022 年之间写的 zip 代码，可能会在一个明明宣称会压缩的 Chrome 上失败。 | |||
| 离屏图像处理（在单独的线程里） | yes | yes | yes |
| Chrome 69、Firefox 105、Safari 16.4。正是它让大文件不会把页面卡住。 | |||
| 由系统提供的条码和二维码识别 | partly | no | no |
| 2026 年 7 月 30 日收紧，而且比我们原先写的更严。这个功能不是一项网页标准：它靠的是操作系统，所以它只存在于 macOS、ChromeOS 和安卓上的 Chromium。Windows 和 Linux 上没有，也就是大多数台式电脑上都没有。Firefox 从来没有实现过它。Safari 从第 17 版起有一个藏在开关后面的实验版本，而它从 iOS 18 起就是坏的。所以一件二维码工具没法依赖它：那就得自带一套识别。 | |||
| 通过真正的“另存为”窗口保存 | yes | no | no |
| 只有 Chromium 有；Firefox 和 Safari 拒绝了这套接口。退路是传统的下载，那到哪儿都行：所以我们的工具默认用的就是它。 | |||
| 把文件一块一块地做散列 | no | no | no |
| 浏览器算 SHA-256 指纹算得很好，但只能对一次性交给它的完整文件：根本没有哪个函数能一点一点往里喂。这就是指纹工具必须有一个体积上限的原因，而那条限制写的正是这个理由。 | |||
| 流式加密文件，不必整个装进内存 | no | no | no |
| 跟散列是同一条限制：浏览器的加密作用在一整块数据上，而“出一个流式版本”的诉求从 2016 年起就开着，没有回音。自己动手切块是可以的，但每一块都得跟它的位置绑起来，否则可以抽掉几块或者调换顺序而校验标签毫无察觉。我们的加密工具宁可写出一个老实的体积上限，也不去临时发明这样一套构造。 | |||
| 浏览器里的现代密钥生成（Argon2） | no | no | no |
| Argon2 是如今“从密码生成密钥”的首选推荐，而它在任何浏览器里都不存在：那得内嵌一个 WebAssembly 引擎。所以我们的加密工具用 PBKDF2 配 SHA-256、六十万轮，这是这一领域的权威在 2026 年公布的数值，而且工具把它显示在屏幕上，不让人以为更好。 | |||
| 从画布写出一个 ICO 图标文件 | no | no | no |
| 没有哪个浏览器写得出 ICO：得围着若干张 PNG 图片手工把容器拼出来。ICO 里放 PNG，Windows Vista 起就支持，Firefox 从 9 起支持；至于 Chrome、Edge 和 Safari，我们只找到用法上的证据，没找到工程资料。许诺一个图标生成器之前，得先知道这一点。 | |||
| 计算 CRC-32，zip 里非有不可的东西 | no | no | no |
| 浏览器只提供密码学摘要（SHA-1 和 SHA-2）。所以 zip 文件在每个头部里都要求的那个 CRC-32，必须用普通的 JavaScript 手工写出来。三十来行就写得完，而这正是“不用库也能做出一个 zip”所缺的最后一块砖。 | |||
内存上的限制，那些真会让标签页崩溃的东西
它们没有写进任何一份标准，正因如此才有那么多转换器在手机上一声不吭地崩掉。本站每件工具都写明自己的上限，超过就干脆拒绝。
| Chrome、Edge | Firefox | Safari（macOS、iOS） | |
|---|---|---|---|
| 画布的最大面积 | yes | yes | partly |
| 在 iPhone 和 iPad 上，画布的面积很长时间都被限死在 1670 万像素（也就是 4096 乘 4096）；iOS 18 把它提到了 6710 万。一张 5000 万像素的照片仍然越过旧的上限：一件要重画图片的工具，必须先把它改小，或者说不行。 | |||
| 所有画布加起来能占的内存 | yes | yes | partly |
| iOS 上的 Safari 给一个标签页里所有画布的总量设了上限，视设备而定，大约几百兆字节。所以批量处理必须在换下一张之前就把每一张释放掉，而不是等到最后。 | |||
浏览器里的 PDF，以及各个库的真实状况
浏览器对一份 PDF 什么都不会做，除了把它显示出来。任何加工都需要内嵌代码，而这是本站的原则唯一允许的例外。以下是 2026 年 7 月 30 日那次核查确认的事实，以及 PDF 专区为什么在等一个决定，而不是半开着。
| Chrome、Edge | Firefox | Safari（macOS、iOS） | |
|---|---|---|---|
| 不用任何库就合并、切分或者修改一份 PDF | no | no | no |
| 浏览器里没有任何东西读得懂 PDF 的结构。显示不等于读取：内置的阅读器不把自己的任何能力借给一个网页。 | |||
| 项目技术卡当初设想的那个加工库 | partly | partly | partly |
| 新事实，而且它改变了决定。这个库采用 MIT 许可，会的东西不少：合并、切分、旋转、绘制、填写表单、写入元数据。但它最后发布的版本是 2021 年 11 月的，而它的作者自 2024 年 5 月起联系不上：项目原本打算内嵌的这段代码，四年多没有收到过任何一次修正。它既不会加密也不会解密 PDF，跟它自己的文档写的一样。 | |||
| 给 PDF 加上或者去掉密码 | partly | partly | partly |
| 在本地技术上是做得到的，这一点出乎我们的预料。这个库有一个仍在维护的延续版本，同样采用 MIT 许可，实现了直到 AES-256 的 PDF 加密，也打得开受保护的文件。所以这不再是技术上的不可能：它成了一个决定，也就是要不要内嵌一个年轻的延续版本、而不是原则里点名的那段代码，并让它成为本站好些年里唯一的依赖。这个决定属于协会，不属于工坊。 | |||
| 把 PDF 的页面变成图片 | partly | partly | partly |
| 用一个加工库做不到，它不是渲染引擎。那得内嵌 Firefox 阅读器的那个引擎，压缩之前大约 1.7 兆字节的代码，只为一件工具：那是一整个网站的分量。要单独重新审视，绝不偷偷来。 | |||
| 真正给一份 PDF 瘦身 | partly | partly | partly |
| 一个加工库可以把文件内部的对象归拢起来，这在表单很多的 PDF 上能省一点。它既不重压图片也不重压字体，而这两样占了一份普通 PDF 绝大部分的体积。所以在一份扫描件上，基本没什么可省的，而一件许诺相反结果的工具是在撒谎。 | |||
| 真正清干净一份 PDF 的元数据 | partly | partly | partly |
| 有两个坑，只有读代码才看得出来。首先，这个库每次打开文件时都会自作主张地重写一个生成软件和一个修改日期，哪怕没有人要求过。其次，它从来不碰 PDF 那个现代的元数据块，而那里可能装着跟别处一样的标题和作者：一次只清到前者就停下的清理是假的，而这一点得靠回读产出的文件来证明。 | |||
| 用内嵌的那个库把 PDF 页面画成图片（栅格化） | no | no | no |
| PDF 专区那个库是做 PDF 的，它不绘制页面：它的公开接口里没有导出任何渲染符号。栅格化需要第二个引擎，按它公布的文件量出来的真实体积是压缩后 1.72 MB（接口 454669 字节，工作线程 1262398 字节），压缩传输约 502 KB。所以“PDF 转图片”被放弃了，并且写了出来。 | |||
| 在浏览器里用 AES-256 加密一份 PDF，并把它打开 | yes | yes | yes |
| 用内嵌的那个库做得到，但只到修订 5（Adobe 2008 年的扩展），不是 PDF 2.0 标准里的修订 6。修订 5 用一遍 SHA-256 来校验密码；修订 6 用的是迭代散列，而攻击工具的公开基准测试显示，两者在试密码的速度上差了四到五个数量级。修订 5 是 PDF 2.0 标准唯一弃用的那个。算法由文件的头部决定：实测下来，只有“1.7ext3”这个字符串才触发 AES-256，否则得到的是 RC4 或者 AES-128。 | |||
| 在浏览器内置的阅读器里打开用 AES-256 修订 5 加密的 PDF | yes | yes | partly |
| 在各引擎的源代码里核实过：PDFium（Chrome、Edge）在它的密码校验里就处理修订 5，而 pdf.js（Firefox）带着一个专门针对修订 5、跟修订 6 分开的类。Adobe Acrobat 从第 9 版起打得开。至于 macOS 和 iOS 的预览，以及安卓上的阅读器，没有找到任何第一手资料：所以 Safari 那一栏写的是“部分”，本站也不多说一个字。 | |||
| 不内嵌字体引擎，就在 PDF 里写带重音或者非拉丁的文字 | partly | partly | partly |
| 这个库对任何自定义字体都要求一个字体引擎，而我们不内嵌它；没有它，就只有 PDF 的 14 种标准字体，走 Windows-1252，也就是大约 218 个拉丁字符。这套之外的字符在已发布的版本里不会抛出错误：代码把异常接住，写了一个问号进去。所以一件要写文字的工具，必须校验输入，并把自己写不出来的东西点名。 | |||
| 真正阻止一份 PDF 被打印或者复制 | no | no | no |
| 这个格式允许把这些禁令写进文件里，但它们只是对阅读器提出的请求：内容一打开就解密了，而一个不理这个请求的阅读器照样打印。任何工具，本地的也好远程的也好，都做不到更多。所以本站不提供这些勾选框。 | |||
我们放弃了什么，为什么
一个对自身界限老实的网站，比一个什么都答应的网站有用。下面是我们决定不做的事，每一条都附上理由。理由不变，这些条目就不会动。
- 图片里的文字识别，以及读 iPhone 的 HEIC 照片：需要的引擎有十到十五兆。网速不好的时候，为了读几个字先下十五兆，这笔账不划算。以后可以重新考虑，但绝不会悄悄改。
- 视频，任何形式的视频：浏览器里的视频转换引擎有三十兆上下。不做。
- 用人工智能抠背景：得先下载一个模型，而模型是又大又看不透的文件。不做。
- 任何天生离不开网络的东西：把链接变短、把短链接还原、查一个域名归谁、显示远程页面的预览。这些工具没法做成本地的，所以这里没有。这不是缺口，这就是这个项目的定义。
- 用地图标出照片拍摄地：那会成为本站唯一一个外发请求，而且它带走的正是文件里最敏感的那条信息。坐标会明明白白列出来，怎么用由您决定。
- 把 PDF 变成图片：那得把页面画出来，而画 PDF 是一整门手艺（字体、矢量、透明、色彩空间）。我们内嵌的那个库会造 PDF，不会画 PDF 的页面。网上唯一像样的渲染引擎，按它自己发布的文件量出来，单为这一件事就要 1.72 MB（压缩前）。反过来的方向，图片转 PDF，已经摆上台，而且能用。
- 给 PDF 签名：理由一样，而这一条最让人不甘心。没有渲染引擎就没法把页面显示出来；显示不出来，就没法让人把签名放在自己想放的位置。闭着眼睛按固定坐标盖上去的签名，比没有还糟。宁可留一个空位，也不出一件会毁掉文件的工具。
- 读二维码：浏览器提供的那个功能靠操作系统撑着。所以它只存在于一部分 Chromium 上，也就是 macOS、ChromeOS 和 Android；Windows 和 Linux 上没有，Firefox 从来没实现过，Safari 的实验版从 iOS 18 起就是坏的。靠它的工具，在大多数台式机访客那里根本不能用。反过来，生成二维码留在计划里：手写得出来，而且标准可以自由使用。
- 禁止打印或复制一份 PDF：格式确实允许写上这些限制，很多工具也把这些勾选框摆出来，因为看着让人安心。它们只是对阅读器提的请求：文件一打开内容就已经解密了，不理这个请求的阅读器照样打印。卖一把其实是贴纸的锁，正是这个网站存在的意义所在——为了不撒这种谎。
- 用麦克风录音，也就是 34 号位置里“录音笔”那一半：本站工具页面的构造，每件工具只给一个入口，一个文件、一段文字或者什么都不要，而每一条信任横幅讲的正好就是那个入口。麦克风会是第四种，得配一条自己的承诺。更重要的是，每次发布前检查本站的那台机器没有麦克风：我们没法证明一段录音不会外传，而证不了的承诺我们不发布。所以 34 号位置是“裁剪录音”，录音这件事交给您的设备，它本来就做得很好。
- 课堂计时器的投影大屏显示：我们视觉规范里最大的字号是计数块用的那一号，它当初不是为了从教室最后一排看清而画的。大屏显示会是一个全新的图形组件，而规范已经冻结；缺什么就记下来，而不是在做工具的半路上自己发明。全屏模式是有的，会铺满整个屏幕，但它不会把数字放大，页面上这一点说了两遍。这是一条需求，已记录在案，没有被埋掉。
- 随机抽取的转盘动画，理由相同：这是视觉规范里没有的组件。而且转盘并不会让抽签更公平，它只是把抽签演出来。让抽签公平的是背后用的随机源和没有偏差，工具把这两样连同算式一起显示出来：n 分之一的机会，n 的阶乘种可能顺序。
- 日期计算器里可点击的日历：我们的视觉规范没有画过日期输入框，而浏览器自带的日期框会带着它自己的边框和高度进来，落在规范之外。所以日期按国际格式输入，这有个实实在在的好处：“03/04”在半个世界指 4 月 3 日，在另外半个指 3 月 4 日。
- 日期计算器里的法定假日：各国不同，同一个国家有时各地区还不同，日期每年会变，而假日碰上周末往往还有一个逐案决定的补休。一份写死的清单十二个月内就会出错，而这个项目面向的是全世界。所以算出来的工作日一律是周一到周五，没有例外，页面上也写着这一点。
- 单位换算器里的迪多点，这是最能说明问题的一条：没有任何计量机构给它下过定义，引用它的书给出了四个不同的数值。当四份二手资料互相打架、又没有任何一手来源时，就没有什么可抄的。相比之下，网页里的点正好等于一英寸的七十二分之一，白纸黑字写在规范里。
- 给 ZIP 压缩包设密码，收发两个方向都不做：这个格式历史上的加密早在 1994 年就被一篇公开的攻击破掉了，而现代那套是私有扩展，还有好几个变体。我们会做一堆重活，换来一层没法老实说它结实的保护。安全专区里的加密工具解决的是真问题，而且它把整套做法都摆出来。
PDF 专区的几次取舍，以及凭的是什么证据
为了开出 PDF 专区，我们做了三个决定，每一个都有代价。下面把它们连同核查真正查实的东西一起写出来。一个不说自己凭什么的取舍不叫取舍，那叫意见。
第一个决定：本站内嵌一个库，而且只此一个。手写一份 PDF 不合情理：这是一种由间接对象、交叉引用表和压缩流构成的格式，错一个字节整个文件就打不开。这是本项目章程允许的那个例外，也是唯一动用过的一次。代码由我们自己提供，绝不走内容分发网络：PDF 专区的页面从本站加载它，版本号钉死在文件名里，好让升级没法悄无声息；它的自由许可证就放在旁边一起提供；它在磁盘上的确切大小每次构建网站时都会量一遍，就在本页再往下一点的位置。
我们还用机器多查了一件事：这个文件里没有任何网络调用，一个都没有，而且内容关卡每次构建都会在原始文件上重查一遍，连注释都不去掉。一个内嵌的库要像工具一样受检查，而且还要更严。
第二个决定：版本。原先章程点名的那个库，从 2021 年 11 月起就没再收到过一处修正，作者自 2024 年 5 月起联系不上：我们改用了那份仍在维护的延续版本，许可证相同。在这份延续版本的两个版本之间，我们没有挑那个更稳当的，而是挑了更新的那个，理由很具体：早先那版会用保存那一刻的时间做哈希，当作受保护文件的内部标识符。这样的标识符可以用暴力搜索反推回去，于是每个加密文件都会被精确到毫秒地标上时间。在一个承诺什么都不泄漏的网站上，这一条就足以出局。我们采用的那版把这个标识符改成随机生成。
第三个决定，也是代价最大的一个：PDF 的密码没有达到标准里最好的那一档，而我们在您动手之前就把这一点写出来。PDF 里有两种做 AES-256 的方式：第 5 修订版，Adobe 2008 年发布；以及 PDF 2.0 标准的第 6 修订版。加密算法是同一个；不同的是校验密码的方式。第 5 修订版一次运算就校验完，第 6 修订版故意把它拖慢，而攻击工具公开发表的实测数据显示，两者的试密速度差了四到五个数量级。这个库只写得出第 5 修订版，而它恰好也是 PDF 2.0 标准唯一标记为废弃的那一版。
我们本来可以只写“AES-256”，然后闭口不谈，提供这个功能的网站大多如此。我们选择在按钮被按下之前，就把修订版号、密钥长度和密钥的生成方式摆出来，并且引导您去生成一句像样的密码短语。用一个短词，这件工具什么也保护不了；用几个随机取来的词组成一句短语，它是真的能护住。差别掌握在您手里，前提是有人把这件事告诉您。
还有一个量出来的陷阱，而且它本来是看不见的。以某种方式保存一份加密文件时，这个库会把文件的标题、作者和软件名以明文留在受保护的文件里：拿一个纯文本编辑器就能看到。我们是在回读自己输出文件的字节时发现的，不是在哪份文档里读到的。所以这件工具只用不泄漏的那一种方式保存，加密之前先把身份信息拿掉；而且验收关卡现在会在每一个产出的文件里搜这些明文值。一个只读代码的检查什么也看不见。
内嵌的库
本店的规矩是零依赖。当手写代码不合情理时，可以破例内嵌一个库：绝不从第三方服务器加载，版本一律钉死，许可证核查过，大小写在这里。
@cantoo/pdf-lib 2.8.1
le coin PDF · Licence MIT · 661.4 KB
Écrire un PDF à la main est déraisonnable : c'est un format d'objets indirects, de tables de références croisées et de flux compressés, et une erreur d'un octet rend le fichier illisible. C'est l'exception que la doctrine autorise, et c'est la seule. Cette bibliothèque est le prolongement MAINTENU de pdf-lib, dont la dernière version date de novembre 2021 : nous avons choisi le code vivant. La version est figée dans le nom du fichier, la licence MIT est servie à côté, et le code est là, chez nous : les pages du coin PDF le chargent depuis ce site, jamais depuis ailleurs. Nous avons vérifié une chose de plus, à la machine : ce fichier ne contient AUCUN appel réseau, pas un seul, et le verrou du contenu le re-vérifie à chaque build.
对照表的来源
对照表的每一行都对着一份公开来源核过。全列在这里，好让这次核查不靠我们也能重做一遍。
- 图片格式指南（MDN）
https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Image_types - 从画布写出 WebP：支持情况一览表
https://caniuse.com/mdn-api_htmlcanvaselement_toblob_type_parameter_webp - canvas.toBlob（MDN）
https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toBlob - 原生压缩：到处都可用（web.dev）
https://web.dev/blog/compressionstreams - 原生加密（MDN）
https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto - 条码识别（MDN）
https://developer.mozilla.org/en-US/docs/Web/API/Barcode_Detection_API - “另存为”窗口（MDN）
https://developer.mozilla.org/en-US/docs/Web/API/Window/showSaveFilePicker - 离屏处理（MDN）
https://developer.mozilla.org/en-US/docs/Web/API/OffscreenCanvas - 各格式里的 EXIF 方向标签
https://zpl.fi/exif-orientation-in-different-formats/ - WebP 容器（规范）
https://developers.google.com/speed/webp/docs/riff_container - pdf-lib：这个库会做什么
https://github.com/Hopding/pdf-lib - iOS 上画布的最大面积
https://pqina.nl/blog/canvas-area-exceeds-the-maximum-limit/ - 把画布序列化成文件（HTML 标准）
https://html.spec.whatwg.org/multipage/canvas.html - 密码的存储：推荐参数
https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html - 从密码生成密钥（NIST SP 800-132）
https://csrc.nist.gov/pubs/sp/800/132/final - 用浏览器的接口做加密
https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/encrypt - 流式加密：一直开着的那个诉求
https://github.com/w3c/webcrypto/issues/73 - 原生压缩：支持情况一览表
https://caniuse.com/mdn-api_compressionstream_compressionstream - ZIP 文件格式（规范）
https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.2.TXT - ICO 图标格式，以及它里面的 PNG
https://devblogs.microsoft.com/oldnewthing/20101022-00/?p=12473 - 那个 PDF 库还在维护吗？（讨论）
https://github.com/Hopding/pdf-lib/discussions/1631 - 那个 PDF 库仍在维护的延续版本
https://github.com/cantoo-scribe/pdf-lib - 条码识别：所谓“真实支持”是什么意思
https://developer.chrome.com/docs/capabilities/shape-detection - Adobe 对 ISO 32000 标准的补充：扩展级别 3 的 AESV3 加密
https://www.loc.gov/preservation/digital/formats/fdd/fdd000313.shtml - pdf.js：PDF 的 AES-256 两个加密修订的代码
https://github.com/mozilla/pdf.js/blob/master/src/core/crypto.js - PDFium：Chrome 引擎里的 AES-256 密码校验
https://github.com/chromium/pdfium/blob/main/core/fpdfapi/parser/cpdf_security_handler.cpp - ISO 32000-1 标准：对象流（§7.5.7）与图像（§8.9.5）
https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/PDF32000_2008.pdf - qpdf：为什么修订 5 只该用来测试兼容性
https://qpdf.readthedocs.io/en/stable/encryption.html