附件损坏签名

Question

我有PDF文件。

1）Adobe读者很好地阅读文档。

2）我签署文件（使用pdfbox），一切都很好

3）我尝试将文件附加到原始pdf（代码写在pdfbox网页 - 在cookBook中）。

4）Adobe读者很好地阅读了附件。一切都很顺利。

5）现在我有附件的文件。

6）我尝试签署该文件（我的意思是带附件的文件）。我有2个问题：

的第一： 当我打开文档时，Adobe读者告诉我签名字节范围无效。

的第二： 当我试图关闭文档（我的意思是关闭adobe reader）时，Adobe读者告诉我： 你想在关闭前将更改保存到“原始[带附件] [签名]”吗？ 我没有发现你的情况发生了。

这里是测试文件uploaded to the google doc

Answer 1

您的问题的原因是，签名original[with-attachment].pdf的过程会创建一个带有交叉引用流的增量更新，而源文件具有交叉引用表。添加增量更新时，新的交叉引用必须与旧交叉引用的类型相同。

很可能这个错误是由于附加attach.txt行为错误的过程造成的：它将文件存储为带有交叉引用表的PDF，即使原始文件是带有交叉引用的文件流，但同时在新文件的预告片中留下前交叉引用字典中的一些元素。这些遗留元素（不属于预告片词典）可能会使您的签名过程认为源已使用交叉引用流。

由于禁止在增量更新之间更改交叉引用样式，Adobe Reader会尝试将文档修复到内存中。此类修复尝试通常会导致意外 您是否要在关闭之前将更改保存到“原始[带附件] [已签名]” 警告。

在修复PDF的过程中，整个PDF被重新排列。这显然会导致 签名字节范围无效。

original.pdf

%PDF-1.3
%âãÏÓ
11 0 obj
<</Linearized 1/L 48987/O 13/E 37674/N 3/T 48682/H [ 480 178]>>
endobj
25 0 obj
<</DecodeParms<</Columns 4/Predictor 12>>/Filter/FlateDecode/ID[<321A6D6DCD0785E8E35BD4B13115140A><59793561FB914D408936FC170763541A>]/Index[11 22]/Info 10 0 R/Length 77/Prev 48683/Root 12 0 R/Size 33/Type/XRef/W[1 2 1]>>stream
hÞbbd``b`jŒ â`–,õ@‚µÄb‰í±@Ä"Q{$¬rÄ‚MLŒ³€,F¬ÄÆK¿ Mi
endstream
endobj
startxref
0
%%EOF

32 0 obj 

[.........]

endobj
8 0 obj
<</DecodeParms<</Columns 3/Predictor 12>>/Filter/FlateDecode/ID[<321A6D6DCD0785E8E35BD4B13115140A><59793561FB914D408936FC170763541A>]/Info 10 0 R/Length 50/Root 12 0 R/Size 11/Type/XRef/W[1 2 0]>>stream
hÞbb```bœ¬ÅÄÀ°“‰A\š‰H³Îbbà)²'ñ5&F§Û@yF€  xi 
endstream
endobj
startxref
116
%%EOF

原始[与附着] .PDF

%PDF-1.3
%öäüß
1 0 obj

[.........]

endobj
xref
0 33 
0000000000 65535 f
0000000015 00000 n
[...]
0000049667 00000 n
0000049737 00000 n
trailer
<<
/DecodeParms <<
/Columns 4
/Predictor 12
>>
/Filter /FlateDecode
/ID [<321A6D6DCD0785E8E35BD4B13115140A> <59793561FB914D408936FC170763541A>]
/Info 5 0 R
/Length 77
/Root 1 0 R
/Size 33
/Type /XRef
/W [1 2 1]
/Index [11 22]
>>
startxref
49755
%%EOF 

原始[与附着] [签名] .PDF

%PDF-1.3
%öäüß
1 0 obj

[....as above....]

startxref
49755
%%EOF 

1 0 obj

[.........]

endobj
37 0 obj
<<
/ID [<DC60F4419C05967B81D7F64090027D7F> <DC60F4419C05967B81D7F64090027D7F>]
/Info 5 0 R
/Root 1 0 R
/Prev 49755
/Type /XRef
/Size 38
/Filter /FlateDecode
/Index [1 1 6 1 33 4]
/W [1 3 0]
/Length 31
>>
stream
xœcd8ú‘1&ˆ‘áØ.F†ã¾ŒŒ±ù@| VÚ
endstream
endobj
startxref
89569
%%EOF 

侧面评论

ID管理：添加附件的流程会保留整个 ID 。您的签名过程会删除PDF的原始 ID ，并将其替换为新的：

• original.pdf

  /ID[<321A6D6DCD0785E8E35BD4B13115140A><59793561FB914D408936FC170763541A>]
  

• 原创[附件] .pdf

  /ID [<321A6D6DCD0785E8E35BD4B13115140A> <59793561FB914D408936FC170763541A>] 
  

• 原文[signed] .pdf

  /ID [<A9F7159B1E5D8285A68475689B750214> <A9F7159B1E5D8285A68475689B750214>] 
  

• 原创[附件] [签名] .pdf

  /ID [<DC60F4419C05967B81D7F64090027D7F> <DC60F4419C05967B81D7F64090027D7F>] 
  

这两种方法都是错误的，操作PDF的过程因此创建新版本的应该保留第一个 ID 条目，并仅使用唯一的新条目替换第二个。