如果您真的可以从 PDF 中 grep 给定字符串(您可以“看到”并在渲染或打印的 PDF 页面上阅读),即使在 的帮助下pdftotext
,那么您一定非常幸运。
首先:您提供的链接中的大多数建议unix.stackexchange.com
都非常不知情(最礼貌地说)。那里的大多数答案显然是由不熟悉大量 PDF 变体的人写的。
在您的情况下,您首先尝试转换文件,pdftotext
将输出流式传输到stdout。
有许多类型的 PDFpdftotext
根本无法提取文本。造成这种情况的原因可能是(以下列表不完整):
您看到的“文本”不是基于使用字体。它可能是由扫描或其他生产过程生成的一个大光栅图像,然后嵌入到 PDF 文件外壳中。这可能会使页面看起来只是文本字符串。
您看到的“文本”不是基于使用字体。它可能是一系列小的矢量图(或小的光栅图像),在我们的眼睛和大脑看来只是文本字符串。
有许多软件应用程序可以将字体转换为所谓的“轮廓”。这种看似奇怪的行为的原因可能是:
- 规避许可问题(当某种字体不允许其嵌入时)。
- 对提取文本的尝试施加障碍。
- PDF 生成应用程序中的意外设置错误。
字体作为子集嵌入在 PDF 文件中(由 PDF 生成软件——用户通常对此操作的细节没有太多控制)并使用“自定义”编码,但文件不提供toUnicode
表格将字形映射到字符。
“字形”是在屏幕上绘制的每种字体中定义明确的形状。字形映射到计算机的字符——我们的眼睛只看到这些形状,我们的大脑将这些转换为字符而不需要toUnicode
表格。像这样的程序pdftotext
需要一个toUnicode
表格来将字形转换回字符。
您可以使用名为的命令行实用程序pdffonts
来初步了解 PDF 文件使用的字体。示例输出:
pdffonts paper-projectiris---final.pdf
name type encoding emb sub uni object ID
-------------------------- ------------ -------------- --- --- --- ---------
TCQJEF+CMCSC10 Type 1 Builtin yes yes no 96 0
VPAFLY+CMBX12 Type 1 Builtin yes yes no 97 0
CWAIXW+CMTI12 Type 1 Builtin yes yes no 98 0
OBMDLT+CMR12 Type 1 Builtin yes yes no 99 0
在这种情况下,文本提取(以及您对字符串的 grepping 方法)应该可以工作:
- 即使名为的列
uni
(告诉toUnicode
PDF 文件中是否嵌入了映射)说明no
了每种字体,但该encoding
列不包含custom
, 但是builtin
(意味着字体文件提供了字形->字符映射,其类型为Type 1
.
总结一下:如果无法访问您的 PDF 文件,就不可能知道为什么您不能“grep”您正在寻找的字符串!