今天一下午写了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. 正则对数据处理是一个好想法