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

Question

我有一些印地语的PDF，并且有可提取的文字。我使用pdfminer.six进行python 3.6来进行提取。输出如下：

可以看出，有许多字符被转换为表格＆＃34;（cid：number）＆＃34;。

在进一步分析中，我发现PDF包含将字符代码映射到字形索引的CMAP。因此，CID是它映射到的字形的字符标识，在CMAP表中。

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

此外，根据对this类似问题的评论，此过程可能不合法。但我并没有试图窃取别人的字体。我想要文字。这个过程如何变得非法？

由于有很多类似这样的问题，我想澄清一点，我的目标不是要解决这个＆＃34; cid＆＃34;问题。我想澄清问题的原因及其非法性的原因。

编辑： This issues page pdfminer讨论了此问题，作者明确表示此问题似乎没有可靠的解决方法。是否有一些普遍的，基本的限制（比如，无法访问字体）会使这个问题不断发生？

Answer 1

  

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

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

在PDF中，字体具有从字符代码到字体程序中的字形ID的映射（或映射序列），并且此映射可能完全是任意的。

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

  

我想澄清问题的原因

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

• PDF字体可能包含 ToUnicode 地图（从字符代码映射到Unicode）以支持搜索字符串或复制＆amp ;;等操作。粘贴在PDF查看器中。该映射立即提供了文本提取器所需的映射。

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

• PDF字体编码定义可能包含预定义标准编码的名称（例如 WinAnsiEncoding 或 GBpc-EUC-H ）或标准化字符给定代码的名称（例如空格，七或 ntilde ）。文本提取器只需要知道该编码名称所代表的编码或该字符名称所代表的代码。

  但编码也可能是一个标识（标识-H 和标识-V ，字符代码=字形代码< / em>）不会泄露任何东西，字符名称也可能是非标准化的（例如 g17 ）。

PDF规范说：如果这些方法无法生成Unicode值，则无法确定字符代码代表什么，在这种情况下，符合本标准的读者可以选择自己选择的字符代码。

如果您的文本提取输出我猜测PDF字体有一个不完整的 ToUnicode 地图。

实际上还有一些地方可以查找其他信息，例如字体程序可能包含自己的字形到Unicode的映射，但这些附加信息也是可选的。

  

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

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

另一方面，如果是您有想法为缺少这样的地图的那些字体构建 ToUnicode 地图，方法是将字体的每个字形绘制到位图上，与其他任何东西完全分开，并将OCR应用于它，您作为接收者PDF突然会使用字体程序绘制除原始文档之外的其他内容，这可能被认为是许可证未涵盖的用法。