问如何处理PDFMiner提取的文本中的CID？

EN

但是这些字符代码与Unicode值有什么关系呢？基本上，PDF查看器如何使用此映射显示字形？

在PDF内容流中找到的字符代码不需要以任何明显的方式与Unicode值相关。特别是，PDF查看器根本不需要Unicode代码点，字符代码就可以显示匹配的字形。

在PDF中，字体在字体程序中有一个从字符代码到字形ID的映射(或一系列映射)，这种映射可以是完全任意的。

例如，在嵌入字体子集的情况下，子集字体程序通常是通过给予页面上使用的第一个字形起始字形id n，然后给出该页面上的第二个不同字形id n+1，然后是下一个不同字形id n+2等等，然后字符代码通常与字形id相同，即上面的映射是身份映射来创建的。如果不再有额外的信息，文本提取器就没有机会正确地完成其工作。

我想弄清楚这个问题的原因

常规文本提取通常具有以下选项来查找字符代码的Unicode值：

• PDF字体可以包括ToUnicode映射(从字符代码映射到Unicode)，以支持在PDF查看器中搜索字符串或复制和粘贴等操作。此映射立即提供文本提取器所需的映射。

不过，请注意:这些ToUnicode映射可能不完整，有时甚至包含故意不正确的映射！

对于给定的代码，PDF字体编码定义可以包含预定义标准编码的名称(例如WinAnsiEncoding或GBpc-EUC-H)或标准化字符名称(例如

• 、或ntilde< code >E223)。文本提取器只需要知道由该编码名称表示的编码或由该字符名称表示的代码。

但是编码也可以是不提供任何东西的身份(具有字符码=字形码的 identity -H和Identity-V)，并且字符名称也可以是非标准化的(例如g17).

PDF规范说:如果这些方法不能产生Unicode值，就没有办法确定字符代码代表什么，在这种情况下，符合标准的阅读器可以选择他们选择的字符代码。

在你的文本提取输出中，我猜PDF字体有一个不完整的ToUnicode映射。

实际上，有更多的位置可以查找额外的信息，例如，字体程序可能包括自己的字形到Unicode的映射，但这些额外的信息也是可选的。

...以及它非法的原因。

在所有上述选项的情况下，我没有看到任何合理的字体许可证被违反，特别是因为这些选项中的大多数甚至没有查看字体程序(例如*.ttf)本身，只是查看包装它的PDF元数据。

另一方面，如果您想通过将字体的每个字形绘制到位图上并应用光学字符识别来为那些缺少这种地图的字体构建ToUnicode地图，那么作为PDF的接收者，您可能会突然使用字体程序来绘制原始文档之外的其他内容，这可能被视为许可证所不涵盖的用途。