但是这些字符代码与Unipre值有何关系？基本上，PDF查看器如何使用此映射显示字形？
在PDF内容流中找到的字符代码不需要以任何明显的方式与Unipre值相关。特别是，PDF查看器根本不需要Unipre代码点来显示字符代码以显示匹配的字形。
在PDF中，字体在字体程序中具有从字符代码到字形ID的映射（或映射序列），并且这种映射可能是完全任意的。
例如，在嵌入字体子集的情况下，子集字体程序常常是通过给予一个页面上使用的第一个字形的起始字形ID创建 Ñ ，然后给予第二，不同的字形在该页面ID 的n
+ 1 ，再下，不同的字形id n + 2
等，然后字符代码通常与字形id相同，即上面的映射是身份映射。如果不再有其他信息，则文本提取器将没有机会正确执行其工作。
我想澄清问题的原因
常规文本提取通常具有以下选项来查找字符代码的Unipre值：
- PDF字体 可能 包含 ToUnipre 映射（从字符代码到Unipre的映射），以支持诸如搜索字符串或在PDF查看器中复制和粘贴的操作。该映射立即提供了文本提取器所需的映射。
但是要当心：这些 ToUnipre 映射可能不完整，有时甚至包含故意不正确的映射！
- PDF字体编码定义可以包含给定代码的预定义标准编码（例如 WinAnsiEncoding 或 GBpc-EUC-H ）的名称或标准化字符名称（例如 space ， 7 或 ntilde ）。文本提取器仅需要知道该编码名称表示的编码或该字符名称表示的代码。
但是， 编码 也可能是不提供任何内容的身份（ Identity–H 和 Identity–V ， 其字符代码=字形代码
），并且字符名称也可能未标准化（例如 g17 ）。
PDF规范说： 如果这些方法无法产生Unipre值，则无法确定字符代码代表什么，在这种情况下，合格的读者可以选择他们选择的字符代码。
如果您的文本提取输出，我想PDF字体具有不完整的 ToUnipre 映射。
实际上，还有更多位置可以查找其他信息，例如，字体程序可能包括其字形到Unipre的自己映射，但是这些其他信息也是可选的。
…及其违法原因。
在上述所有选项的情况下，我看不到任何明智的字体许可证被侵犯，特别是因为大多数这些选项甚至没有查看字体程序（例如*
.ttf）本身，而只是查看了PDF元数据包装它。
另一方面，例如，如果您有想法通过将字体的每个字形绘制到位图上并与其他任何东西很好地分开并对其应用OCR，来为那些缺少此类映射的字体构造
ToUnipre 映射，则您是该对象的接收者PDF突然会使用字体程序绘制原始文档以外的其他内容，这可能被视为许可证未涵盖的用法。
