我正在尝试使用 C++ 在磁盘上进行一些文件雕刻。我在网上找不到任何与 pdf 文件的磁盘结构相关的资源。问题是我可以在集群的开头找到 %PDF-1.x 令牌，但我无法在任何地方找到 PDF 文件的大小。
假设这个特定文档的文件系统条目丢失了。我找到了文档的开头并继续阅读，直到遇到“startxref number %%EOF”。问题是我不知道何时停止，因为文档内容中有多个“%%EOF”标记。
我试过在阅读后停下来，比如说 10 个集群，但在任何地方都没有找到任何 pdf 特定的关键字，如“obj”、“stream”、“trailer”、“xref”。但它非常随意，它不是找到文档结尾的确定性方法，因此我可以确定它的大小。
我还在一些“obj”的开头看到了一些“长度数字”标记，但大多数时候这个数字并不适合。
关于下一步我可以尝试什么的任何想法？有没有办法确定整个文档的确切大小？我对以编程方式恢复文档感兴趣。
由于 PDF 是“自由格式”（很像文本文件，但在“阅读”内容时对人类来说不太明显），如果它们不按顺序排列，可能很难将它们拼凑在一起。
Astream确实有一个长度，这是通往何处的关键endstream。（流本身之前和之后的空行）。流用于将位图和类似的东西（字体、压缩形式的艺术线条数据等）引入文档）。但是，如果您有几个 4KB 的段可以作为流中间的同一个块进入，那么除了将它们粘贴在一起并查看哪些看起来正常而哪些不正常之外，没有办法知道它们往哪边走。类似地，如果有多个流和对象段，您无法真正分辨出哪个流向何处。
当然，这适用于几乎所有类型的具有“可变内容”的文件——你可以找到 JPG 的前几 KB，但要知道 REST 的内容是什么并不容易——只能目视检查内容你能确定哪些字节块属于哪里 - 如果你弄错了，你可能只会得到一些随机垃圾。
开源工具bulk_extractor有一个名为的模块scan_pdf，它几乎可以完成您在此处描述的工作。它可以识别驱动器上 PDF 文件的各个部分，自动解压缩压缩区域，并使用两种策略提取文本。即使xref找不到表格，它也会从 PDF 片段中恢复数据。