如何找到预告片字典？

浏览 PDF 规范，它说trailer之前的startxref。对我来说，这意味着xref可以出现在文档中的任何位置，但是trailer仍然出现在startxref。在您必须解析它之前，这是有意义的，因为您必须反向解析，您无法考虑注释或字符串。那么让我们变得更古怪一点。

trailer<< %\
  /Size 4 %\
  /Root 1 0 R %\
  /Info 4 0 R %\
  /Key (\
trailer<< %\
  /Size 4 %\
  /Root 2 0 R %\
  /Info 3 0 R %\
>>%)
>>&)
% test test )
startxref
 15
%%EOF

这是一个完全有效的预告片。第一个是真正的预告片，但第二个是“字符串”。在这种情况下，反向解析将无法捕获注释。如果字符串预告片是注释或字符串的一部分，则查找字符串预告片将会失败。我想知道找出预告片开始位置的最佳方法是什么？

更新 - 该预告片似乎可以在 Acrobat Reader 中打开

%PDF-1.3
%âãÏÓ
xref
0 4
00000000 65535 f
00000110 00000 n
00000250 00000 n
00000315 00000 n
00000576 00000 n

1 0 obj <<
  /Type /Catalog
  /Pages 2 0 R
  /OpenAction [ 3 0 R /XYZ null null null ]
  /PageLabels << /Nums [0 << /S /D >> ] >>
>>
endobj
2 0 obj <<
  /Type /Pages
  /Kids [ 3 0 R ]
  /Count 1
>>
endobj
3 0 obj <<
  /Type /Page
  /Parent 2 0 R
  /Resources << >>
  /MediaBox [ 0 0 612 792 ]
>>
endobj
4 0 obj <<
  /Producer (Me)
  /CreationDate (D:20110626000000Z)
>>
endobj

trailer<< %\
  /Size 4 %\
  /Root 1 0 R %\
  /Info 4 0 R %\
  /Key (\
trailer<< %\
  /Size 4 %\
  /Root 2 0 R %\
  /Info 3 0 R %\
>>%)
>>%)
% test test )
startxref
 15
%%EOF

就语法而言，这符合规范。不知何故，他们似乎能够知道自己是在评论中，还是在字符串中。解析 L-R，第二个预告片位于一个带有 % 尾部的字符串中，预告片后面有注释。但是 R-L 解析，你不知道第一个 ) 是注释的一部分，还是字符串定义的结尾。

另一个例子：

%PDF-1.3
%âãÏÓ
xref
0 8
0000000000 65535 f
0000000210 00000 n
0000000357 00000 n
0000000428 00000 n
0000000533 00000 n
0000000612 00000 n
0000000759 00000 n
0000000830 00000 n
0000000935 00000 n

1 0 obj <<
  /Type /Catalog
  /Pages 2 0 R
  /OpenAction [ 3 0 R /XYZ null null null ]
  /PageLabels << /Nums [0 << /S /D >> ] >>
>>
endobj
2 0 obj <<
  /Type /Pages
  /Kids [ 3 0 R ]
  /Count 1
>>
endobj
3 0 obj <<
  /Type /Page
  /Parent 2 0 R
  /Resources << >>
  /MediaBox [ 0 0 612 792 ]
>>
endobj
4 0 obj <<
  /Producer (Me)
  /CreationDate (D:20110626000000Z)
>>
endobj
5 0 obj <<
  /Type /Catalog
  /Pages 6 0 R
  /OpenAction [ 7 0 R /XYZ null null null ]
  /PageLabels << /Nums [0 << /S /D >> ] >>
>>
endobj
6 0 obj <<
  /Type /Pages
  /Kids [ 7 0 R ]
  /Count 1
>>
endobj
7 0 obj <<
  /Type /Page
  /Parent 6 0 R
  /Resources << >>
  /MediaBox [ 0 0 100 100 ]
>>
endobj
8 0 obj <<
  /Producer (Me)
  /CreationDate (D:20110626000000Z)
>>
endobj

trailer<< %\
  /Size 8 %\
  /Root 1 0 R %\
  /Info 4 0 R %\
  /Key (\
trailer<< %\
  /Size 8 %\
  /Root 5 0 R %\
  /Info 8 0 R %\
>>%)
>>%)
% test test )
startxref
 17
%%EOF

此示例在 Adob​​e 中正确显示。在我的上一个例子中，您声称它会失败，因为“根”节点无效，但在这个新示例中，根是有效的，但从未实际使用过。那么它不应该显示 100x100 的窗口，而不是 8.5"x11" 吗？

关于资源

  (Required; inheritable) A dictionary containing any resources required by the page 
(see Section 3.7.2, “Resource Dictionaries”). If the page requires no resources, the 
value of this entry should be an empty dictionary. Omitting the entry entirely
indicates that the resources are to be inherited from an ancestor node in the page 
tree.

问：医生，我这样做时会很痛。
答：不要这样做。

解析 PDF 结尾的正确方法如下：

1. 找到最后一个startxref
2. 备份到该字节偏移并开始解析外部参照表条目
3. 在最后一个外部参照表之后，解析出预告片。

如果您只是想找到预告片，则实际上不必解析对象编号和字节偏移量等。您需要做的就是查看外部参照的给定小节中有多少条目，跳过 20*N 字节，并检查另一个小节（或“预告片”）。当你最终点击“预告片”而不是数字时，你就到了。

那么你到底为什么只想要预告片呢？

当我浏览 PDF 参考时，我希望找到一些文本行，说明标题/正文/外部参照/预告片必须按该顺序排列。我没有。

我发现的是：

基本的合格 PDF 文件应由以下四个元素构成（见图 2）：
- 单行标题...
- 身体...
- 交叉引用表...
- 预告片...

这些部分前面有项目符号，而不是数字。

因此，所有迹象都表明，符合要求的 PDF 可以通过交换正文和外部参照的顺序而逃脱惩罚。另一方面，标题是required首先，预告片是required最后，PDF 的所有部分均按该顺序列出。这意味着秩序，但在法庭上站不住脚。

但是，如果您查看标题为“PDF 文件的初始结构”的图 2（第 7 章第 5.1 节），您将看到直观定义的顺序。虽然有点薄，但我还是会坚持下去。

如果发现将正文放在外部参照表之后的 PDF 会破坏某些 PDF 查看器（尤其是程序试图修复的格式错误的 PDF），我一点也不感到惊讶。

我使用 PDF 文件已有十多年了。在那段时间里，我有never看过一个 PDF，其中外部参照位于正文之前。我还见过一些完全搞砸的 PDF。

因此，虽然我的“解析 PDF 的正确方法”可能不是铁甲如山，但它仍然相当耐用。

如果您绝对坚持备份以查找关键字“预告片”，那么您可以在解析出找到的预告片后查找“关闭数组或字典”标记。如果它被包裹在字符串中，则所有名称斜杠都必须转义，从而导致错误解析。名称中不能有空格...所以只剩下数组和字典。

但在现实生活中，您遇到此问题的可能性非常小，除非您打算破坏 PDF 软件并自己创建这些 PDF。这会让你的动机受到质疑。