关于 PDF 抽取的吐槽

今天一下午写了8,9个 PDF 抽取的脚本。最后又回归最开始简单的模式了,要疯了,谁懂啊。

我是下午的工作是这样的(我是这么疯的)

  1. 最开始使用最简单的策略,先使用 PyPDF2.PdfReader(file) 读取文件,然后在每一页使用 page.extract_text() 提取文字。如果不足 50 个字认为是图片,使用 OCR 识别。其实发现效果还是不错的
  2. 但是不安分的我开始想,我记得有一个库叫pdfplumber,它对表格信息友好,且能识别图片。所以,我就想,如果我的脚本可以提前甄别图片、表格和纯文本,分别对他们进行OCR、pdfplumber提取表格和pypdf提取文本,那岂不是无敌了。结果,,,,一步错步步错
  3. 首先是pdfplumber提取表格的效果,真的很糟糕,经常提取出来一堆空白
  4. 其次是考虑OCR的时候,把OCR当回事的时候,真的会吃大亏。
    a. 直接对 PDF 使用 OCR,会出现大范围的乱码
    b. 对图片进行灰度处理和二值化处理,效果会好一些,但是仍然不如直接使用pypdf提取文字的效果
    c. 所以我又使用 opencv 进行降噪和对损失的图片进行还原,使用的是qpdf,发现结果好点,但还是不如直接用pypdf
    c. 把图像转换成base64的格式,这个我做出来了,后来想想,我真是个东西啊,我做出来这玩意有啥用,没用啊,我的工作内容用不到这啊
  5. 在进行表格和图像处理优化的时候,我想到了多线程。结果多线程也是个坑,用了多线程不一定会加速。我严重怀疑是因为我没用队列控制线程的排队。因为我之后写划分chunk 代码的时候用了Queue进行线程排队,又快又没有出现cache丢失或充写的情况
  6. 最后回归最开始的方案,因为要考虑源信息,使用json存文件了(其实我认为用jsonl更好)
  7. 作为优化,我使用了正则对文本数据进行了处理

总结

  1. 多线程用不好的话,效果不一定好。最好处理好排队的逻辑
  2. OCR 是一个坑,慎用
  3. jsonl 对并行处理更友好
  4. 正则对数据处理是一个好想法
相关推荐
穆友航5 小时前
PDF内容提取,MinerU使用
数据分析·pdf
拾荒的小海螺1 天前
JAVA:探索 PDF 文字提取的技术指南
java·开发语言·pdf
村东头老张1 天前
Java 实现PDF添加水印
java·开发语言·pdf
好美啊啊啊啊!1 天前
Thymeleaf模板引擎生成的html字符串转换成pdf
pdf·html
zhentiya2 天前
曼昆《经济学原理》第八版课后答案及英文版PDF
大数据·pdf
三天不学习2 天前
如何解决pdf.js跨域从url动态加载pdf文档
javascript·pdf
吾店云建站2 天前
9个最佳WordPress PDF插件(查看器、嵌入和下载)
程序人生·pdf·创业创新·流量运营·程序员创富·教育电商
007php0072 天前
基于企业微信客户端设计一个文件下载与预览系统
开发语言·python·docker·golang·pdf·php·企业微信
慧都小妮子2 天前
Spire.PDF for .NET【页面设置】演示:更改 PDF 页面大小
前端·pdf·.net