合并 PDF

真正会用到它的场合

合并本身很少是目的。几乎每一次合并,都是因为某件事必须以「一个文件」的形式交出去,而收件方还有规矩。

这些是最常遇到的:

• 报销。财务系统只收一个附件,而你手机扫描 App 里躺着十一张各自成文件的发票。
• 合同加附件。签字页、附件清单、报价函来自三个人、三个文件,对方要一份能一起签字盖章的完整文档。
• 租房或签证材料。要求写得很明确:「护照、银行流水、住址证明,合并为一个文件,按此顺序」——顺序错了就是退回重交。
• 扫描的教材章节或讲义。每章从复印机出来都是一个独立 PDF,你想并成一个能在平板上顺着读的文件。
• 法院或保险的举证材料。证据要编号,编号还得和书面清单对得上。这种场合顺序错了代价很大,所以顺序应当照着清单排,不要凭记忆排。

按下「开始合并」之后到底发生了什么

你选中文件时,浏览器交给页面的只是一个指向硬盘上那个文件的 File 对象 —— 它不是被复制到某个服务器目录里的副本,而是一个句柄。页面只在需要时才用标准的 ArrayBuffer 接口把字节读进内存。

合并本身由 pdf-lib 完成,这是一个跑在标签页里的 JavaScript 库。它逐个解析源文档,把每个页面对象复制进一个新文档,再序列化回字节;这些字节变成一个 Blob,Blob 拿到一个临时的内存 URL,下载链接指向它。你关掉标签页,这个 URL 和它背后的内存就没了。

想自己验证而不是听我们说,那就打开浏览器开发者工具的 Network 面板,再点合并。第一次你会看到加载 pdf-lib 的请求,之后什么都没有 —— 没有任何一个请求带着你的文档。这个办法对本站每个工具都适用,也是这里唯一值得你自己动手验一遍的说法。

哪些东西保住了,哪些悄悄丢了

这是多数合并工具不会主动告诉你的一段,而它偶尔真的会毁掉某人的一个下午。

• 页面尺寸和方向按页保留。A4 和 Letter 混在一起没问题,每一页保持自己的尺寸,不会被强行缩放对齐。
• 画质不受影响。页面是以对象为单位复制的,不是重新渲染成图片,所以文字依然可选、没有代际损失。合并后的体积基本等于几个源文件之和 —— 也就是说,合并不可能让文件变小。
• 书签和目录树会丢失。合并后的文档不会有源文件里的那个导航侧栏。
• 表单域不能跨文件保留。可填写的表单域会被压平或消失,对方填过的内容也不会带过来。要么先填好再合并,要么先合并再填,不要两头都指望。
• 数字签名必然失效,这是定义决定的。签名覆盖的是它被施加时那份文档的精确字节;加了一页就是改了字节,于是签名会被判为无效 —— 尽管没有任何东西被篡改。如果一份签好的合同需要保持可验证,就不要合并它,分开交。
• PDF 内嵌的附件会被丢掉。

怎么快速排出正确的顺序

最常见的失误是按文件管理器的排列顺序一股脑加进来,合到一半才发现第 4 页本来该在第 9 页的位置。顺序排错再合一次也就十秒钟,算不上灾难,但有个几乎不花力气的办法可以避开它。

如果这份材料有书面清单,把清单放在手边,照着清单一个一个加,边加边看列表。如果没有清单,就在系统里把源文件改名,让文件名的字母顺序正好等于你想要的顺序,然后一次性全加进来 —— 排序这件事交给操作系统做,它又快又不会错;交给手点,就要点很多下。序号用两位数(01、02……10),超过九个文件时顺序才不会乱,一位数会乱。

什么时候不该用合并

有三种情况你要的是别的东西:

• 合出来的文件太大,邮件发不出去。合并不压缩,你需要的是「压缩 PDF」,它会把内嵌图片重新编码。先压缩再合并 —— 反过来做等于对一个大文件压缩一次,比压几个小文件更慢、效果也更差。
• 某个源文件有密码。加密状态下没法合并,这个工具会直接告诉你哪个文件出的问题,而不是悄悄给你一份空白页。用阅读器打开它、输入密码、另存为一份无密码副本,再来合并。
• 你要处理的是几百个大文件。这里的一切都跑在浏览器分给标签页的那部分内存里,而那只是整机内存的一小部分。几个文件完全不算事;五百个 50MB 的扫描件,更好的做法是分批,每二十个左右合成一份,最后再把这几十份并起来。