1。“regex”方法行不通!在
你想要的东西是不可能的!简单明了的回答。在
原因:
对于一般情况,不能使用regex在PDF文本中查找“匹配项”。我甚至不会在这里谈论Unicode字符。。。在
我只考虑问题中示例中的简单文本字符串:match。在
在PDF源代码中,这个字符串可以以不同的形式出现,这取决于PDF生成软件以及使用的字体编码的确切字体。以下列表不完整!在(match) Tj # you are lucky
<6d61746365> Tj # hex representation of characters
<6d 61 74 63 65> Tj # hex representation of characters, v2
<6d 61 7463 65> Tj # hex representation of characters, v3
<6d>Tj <61> Tj<746365>Tj # hex representation of characters, v4
.... # skipping version 5-500000000 of all...
# ...possible hex representations
(\155\141\164\143\150) Tj # octal representation of characters
(m\141\164ch) Tj # octal/ascii mixed representation of chars
(\155a\164ch) Tj # octal/ascii mixed representation of chars, v3
<6d 61>Tj (\164c\150) Tj # hex/octal/ascii mix
.... # skipping many more possibilities
甚至,如果字符串应该使用的字体确实使用了自定义编码(就像字体作为一个子集嵌入到PDF中,只包含在相应文本中使用的这些字形)的情况也会变得更加复杂。在
这可能意味着上面的<6d61746365> Tj可以变成<2234567111> Tj,但是它仍然会在PDF页面上显示match。在
2。获得相似结果的变通方法可能会奏效您可以使用pdftotext -layout some.pdf some.txt创建一个包含PDF文本的文件。(这不可靠。有些PDF,例如那些缺少一个有效的/ToUnicode表的PDF,将不容易用于文本提取。)
这可以引导您找到匹配的页码。在
使用(有一些尝试性的错误)pdftotext -f 33 -l 33 -layout -x NN -y MM -W NN -H MM可以更精确地缩小第33页上匹配项的位置。在
使用pdftotext -layout -bbox -f 33 -l 33将返回第33页上每个单词的边框坐标。
您也可以使用文本提取工具包来查找匹配单词的精确坐标。TET甚至可以给你单个字形的坐标。
一旦确定了匹配项的位置,就可以使用