使用PDFBox 2.x从PDF中提取文本时合并行的问题

Question

使用PDFBox 2.x从PDF中提取文本时合并行的问题

3

我在使用PDFBox 2.0.13的PDFTextStripper提取PDF文本时遇到了问题。更具体地说，过于接近的行被合并在一起。例如：

第一行有文本“signfieldbig”，第二行包含下划线，但是PDFTextStripper将其解析为“s_i_g_n_fi_e_ld_b_ig_ _______”（它将两行合并成了一行）。我尝试了多种设置（不同的lineSeparator、treshold等），但没有帮助。这两行每次都会合并，我不能简单地从文本中删除所有不必要的字符，因为我正在寻找此占位符的位置以创建签名字段。

更新：我刚刚意识到造成这个问题的原因-在原始文件中，并没有两个由换行符分隔的正常行，而是一个带有下划线和手动放置的文本区域“placeholder”的行。但是，PDF查看器（将其视为文本）或其他PDF库（iText 2.x）将其解析为两个单独的行...

- mi0

1

如果您使用AcroForm进行字段操作，则占位符并不重要。 - logger

实际上，如果有下划线，那么将它们提取出来是正确的。如果文本的高度与下划线相同，很明显它们可能会混淆。 - mkl

@logger：我不是PDF文件的创建者，因此我需要占位符来知道在哪里放置字段 :) - mi0

@mkl 问题在于 PDFTextStripper 忽略了换行符。原始的 Word 文件中，存在换行符（表示有两行文本），在转换为 PDF 文件后，有两行文本，在文本查看器中查看 PDF 文件时显示为两行，即使使用另一个 PDF 库（旧版 iText 2.x）解析 PDF 文件也会显示为两行...只有 PDFBox 将它们合并在一起。为什么它忽略了换行符却像 OCR 一样工作呢？ - mi0

2

那个新的换行分隔符不在 pdf 中。一个 pdf 基本上包含诸如“在 [坐标] 处绘制 [文本块]”之类的指令。如果不同块的 y 坐标足够接近，文本提取器可能会认为它们在同一行上；但不同的文本提取器在它们对“足够接近”的概念上存在差异。在文本拾取器中使用 setSortByPosition(false) 可能会有所帮助。 - mkl

@mkl 你是老板！！是的，那很有帮助。谢谢！请发布一个简短的回复，以便我可以将其标记为正确答案 :) - mi0

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- mkl · Accepted Answer

有不同的文本提取策略，可以按照文本块的顺序进行提取，并在新的文本块坐标不紧跟在前一个文本块之后时，只添加一个新行或类似的内容；或者可以收集所有文本块，按照坐标排序，然后从这些排序后的文本块中提取文本。（显然，这两种策略类型可以与一定程度的文本布局分析相结合。）

在您的情况下，排序是激活的，导致下划线和上方的文本被连接成“s_i_g_n_fi_e_ld_b_ig_ _______”。

您可以在pdfbox文本剥离器中使用“setSortByPosition(false)”来禁用排序。

没有通用的最佳方法，具体取决于所涉及的文档，其中一种方法可能更好。