java pdf 签名_java – PDFBox 1.8.10：填充和签名PDF生成无效签名

OP原始问题的原因,即在用PDFBox加载PDF(用于表单填写)然后保存它之后,这个新PDF无法使用PDFBox签名代码成功签名,已在

this answer中详细解释过,短：

>定期保存文档时,PDFBox使用交叉引用表进行保存.

>如果定期保存的文档已从带有交叉引用流的PDF加载,则交叉引用流字典的所有条目都将保存在预告字典中.

>在应用签名的过程中保存文档时,PDFBox会创建增量更新;因为这样的增量更新要求更新使用与原始版本相同类型的交叉引用,在这种情况下,PDFBox会尝试使用相同的技术.

>为了识别最初使用的技术,PDFBox在其文档表示中查看字典的Type条目,其中已加载了预告片或交叉引用流字典：如果存在值为XRef的Type条目(为交叉引用流指定了该条目) ),假定流,否则为表.

因此,对于OP的原始PDF doc.pdf,它具有交叉引用流：

>加载并形成填写后,文档会定期保存,即使用交叉引用表,但所有以前的交叉引用流条目(其中包括Type)都将复制到预告片中. (doc_filled.pdf)

>使用交叉引用表加载此已保存的PDF以进行签名后,将使用增量更新再次保存该PDF. PDFBox假定(由于Type预告片条目)现有文件具有交叉引用流,因此在增量更新结束时也使用交叉引用流. (doc_filled_signed.pdf)

>因此,最后填写的,然后签名的PDF有两个修订版,内部一个带有交叉引用表,外部带有交叉引用流.

>由于这是无效的,Adobe Reader在加载PDF时会在其内部文档表示中对其进行修复.修复会更改文档字节.因此,Adobe Reader眼中的签名被打破了.

>大多数其他签名验证器不会尝试此类修复,而是按原样检查文档的签名.他们成功验证了签名.

> A：在加载表格填写的PDF后,在定期保存之前从预告片中删除“类型”条目.如果对此文件应用签名,则PDFBox将采用交叉引用表(因为误导性类型条目不存在.因此,签名增量更新将是有效的.

> B：使用增量更新来保存表单填写更改,无论是在单独运行中还是在与签名相同的运行中.这也会导致有效的增量更新.

通常我会提出后一个选项,因为如果PDFBox保存例程彼此兼容,前一个选项可能会中断.

但遗憾的是,后一种选择要求将添加和更改的对象标记为已更新,包括文档目录中的路径.如果这不可能或至少太麻烦,第一种选择可能更可取.

在手头的情况下,OP尝试了后一个选项(doc_filled_and_signed.pdf)：

At the Moment the text box’s content is only visible, when the text box is selected (with Acrobat reader and Preview the same behaviour). I flag the PDField, all of its parents, the AcroForm, the Catalog as well as the page where it is displayed.

他将更改的字段标记为已更新,但未将相关的外观流标记为PDFBox在设置表单字段值时自动生成.

因此,在结果PDF文件中,该字段具有新值,但是旧的空外观流.只有在单击该字段时,Adobe Reader才会根据要编辑的值创建新外观.

因此,OP还必须标记新的正常出现流(表单字段字典包含引用其中N引用正常出现流的字典的条目AP).或者(如果发现更改或添加的条目变得太麻烦),他可能会尝试其他选项.