新的 iText Producer 字段导致验证失败答案

【问题标题】：New iText Producer field causes validation failure新的 iText Producer 字段导致验证失败
【发布时间】：2015-01-30 15:34:13
【问题描述】：

我从旧的 iText 库切换到 iTextPdf 库并注意到一个问题。新库将 producer 设置为包含非 Unicode 字符（windows TM 符号和版权符号）的值。问题是读取此文本的验证程序会卡在这些字符上。

我可以让 iText 解决这个问题（无需支付许可证费用）吗？我对 iText 获得信任感到满意。我只是希望学分是 Unicode 干净的。

<</Producer(iText® 5.5.0 ©2000-2013 iText Group NV \(AGPL-version\))/ModDate(D:20150126155550-07'00')/CreationDate(D:20150126155550-07'00')>>

【问题讨论】：

我可以让 iText 来解决这个问题（无需支付许可证费用）吗？ 是一个奇怪的问题。您是否在 AGPL 应用程序中使用 iText？如果是这样，请分享我们可以看到您的代码的 URL。您是否在其他情况下使用 iText，那么您可能无论如何都需要商业许可证。（不过也有例外。）此外，您会切换到 5.5.0 而不是 5.5.4，这很奇怪。
我这样问这个问题是因为该网站声明商业被许可人无需更改生产者的要求。我正在使用它 AGPL 并为开发贡献了代码。
好的，在这种情况下，没有问题（尽管如果您将 AGPL 项目的链接添加到您的个人资料中会有所帮助）。无论如何，正如@mkl 解释的那样：iText 中确实没有什么可以修复的。

【解决方案1】：

您正在查看 PDF 的文档信息字典，更准确地说是查看其 Producer 条目的值。指定为：

Producer 文本字符串（可选） 如果文档从其他格式转换为 PDF，则为将其转换为 PDF 的符合产品的名称。

（表 317 - 文档信息字典中的条目）

因此该值必须具有 文本字符串 类型。这又被指定为：

文本字符串类型应用于应以 PDFDocEncoding 或 UTF-16BE Unicode 字符编码方案编码的字符串。 PDFDocEncoding 可以对所有 ISO Latin 1 字符集进行编码，并记录在附件 D 中。

（第 7.9.2.2 节文本字符串类型）

在附录 D 中您可以找到：

               CHAR CODE (OCTAL)
CHAR NAME       STD MAC WIN PDF
...
©    copyright   —  251 251 251
...
®    registered  —  250 256 256
...

（D.2 拉丁字符集和编码）

因此，这些字符在这里完全有效，阻塞这些字符的验证器被破坏。

因此，您最好将此错误报告给相关验证器的开发人员。

【讨论】：