对于某些PDF，我在刷新标记结构时看到一个NPE。这个问题发生在iText 7.0.2-Snapshot中。iText 5.5.10可以很好地处理这些文件。NPE在pdfdictionary.get（PdfName键，布尔asDirect)中抛出，因为映射是空的。该类中的映射只有在调用releaseContent()时才能变为null。
因为releaseContent()的唯一目的是--就我所知--释放内存，所以我测试了当它更改为空方法时会发生什么。结果是文件似乎正常处理。不再有例外。下面是一个示例文件。
protected void releaseContent() {
List<Integer> objs = Arrays.asList(6888, 6856, 6824, 844, 836);
if (objs.contains(indirectReference.objNr)) {
return;
}
map = null;
}
PdfReader reader = new PdfReader(src);
PdfWriter writer = new PdfWriter(dest);
PdfDocument doc = new PdfDocument(reader, writer);
doc.close();`
输出是什么：
Exception in thread "main" com.itextpdf.kernel.PdfException: Tag structure flushing failed: it might be corrupted.
at com.itextpdf.kernel.pdf.PdfDocument.tryFlushTagStructure(PdfDocument.java:1746)
at com.itextpdf.kernel.pdf.PdfDocument.close(PdfDocument.java:727)
at perinorm.cleanPdf.MainCleanPDF.run(MainCleanPDF.java:139)
at perinorm.cleanPdf.MainCleanPDF.lambda$2(MainCleanPDF.java:58)
at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(Unknown Source)
at java.util.stream.ReferencePipeline$3$1.accept(Unknown Source)
at java.util.stream.ReferencePipeline$2$1.accept(Unknown Source)
at java.util.stream.ReferencePipeline$3$1.accept(Unknown Source)
at java.util.Iterator.forEachRemaining(Unknown Source)
at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Unknown Source)
at java.util.stream.AbstractPipeline.copyInto(Unknown Source)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source)
at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(Unknown Source)
at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(Unknown Source)
at java.util.stream.AbstractPipeline.evaluate(Unknown Source)
at java.util.stream.ReferencePipeline.forEach(Unknown Source)
at perinorm.cleanPdf.Main.main(Main.java:56)
Caused by: java.lang.NullPointerException
at com.itextpdf.kernel.pdf.PdfDictionary.get(PdfDictionary.java:555)
at com.itextpdf.kernel.pdf.PdfDictionary.get(PdfDictionary.java:146)
at com.itextpdf.kernel.pdf.tagging.PdfStructElem.getK(PdfStructElem.java:338)
at com.itextpdf.kernel.pdf.tagging.PdfStructElem.getKids(PdfStructElem.java:322)
at com.itextpdf.kernel.pdf.tagging.PdfStructTreeRoot.flushAllKids(PdfStructTreeRoot.java:247)
at com.itextpdf.kernel.pdf.tagging.PdfStructTreeRoot.flushAllKids(PdfStructTreeRoot.java:249)
at com.itextpdf.kernel.pdf.tagging.PdfStructTreeRoot.flushAllKids(PdfStructTreeRoot.java:249)
at com.itextpdf.kernel.pdf.tagging.PdfStructTreeRoot.flushAllKids(PdfStructTreeRoot.java:249)
at com.itextpdf.kernel.pdf.tagging.PdfStructTreeRoot.flushAllKids(PdfStructTreeRoot.java:249)
at com.itextpdf.kernel.pdf.tagging.PdfStructTreeRoot.flushAllKids(PdfStructTreeRoot.java:249)
at com.itextpdf.kernel.pdf.tagging.PdfStructTreeRoot.flush(PdfStructTreeRoot.java:184)
at com.itextpdf.kernel.pdf.PdfDocument.tryFlushTagStructure(PdfDocument.java:1744)
... 16 more
这个问题的直接原因是，在示例文档的结构树中，一些节点被多次使用，例如。
6770 0 obj
<<
/K [ 6873 0 R 6874 0 R 6875 0 R 6876 0 R 6877 0 R 6878 0 R 6879 0 R
6880 0 R 6881 0 R 6882 0 R 6883 0 R 6884 0 R 6885 0 R 6886 0 R
6887 0 R 6888 0 R 6888 0 R ]
/P 5874 0 R
/S /TR
>>
如您所见，68880R在此结构树节点的子节点数组中出现了两次。
当iText 7关闭pdfdocument时，它遍历结构树并将找到的每个元素刷新到目标文档：
private void flushAllKids(IPdfStructElem elem) {
for (IPdfStructElem kid : elem.getKids()) {
if (kid instanceof PdfStructElem) {
flushAllKids(kid);
((PdfStructElem) kid).flush();
}
}
}
private void flushAllKids(IPdfStructElem elem) {
for (IPdfStructElem kid : elem.getKids()) {
if (kid instanceof PdfStructElem) {
if (!((PdfStructElem) kid).isFlushed())
{
flushAllKids(kid);
((PdfStructElem) kid).flush();
}
}
}
}
通过此更改，示例文档将无例外地被盖章。
