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