附件损坏签名 [英] Attachment damages signature

问题描述

我有PDF文档.

1)Adobe Reader能够很好地阅读文档.

2)我签署了文档(使用pdfbox)，一切都很好

3)我尝试将文件附加到原始pdf(代码写在pdfbox网页中-cookBook中).

4)Adobe Reader可以很好地阅读附件文档.一切都很好.

5)现在我有带附件的文件.

6)我尝试在该文件上签名(我的意思是带有附件的文件).我有两个问题:

第一个: 当我打开文档时，Adobe Reader告诉我签名字节范围无效.

第二: 当我尝试关闭文档(我的意思是关闭Adobe Reader)时，Adobe Reader告诉我: 您要在关闭之前将更改保存到原始[带附件] [签名]"吗? 我没发现您会发生这种情况.

这是测试文件已上传到Google文档

解决方案

问题的原因是，对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Ä‚MLŒ³€,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 ，并用一个新的ID替换它:

• original.pdf

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

• 原始[带有附件] .pdf

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

• 原始[签名] .pdf

  /ID [<A9F7159B1E5D8285A68475689B750214> <A9F7159B1E5D8285A68475689B750214>] 
  

• 原始[带附件] [签名] .pdf

  /ID [<DC60F4419C05967B81D7F64090027D7F> <DC60F4419C05967B81D7F64090027D7F>] 
  

这两种方法都是错误的，处理PDF的过程因此创建了它的新版本，应保留第一个 ID 条目，并仅用唯一的新条目替换第二个. >

I have PDF document.

1) Adobe reader reads document well.

2) I sign document (using pdfbox) and everything is well

3) I try to attach file to original pdf (Code is written in the pdfbox web page - in the cookBook).

4) Adobe reader reads attached document well. everything is well.

5) Now I have document with attachment.

6) I try to sign that document (I mean document with attachment). And I have 2 problem:

First: when I open document, Adobe reader tells me that signature byte range is invalid.

Second: when I try to close document (I mean to close adobe reader), Adobe reader tells me that: Do you want to save changes to "original[with-attachment][signed]" before closing? I didn't find thy this happens.

here is testing files uploaded to the google doc

解决方案

The cause of your issue is that the process of signing original[with-attachment].pdf creates an incremental update with a cross reference stream while the source file has a cross reference table. When adding incremental updates, the new cross references must be of the same type as the old ones.

It is quite possible that this error is due to the process attaching attach.txt misbehaving a bit, too: it stores the file as a PDF with a cross reference table even though the original was a file with a cross reference stream, but at the same time leaves some elements from the former cross reference dictionary in the trailer of the new file. These left-over elements (which do not belong in a trailer dictionary) probably make your signing process think the source already uses a cross reference stream.

As this change of cross reference style between incremental updates is forbidden, the Adobe Reader tries to fix the document in memory. Such attempts to fix often give rise to unexpected Do you want to save changes to "original[with-attachment][signed]" before closing? warnings.

In the course of fixing the PDF, the whole PDF is rearranged. This obviously causes that signature byte range is invalid.

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Ä‚MLŒ³€,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

original[with-attachment].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 

original[with-attachment][signed].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 

A side remark

ID management: Your process adding attachments keeps the whole ID. Your signing process drops the whole original ID of the PDF and replaces it with a new one:

• original.pdf

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

• original[with-attachment].pdf

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

• original[signed].pdf

  /ID [<A9F7159B1E5D8285A68475689B750214> <A9F7159B1E5D8285A68475689B750214>] 
  

• original[with-attachment][signed].pdf

  /ID [<DC60F4419C05967B81D7F64090027D7F> <DC60F4419C05967B81D7F64090027D7F>] 
  

Both approaches are wrong, processes manipulating a PDF and, therefore, creating a new version of it, shall keep the first ID entry and replace only the second one with a unique new one.

这篇关于附件损坏签名的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！