PDFBOX2.X-从acroForm读取错误的数据

Question

从acroform读取数据时我们面临问题。

我们正在使用PDFBOX2.x版本创建PDF文件。我们的目标是使pdf可执行文件，这意味着我们可以下载包含acroform的pdf文件。我们可以收集数据，以后再上传以与数据库同步。

我们面临的问题是PDFBox调试器，或者我们可以在上传文件中说。我们的文本框值会自动更改。

请在下图中查看更多详细信息。

我们已使用PDF调试器工具检查PDF内容。您可以看到totalBuyoffCount值为0。但是应该为3。

我已经使用iTextDebugger检查相同的字段

这是完全随机的行为，我们注意到以下情况

有时0或1的值变为N或Y 很少有字段受到影响，但是如果将其转换为字符串值，则会导致NumberFormat异常。 这会使我们的整个文件损坏。

如果它不能被固定，那么您能告诉我我们需要看哪个区域，以便我们能够理解和调试其值更改的原因或从何处获取值，以便在发现时可以更改或覆盖它。行为

Answer 1

看着有问题的PDF对象（1499，第0代）

1499 0 obj
<<
/FT /Tx
/Q 0
/V (0)
/Ff 1
/Rect [0.0 1.0 1.0 1.0]
/Type /Annot
/Subtype /Widget
/T <77A2A671303FC282631C0C903EA8F40F>
/DA <2C85B77C2A5D81D53C5A3EB571EDBA1C>
/F 6
>>
endobj 

因此可能会想说您看到“ / V（0）”。而不是3。

虽然这是正确的，但不幸的是，由于文件已加密，因此意义不大！

因此，问题归结为对象1499中的字符串0（第0代）是解密为“ 0”还是解密为“ 3”。

我自己还没有实现PDF解密器，所以我不能声称要用自己的代码进行检查。

我能做的第二件事就是检查Adobe将其解密的内容。我的旧版Adobe Acrobat 9.5 Preflight显示如下：

很显然，Adobe就像iText一样，将0解密为“ 3”。使用在线PDF解密程序进行的额外检查或两个检查均支持此解密结果。

因此，看来PDFBox无法正确解密此0字符串。

考虑到OP的进一步观察，“有时0或1的值变为N或Y几乎没有影响的字段” 看起来PDFBox有时不能正确解密单个字符串。

另一种选择是，相关文件的加密参数存在问题。我真的不相信这一点，但是我不能排除它。

错误

正如Tilman在对PDFBOX-4453的评论中所暗示的那样，该错误是由于PDFBox的方式，尤其是SecurityHandler跟踪哪些对象已经被解密以及哪些对象仍然必须被解密。 ：已经解密的对象存储在HashSet SecurityHandler.objects中；当要求SecurityHandler.decrypt解密对象时，equals首先检查该对象是否在该集合中，只有当它不在该集合中时，它实际上才被解密并添加到集合中。

因此，如果仍然加密的对象totalBuyoffCount已经被解密，则调用对该加密对象进行解密将根本不起作用。

在手头的文件中，有一个字符串被解密为“ 0”。因此，当将0，SecurityHandler的加密值发送到{{1}}进行解密时，错误地认为该值已被解密，因此它保持原样。 >

对于更长的字符串，这通常没有问题，因为它们的加密版本通常完全乱码，因此不会在已经解密的对象中找到它们。另一方面，短字符串（尤其是单字符字符串）可能具有有意义的加密版本，因此可能会发生冲突。

解决此问题的选项在参考的Apache Jira问题中进行了讨论。一种选择是用所讨论的单个对象的标志替换提到的集合，但是其他选择也是可能的。