如何处理 PDFMiner 提取的文本中的 CID？
What to do with CIDs in text extracted by PDFMiner?
我有一些印地语的 PDF，并且有 extractable 文本。我使用 pdfminer.six for python 3.6 来进行提取。输出如下：
可以看出，有许多字符被转换为“(cid :number)”形式。
在进一步分析中，我发现 PDF 包含将字符代码映射到字形索引的 CMAP。因此，CID 是它映射到的字形的字符标识，位于 CMAP table.
内
但是这些字符代码与 Unicode 值有什么关系呢？基本上，PDF 查看器如何使用此映射显示字形？
此外，根据对this类似问题的评论，此过程可能不合法。但我不是想偷别人的字体。我要正文。这个过程如何成为非法的？
既然这样的问题很多，我想说明一下，我的目的不是要解决"cid"这个问题。我想澄清问题的原因和不合法的原因。
EDIT: This issues page for pdfminer 讨论了这个问题，作者明确表示这个问题似乎没有可靠的解决方法。是否有一些一般的基本限制（例如，无法访问字体）导致此问题持续存在？
But how are these character codes related to Unicode values? Basically, how is a PDF viewer able to show the glyph using this mapping?
在 PDF 内容流中找到的字符代码不需要以任何明显的方式与 Unicode 值相关。特别是，PDF 查看器根本不需要字符代码的 Unicode 代码点来显示匹配的字形。
在 PDF 中，字体具有从字符代码到字体程序中的字形 ID 的映射（或一系列映射），并且此映射可能完全是任意的。
例如在嵌入字体子集的情况下，子集字体程序通常是通过为页面上使用的第一个字形提供起始字形 ID n，然后在该页面上提供第二个不同的字形 ID n+1，然后是下一个不同的字形 ID n+2 等等，然后字符代码通常与字形 ID 相同，即上面的映射是身份映射。如果不再有附加信息，文本提取器就没有机会正确地完成它的工作。
I want to clarify the reasons for the problem
常规文本提取通常有以下选项来查找字符代码的 Unicode 值：
PDF 字体 可能 包含一个 ToUnicode 映射（从字符代码到 Unicode 的映射）以支持诸如在 PDF 查看器中搜索字符串或复制和粘贴。此映射立即提供文本提取器所需的映射。
但请注意：这些 ToUnicode 映射可能不完整，有时甚至包含故意不正确的映射！
PDF 字体编码定义可能包含预定义标准编码的名称（例如 WinAnsiEncoding 或 GBpc-EUC-H ) 或标准化字符名称（例如 space、seven 或 ntilde) 对于给定的代码。文本提取器只需要知道由该编码名称表示的编码或由该字符名称表示的代码。
但是Encoding也可能是一个identity（Identity–H and Identity–V with character code = glyph code) 这不会泄露任何东西，字符名称也可能是非标准化的（例如 g17） .
PDF 规范说：如果这些方法无法生成 Unicode 值，则无法确定字符代码代表什么，在这种情况下，符合要求的 reader 可能会选择一个字符他们选择的代码。
在你的文本提取输出的情况下，我猜想 PDF 字体有一个不完整的 ToUnicode 映射。
实际上还有更多位置可以查找其他信息，例如字体程序可能包含其字形到 Unicode 的映射，但这些附加信息也是可选的。
... and reasons for it's illegality.
在所有上述选项的情况下，我没有看到任何合理的字体许可证被违反，特别是因为大多数选项甚至没有查看字体程序（例如 *.ttf）本身，仅仅是放入包装它的 PDF 元数据中。
另一方面，如果例如您有想法为那些缺少此类映射的字体构建 ToUnicode 映射，方法是将字体的每个字形绘制到位图上，与其他任何内容很好地分开，然后对其应用 OCR，您作为PDF 的收件人突然使用字体程序绘制原始文档以外的其他内容，这可能被视为未涵盖在许可范围内的用法。
我有一些印地语的 PDF，并且有 extractable 文本。我使用 pdfminer.six for python 3.6 来进行提取。输出如下：
可以看出，有许多字符被转换为“(cid :number)”形式。
在进一步分析中，我发现 PDF 包含将字符代码映射到字形索引的 CMAP。因此，CID 是它映射到的字形的字符标识，位于 CMAP table.
内但是这些字符代码与 Unicode 值有什么关系呢？基本上，PDF 查看器如何使用此映射显示字形？
此外，根据对this类似问题的评论，此过程可能不合法。但我不是想偷别人的字体。我要正文。这个过程如何成为非法的？
既然这样的问题很多，我想说明一下，我的目的不是要解决"cid"这个问题。我想澄清问题的原因和不合法的原因。
EDIT: This issues page for pdfminer 讨论了这个问题，作者明确表示这个问题似乎没有可靠的解决方法。是否有一些一般的基本限制（例如，无法访问字体）导致此问题持续存在？
But how are these character codes related to Unicode values? Basically, how is a PDF viewer able to show the glyph using this mapping?
在 PDF 内容流中找到的字符代码不需要以任何明显的方式与 Unicode 值相关。特别是，PDF 查看器根本不需要字符代码的 Unicode 代码点来显示匹配的字形。
在 PDF 中，字体具有从字符代码到字体程序中的字形 ID 的映射（或一系列映射），并且此映射可能完全是任意的。
例如在嵌入字体子集的情况下，子集字体程序通常是通过为页面上使用的第一个字形提供起始字形 ID n，然后在该页面上提供第二个不同的字形 ID n+1，然后是下一个不同的字形 ID n+2 等等，然后字符代码通常与字形 ID 相同，即上面的映射是身份映射。如果不再有附加信息，文本提取器就没有机会正确地完成它的工作。
I want to clarify the reasons for the problem
常规文本提取通常有以下选项来查找字符代码的 Unicode 值：
PDF 字体 可能 包含一个 ToUnicode 映射（从字符代码到 Unicode 的映射）以支持诸如在 PDF 查看器中搜索字符串或复制和粘贴。此映射立即提供文本提取器所需的映射。
但请注意：这些 ToUnicode 映射可能不完整，有时甚至包含故意不正确的映射！
PDF 字体编码定义可能包含预定义标准编码的名称（例如 WinAnsiEncoding 或 GBpc-EUC-H ) 或标准化字符名称（例如 space、seven 或 ntilde) 对于给定的代码。文本提取器只需要知道由该编码名称表示的编码或由该字符名称表示的代码。
但是Encoding也可能是一个identity（Identity–H and Identity–V with character code = glyph code) 这不会泄露任何东西，字符名称也可能是非标准化的（例如 g17） .
PDF 规范说：如果这些方法无法生成 Unicode 值，则无法确定字符代码代表什么，在这种情况下，符合要求的 reader 可能会选择一个字符他们选择的代码。
在你的文本提取输出的情况下，我猜想 PDF 字体有一个不完整的 ToUnicode 映射。
实际上还有更多位置可以查找其他信息，例如字体程序可能包含其字形到 Unicode 的映射，但这些附加信息也是可选的。
... and reasons for it's illegality.
在所有上述选项的情况下，我没有看到任何合理的字体许可证被违反，特别是因为大多数选项甚至没有查看字体程序（例如 *.ttf）本身，仅仅是放入包装它的 PDF 元数据中。
另一方面，如果例如您有想法为那些缺少此类映射的字体构建 ToUnicode 映射，方法是将字体的每个字形绘制到位图上，与其他任何内容很好地分开，然后对其应用 OCR，您作为PDF 的收件人突然使用字体程序绘制原始文档以外的其他内容，这可能被视为未涵盖在许可范围内的用法。