如何处理 PDFMiner 提取的文本中的 CID？
Moo*_*ter 4 python pdf text pdfminer
我有一些印地语的 PDF，并且有可提取的文本。我使用pdfminer.six for python 3.6 来进行提取。输出看起来像：
如您所见，有许多字符被转换为“(cid :number)”形式。
在进一步分析中，我发现 PDF 包含将字符代码映射到字形索引的 CMAP。因此，CID 是 CMAP 表中它映射到的字形的字符标识。
但是这些字符代码与 Unicode 值有什么关系呢？基本上，PDF 查看器如何使用此映射显示字形？
此外，根据对这个类似问题的评论，这个过程可能不合法。但我并不是要窃取某人的字体。我要正文。这个过程如何成为非法的？
由于像这样的问题很多，我想澄清一下，我的目的不是解决“cid”问题。我想澄清问题的原因和违法的原因。
编辑： 这问题页的pdfminer讨论这个问题，在这里笔者清楚地说，似乎有此问题没有可靠的解决方法。是否有一些通用的基本限制（例如，无法访问字体）使此问题持续存在？
但是这些字符代码与 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）或标准化字符名称（例如space、Seven或ntilde）。文本提取器只需要知道该编码名称表示的编码或该字符名称表示的代码。
但是Encoding也可能是一个身份（Identity–H和Identity–V with character code = glyph code），它不会泄露任何东西，并且字符名称也可能是非标准化的（例如g17）。
PDF 规范说：如果这些方法无法生成 Unicode 值，则无法确定字符代码代表什么，在这种情况下，符合要求的读者可以选择他们选择的字符代码。
如果您的文本提取输出，我猜 PDF 字体有一个不完整的ToUnicode映射。
实际上，还有更多位置可以查找附加信息，例如字体程序可能包含自己的字形到 Unicode 的映射，但这些附加信息也是可选的。
......以及其非法的原因。
在上述所有选项的情况下，我没有看到任何合理的字体许可被违反，特别是因为大多数选项甚至没有查看字体程序（例如 *.ttf）本身，仅查看 PDF 元数据包装它。
另一方面，例如，如果您有想法为那些缺少这种映射的字体构建ToUnicode映射，方法是将字体的每个字形绘制到位图上，与其他任何东西很好地分开，并将 OCR 应用于它，您作为接收者PDF 突然会使用字体程序绘制原始文档以外的其他内容，这可能被视为许可证未涵盖的用法。