关于 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. 正则对数据处理是一个好想法
相关推荐
inxunoffice3 小时前
批量将文本文件转换为 Word/PDF/Excel/图片等其它格式
pdf·word·excel
人工智能教学实践5 小时前
【爬虫脚本】实现批量pdf文件下载
pdf
海峰教授1 天前
扫描仪+文档pdf编辑器+pdf格式转换器
pdf
Li_na_na011 天前
解决安卓手机WebView无法直接预览PDF的问题(使用PDF.js方案)
android·pdf·uni-app·html5
背太阳的牧羊人1 天前
使用 PyMuPDF(fitz)库打开 PDF 文件,并且是从内存中的字节流(BytesIO)读取 PDF 内容
数据库·pdf·文件处理·pymupdf·fitz
灯火不休ᝰ1 天前
前端处理pdf文件流,展示pdf
前端·pdf
梨小橙子1 天前
PPT画图,如何用Visio转化为pdf,且无白边
pdf·powerpoint
云只上1 天前
解决Luckysheet在线预览编辑Excel、PDF.....无法在同一个界面创建多个luckysheet实列问题
pdf
inxunoffice1 天前
批量给 PDF 添加页眉页脚以及页码信息
前端·javascript·pdf
学c真好玩1 天前
4.1-python操作wrod/pdf 文件
开发语言·python·pdf