追加模式要求文档没有错误，即使可以恢复也是如此 [英] Append mode requires a document without errors, even if recovery is possible
问题描述
我用 append 模式签名的PDF是从Office Word 2016导出的.
The PDF which I signed with append mode is exported from Office Word 2016.
这是我的文件: word.pdf
我收到此错误消息:
com.itextpdf.kernel.PdfException: Append mode requires a document without errors, even if recovery is possible.
com.itextpdf.kernel.PdfException: Append mode requires a document without errors, even if recovery is possible.
我正在使用iText7 7.0.4.
I am using iText7 7.0.4 .
推荐答案
您试图在追加模式下更改的文档已损坏.交叉引用表中定义的字节偏移很可能与PDF对象的实际字节位置不符.
The document you are trying to change in append mode is broken. Most likely, the byte offsets as defined in the cross-reference table don't correspond with the actual byte positions of the PDF objects.
在您的情况下，文件末尾出现了一些奇怪的情况:
In your case, I see something strange at the end of the file:
xref
0 26
0000000010 65535 f
0000000017 00000 n
0000000166 00000 n
0000000222 00000 n
0000000492 00000 n
0000000755 00000 n
0000000932 00000 n
0000001180 00000 n
0000001233 00000 n
0000001286 00000 n
0000000011 65535 f
0000000012 65535 f
0000000013 65535 f
0000000014 65535 f
0000000015 65535 f
0000000016 65535 f
0000000017 65535 f
0000000018 65535 f
0000000019 65535 f
0000000020 65535 f
0000000000 65535 f
0000001961 00000 n
0000002154 00000 n
0000044863 00000 n
0000048000 00000 n
0000048045 00000 n
trailer
<</Size 26/Root 1 0 R/Info 9 0 R/ID[<8812105F6F93284DAEF240C8C1FC4C4E><8812105F6F93284DAEF240C8C1FC4C4E>] >>
startxref
48341
%%EOF
xref
0 0
trailer
<</Size 26/Root 1 0 R/Info 9 0 R/ID[<8812105F6F93284DAEF240C8C1FC4C4E><8812105F6F93284DAEF240C8C1FC4C4E>] /Prev 48341/XRefStm 48045>>
startxref
49017
%%EOF
您有一个带有两个预告片的PDF.一位预告片声称交叉引用表存储在流中:
You have a PDF with two trailers. One trailer claims that the cross-reference table in stored in a stream:
/XRefStm 48045
同时指示交叉引用表在字节位置49017的开始:
While at the same time indication the start of the cross-reference table at byte position 49017:
startxref
49017
另一个预告片声称有一个未压缩的交叉引用表，并且它从字节位置48341开始:
The other trailer claims that there's an uncompressed cross-reference table and that it starts at byte position 48341:
startxref
48341
确实:存在未压缩的交叉引用流:
And indeed: there is an uncompressed cross-reference stream:
xref
0 26
0000000010 65535 f
0000000017 00000 n
您了解文件中的不一致之处吗?
Do you understand the inconsistency in your file?
在使用附加模式时，iText不会对原始文档进行任何更改:不会更改单个字节；不会更改单个字节.在原始文件的最后%%EOF标记之后添加新的字节.但是，当原始文件损坏时，iText拒绝执行此操作.我希望您能理解其基本原理:如果iText允许您这样做，将会使情况变得更糟.
When you use append mode, iText doesn't change anything to the original document: not a single byte is changed; new bytes are added after the final %%EOF marker of the original file. However, iText refuses to do this when the original file is broken. I hope you understand the rationale: you'd make a bad situation worse if iText allowed you to do this.
要解决此问题，您需要先修复损坏的文件.可以通过操作"文档而不更改任何内容来完成，但是要在普通模式下而不是在追加模式下完成此操作.
To solve this problem, you need to fix the broken file first. That can be done by "manipulating" the document without changing anything, but to do this in normal mode, not in append mode.
您是否尝试过删除多余的预告片.我扔了:
Have you tried removing the extra trailer. I threw away:
xref
0 0
trailer
<</Size 26/Root 1 0 R/Info 9 0 R/ID[<8812105F6F93284DAEF240C8C1FC4C4E><8812105F6F93284DAEF240C8C1FC4C4E>] /Prev 48341/XRefStm 48045>>
startxref
49017
%%EOF
删除这些字节后，Adobe Reader并没有抱怨.
Adobe Reader didn't complain after removing these bytes.
这篇关于追加模式要求文档没有错误，即使可以恢复也是如此的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
