大多数 PDF 提取器使用的 API 都是错误的

大多数 PDF 工具使用的都是错误的数据源。

当开发者谈论 PDF 提取时，他们通常指的是 getTextContent()。该方法提供文本项及其位置。它是几乎所有浏览器端工具的默认选择。

但 getTextContent() 是一个经过处理的视图。它是实际可用数据的简化版本。

PDF.js 中存在三个层级的数据：

• getStructTree()：它告诉你文档的含义。它包含表格、标题和公式。 • getOperatorList()：它告诉你文档绘制了什么。它包括线条、路径和形状。 • getTextContent()：这是对文档绘制内容的过滤视图。

大多数工具使用第三种方案。这适用于 80% 的文档（如简单的报告）。然而，在处理学术论文和复杂的出版物时，它会失效。

仅使用 getTextContent() 会导致四个主要问题：

• 丢失表格结构。你必须根据文本位置来猜测单元格的位置。
• 破坏数学公式。LaTeX 公式通常表现为单个巨大的文本块。
• 遗漏分栏线。许多布局使用实际的线条来分隔栏目。这些线条在文本内容中并不存在。
• 阅读顺序错误。文本出现的顺序通常是其绘制的顺序，而不是人类阅读的顺序。

构建 PDF 处理器的正确方法是一个三层系统：

1. 首先检查 getStructTree()。如果文档具有逻辑结构，请立即使用它来查找表格和标题。
2. 接下来检查 getOperatorList()。利用明确的线条和路径来寻找分栏边界。
3. 将 getTextContent() 作为兜底方案。仅在前两个层级无法提供数据时，才使用几何数学计算。

这种方法并不会增加工作量。第一层和第二层起到了“快速退出”的作用。如果文档结构良好，你就可以跳过复杂的数学计算。只有在文档未标记（untagged）时，才需要使用复杂的推理。

这种架构既能处理简单的企业文件，也能处理复杂的科学论文。

来源：https://dev.to/bonzai2carn/most-pdf-extractors-use-the-wrong-api-heres-what-we-built-instead-5dgh