Question

我正在使用iText v5.5.1来阅读PDF并从中呈现绘画文本：

pdfReader = new PdfReader(new CloseShieldInputStream(is));
pdfParser = new PdfReaderContentParser(pdfReader);

int maxPageNumber = pdfReader.getNumberOfPages();
int pageNumber = 1;

StringBuilder sb = new StringBuilder();

SimpleTextExtractionStrategy extractionStrategy = new SimpleTextExtractionStrategy();

while (pageNumber <= maxPageNumber) {
    pdfParser.processContent(pageNumber, extractionStrategy);

    sb.append(extractionStrategy.getText());

    pageNumber++;
}

在one PDF file上抛出以下异常：

java.lang.ClassCastException: com.itextpdf.text.pdf.PdfNumber cannot be cast to com.itextpdf.text.pdf.PdfLiteral
    at com.itextpdf.text.pdf.parser.PdfContentStreamProcessor.processContent(PdfContentStreamProcessor.java:382)
    at com.itextpdf.text.pdf.parser.PdfReaderContentParser.processContent(PdfReaderContentParser.java:80)

那个PDF文件好像坏了，但也许它的内容仍然有意义......

Answer 1

的确

该PDF文件似乎已被破坏

所有页面的内容流如下所示：

/GS1 gs
q
595.00 0 0

看起来它们都被提前切断，因为最后一行不是一个完整的操作。这当然可以像iText那样使解析器变为hickup。

此外，内容应该更长，因为即使它们的压缩流的大小比它的长度略大。这表示在字节级别上断流。

查看PDF文件的字节，我们不禁注意到

即使在二进制流内，代码13和10也只能一起出现
交叉引用偏移值小于实际位置。

所以我假设这个PDF已经使用传输方法传输它作为文本数据处理，特别是用文件中无处不在的CR LF替换任何类型的假设换行符（CR或LF或CR LF）（CR =回车= 13; LF =换行= 10）。此类替换将自动中断任何压缩数据流，如文件中的内容流。

不幸的是，虽然......

但也许它的内容仍然有意义

不多。每个页面分别有一个大图像。考虑到内容流的小尺寸和大图像尺寸，我认为PDF仅包含扫描页面。但是由于上面提到的替换，图像也被打破了。

Answer 2

这不是最佳解决方案，但我遇到了这个问题，遗憾的是无法分享我遇到问题的确切PDF文件。

我创建了一个itextpdf的fork，它捕获了ClassCastException并且只是跳过了它所遇到的PdfObjects。它打印到System.out包含的文本和itextpdf认为它是什么类型。我无法将这个问题映射到我的PDF的一些系统性问题（比我聪明的人需要这样做），而这个例外只发生在蓝色月亮中。无论如何，如果它对任何人有帮助，这个fork至少不会崩溃你的代码，让你解析大部分的PDF，并给你一些关于什么类型的字节串似乎给itextpdf消化不良的信息。

https://github.com/njhwang/itextpdf

iText抛出ClassCastException：PdfNumber无法强制转换为PdfLiteral

2 个答案: