我们通过将其页面提取到单独的文件中来处理大量传入的pdf。有时我们会遇到这个奇怪的问题。每个提取的页面几乎都是整个文件的大小。 例如，如果pdf是500 Mb并且有1000页，那么从中提取单独的页面将导致每500 mb 1000个文件。即使打开单独的页面文件，您也只能在那里看到一页。
当我们使用Adobe Acrobat功能减少文件大小时，Adobe Acrobat需要一些时间并生成一个较小的文件。之后，提取页面的问题是固定的。页面开始正确提取并且尺寸较小。
到目前为止我们遇到过一些文件，可能会遇到更多文件。
我试图寻找一种自动修复此类文件的工具，我们下载并尝试了Pdflib PLOP工具。不幸的是，它没有修复文件，即使我选择了所有适用的修复和优化选项。这是我使用的命令行：
〜/ plop -v 4 --inputopt“xmppolicy = remove repair = force”--outputopt optimize = all --outfile fixed.pdf bad.pdf
它根本没有解决问题。
你有没有遇到过这样的问题？您是否有一个如何使用pdflib库或任何其他库或工具修复它们的示例？答案 0 :(得分：1)
pdf修复程序未修复这些文件的原因是它们没有被破坏开始。它们的构建方式只是简单的pdf分割器将所有资源（图像，字体......）从源pdf复制到每个分割pdf中。
更详细地说， pdf是由许多对象构建的，原始对象如字符串和数字以及更复杂的对象，如数组和字典。
每个页面都由页面树引用的字典表示。这些页面词典引用其各自的内容流，其中包含构建页面的说明。这些指令并非都是自包含的，但它们可能会按名称引用字体和位图图像等资源。这些资源在资源字典中查找，资源字典也是从页面字典中引用的。
但是资源字典不需要仅包含引用它的页面的资源，可能会有更多，并且在绘制时忽略页面上未使用的额外条目。
这允许 pdf制作者简单地将整个pdf 的所有资源放入单一资源字典，然后由所有页面字典引用，有些pdf生产商确实这样做了。像这样构建的Pdfs是困扰你的pdfs。
另一方面 pdf splitters 通常假设从页面引用的资源字典仅包含该页面的资源，因此，只需复制整个资源字典到页面的分割文件中。
如果使用单个资源字典构建pdf，则会导致为每个页面复制所有源pdf资源，并且由于资源通常包含大数据blob，因此每个页面生成的分割文件几乎都与源文件。
要回到堆栈溢出，编程的焦点，需要实现的是
的例程读取pdf，
为每个页面解析已使用资源名称的内容流，
将每个页面的相应资源字典替换为仅包含该页面上使用的条目的资源字典，并且
再次存储此更改的pdf。
在分割之前将这样的程序应用于pdf应该可以防止手头的问题。
P.S。：实际情况实际上有点复杂，因为不仅页面有资源字典，还有其他实体，如注释，表单XObject和模式。这些必须同样处理。此外，页面信息不仅可以出现在页面字典本身中，还可以从祖先继承到页面树的根目录。但这些仅仅是细节......