关于 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. 正则对数据处理是一个好想法
相关推荐
小墨宝3 小时前
js 生成pdf 并上传文件
前端·javascript·pdf
热水养鲨鱼8 小时前
Java实现HTML转PDF(deepSeekAi->html->pdf)
人工智能·pdf·html
开开心心_Every20 小时前
体积小巧的 Word 转 PDF 批量工具
pdf
一眼青苔20 小时前
切割PDF使用python,库PyPDF2
服务器·python·pdf
zyk_5201 天前
前端渲染pdf文件解决方案-pdf.js
前端·javascript·pdf
IDRSolutions_CN1 天前
如何将 PDF 中的文本提取为 JSON 格式
java·经验分享·pdf·软件工程·团队开发
南博萬1 天前
java将pdf转换成word
java·pdf·word
zhishishe1 天前
2025 年免费 Word 转 PDF 转换器有哪些?
android·windows·pdf·电脑·word
.m2 天前
几种Word转换PDF的常用方法
pdf
前端开心果2 天前
vue实现静默打印pdf
前端·vue.js·pdf