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