我目前正在使用tm包中的readPDF()函数从多个PDF中抓取一些文本数据。这一切都很有效,在大多数情况下,编码似乎是“latin1” - 但在某些情况下,它并非如此。 R中是否有一种检查字符编码的好方法?我在tau包中找到了函数is.utf8()和is.local(),但这显然只能让我到目前为止。
感谢。
答案 0 :(得分:1)
PDF规范定义了简单字体(每个字体最多可包含256个字符形状)的编码,用于拉丁文本,应在任何符合标准的阅读器中预定义:
/StandardEncoding
强> /MacRomanEncoding
强> /PDFDocEncoding
强> /WinAnsiEncoding
强> /MacExpertEncoding
强> 然后有两种符号字体的特定编码:
此外,字体可以有内置编码,这可能会偏离其创建者想要的标准编码(当嵌入标准字体时,也可用于差异编码是子集)。
因此,为了正确解释PDF文件,您必须查找所用字体的每种字体编码,并且必须使用/Encoding
数组考虑任何/Differences
太
但是,简单字体的整体任务仍然非常简单。 PDF查看器程序只需要映射1:1 “每个字节序列中的每一个我看到的意思是表示文本字符串”到“正好是一个字形供我绘制哪个我可以在编码表中查找“。
对于复合,CID键控字体(可能包含数千个字符形状),的查看器程序的查找/映射“这是我看到的字节序列我应该绘制文本“ to ”这是绘制“不再是1:1的字形形状序列。这里,需要解码一个一个或多个字节的序列,以从CIDFont中选择每个一个字形。
为了帮助这个CIDFont解码,需要有 CMap 结构。 CMaps定义从Unicode编码到字符集的映射。 PDF规范为中文,日文和韩文字体定义了至少5打CMaps及其标准名称。这些预定义的CMap不需要嵌入到PDF中(但符合要求的PDF阅读器需要知道如何正确处理它们)。但是(当然)还有自定义CMap,当PDF创建应用程序写出PDF时,它可能是“动态”生成的。在这种情况下,CMap需要嵌入PDF文件中。
有关这些复杂性的所有详细信息都在official PDF-1.7 specification。
中答案 1 :(得分:1)
我对R不太了解。但是我现在已经在CRAN上找了一下,看看提到的 tm 和 tau 包是什么。
所以 tm 用于文本挖掘,对于PDF阅读,它需要并依赖于Poppler的pdftotext
实用程序。我起初[明显错误]的印象是,你提到的 readPDF()函数正在对PDF文件中的PDF对象进行一些低级的,基于库的访问....如何错我曾是!事实证明它“仅”查看pdftotext
命令行工具的文本输出。
现在,这解释了为什么你可能无法成功阅读任何使用比“简单”Latin1更复杂的字体编码的PDF。
我担心,问题的原因是目前Poppler和pdftotext
根本无法处理这些问题。
也许您最好向 tm 维护人员询问功能请求: - )