使用 iText(Sharp) 提取 PDF 注释不一致的原因答案

【问题标题】：Cause for Inconsistent Extractions of PDF Annotations with iText(Sharp)使用 iText(Sharp) 提取 PDF 注释不一致的原因
【发布时间】：2012-07-09 03:39:38
【问题描述】：

场景：

我有一个应用程序使用 iTextSharp 搜索 PDF 文件中的超链接。

PDF 中的超链接是文件结构中“注释对象”的子类型，因此我的代码本质上是 (1) 读取文件，(2) 循环浏览页面，(3) 获取页面的注释集合，以及 (4) 提取页面的超链接注释。

问题

有时表示给定页面的“pdf 字典”对象没有注释集合（没有/ANNOTS）键。因此尝试获取此类集合返回null。这是一个问题，因为当相关页面上有明显可见且可点击的链接时，它不时发生。

请注意，可点击在这里很重要，因为我知道纯文本中可能存在 URL 地址，但我不关心那些，只关心真实的超链接。

代码

我通过提供的答案发现了类似的 SO 问题 (http://stackoverflow.com/questions/6959076/reading-hyperlinks-from-pdf-file) 几乎正是我已经在使用的代码。主要区别在于：

// My code
var pdfAnnotations = (PdfArray)PdfReader.GetPdfObject(pageDict.Get(PdfName.ANNOTS));
foreach (var annotation in pdfAnnotations.ArrayList) {}
                    {

// Chris' code                        
var annotsArray = pageDict.GetAsArray(PdfName.ANNOTS); 
foreach(var annotation in annotsArray.ArrayList) { }

// My pageDict.Get() and Chris's pageDict.GetAsArray() methods both 
// return null because there is no ANNOTS key present in pageDict.

问题

为什么是空值？带有清晰可见/可点击链接的 PDF 文档如何没有注释集合？文件结构中是否还有其他代表超链接/URI 的PdfObject 子类型？

谢谢

【问题讨论】：

您能否提供一个带有可点击链接的 1 页 PDF 示例，其中 PDF 源代码中没有 /ANNOTS 键？
很遗憾没有。这些是我无法与公众共享的工作文件，即使可以，几乎所有文件共享网站都被阻止。我知道，这让这种情况变得艰难。

标签： c# pdf hyperlink annotations itextsharp

【解决方案1】：

那么让我猜一猜。（没有要分析的样本，就没有其他办法了。）

顺便说一句，在 PDF 代码中它是从不 /ANNOTS -- PDF 密钥区分大小写！ -- 总是/Annots。

在 PDF 源代码中，像 /Annots 这样的 ASCII 字符串作为名称对象可以用以下任何一种替代方式表示。根据 PDF 规范，这些都是“合法的”（参见PDF-1.7 specification 的第 7.3.5 段，名称对象）：

 /Annots
 /#41nnots      # '#41' is the hex represenation of ASCII 'A' in PDF
 /A#6Enots      # '#6E' is the hex represenation of ASCII 'n' in PDF
 /An#6Eots      # '#6E' is the hex represenation of ASCII 'n' in PDF
 /A#6E#6Eots    # '#6E' is the hex represenation of ASCII 'n' in PDF
 ...
 /Annot#73      # '#73' is the hex represenation of ASCII 's' in PDF

你明白了......（如果我的快速计算是正确的，你可以做出 32 种不同的变化......）

顺便说一句，这是黑帽黑客用来混淆其恶意软件 PDF 中的 /#4Aava#53cript 密钥的最简单方法之一！有关其潜在方法的更完整列表，请参阅'Corkami Project'。）

也许您的 iTextSharp 版本（您没有说明）不能正确处理您对 /Annots 名称键的所有表示的搜索？

如果是这样，那么我对您的建议是在查找 /Annots 之前规范化每个 PDF 的副本。您可以借助qpdf 的命令行工具（和API）成功实现这一点：

 qpdf --qdf helloworld.pdf qdf---helloworld.pdf

让我们看看：

 kp@mbp:~$  grep nnots helloworld.pdf
      /#41nnots 57 0 R

 kp@mbp:~$  qpdf --qdf helloworld.pdf qdf---helloworld.pdf

 kp@mbp:~$  grep nnots qdf---helloworld.pdf
 qdf---helloworld.pdf:     /Annots 57 0 R

【讨论】：

【解决方案2】：

我很确定您不需要担心任何其他类似链接的 PDF 对象（除了大纲/书签元素和嵌入的与 javascript 相关的东西）。但是有些读者会在文本中找到 URL 模式并继续使它们可点击，即使它们没有被编码为链接注释。如果没有 PDF 来查看它，最好的猜测是这就是您的情况。（您可以通过在文本中创建一个带有简单 URL（但没有链接注释）的 PDF 来测试这一点，并查看您的阅读器是否使其可点击。）

【讨论】：