睡一觉，扫描版 PDF 变 EPUB
睡一觉，扫描版 PDF 变 EPUB
先还原一个场景：地铁上单手举着手机，看一份 419 页的扫描版技术书。整页 A4 扫描图，字小得像蚂蚁，两指捏开放大，看三行，往右拖，再看三行——代码被扫成了图片，想复制出来搜一下都做不到。
那本"想读很久"的书，就这样在手机里躺了半年。不是你不想读，是没有人能用这种方式读完一本技术书。
解法的方向人人都知道：OCR 转成可重排的 EPUB。但自己跑 OCR 模型要么吃显卡要么调参到天亮，而且扫描书转 EPUB 的难点从来不是 OCR 本身，是识别之后的整理：切章节、去页眉、接断句、嵌图片。很多工具卡在"转出来了但没法读"。
两条现成流水线，各有各的聪明。
路线一：本地大模型挂机（pdf2epub-glmflash）
把扫描 PDF 每页渲染成图，交给多模态模型逐页转录成 Markdown，再组装成 EPUB。
关键数字：419 页，8 分钟，6 路并发。正文页抽样相似度 97%–99.6%（独立提示词重新转录逐字对比），728 个代码块、25 张表格一个没丢，流程图按 300dpi 从 PDF 裁出来嵌在原本的段落位置。
为什么传统 OCR 做不到、多模态模型可以：OCR 识别的是字符，不理解版式——代码块读成断行乱码，表格拆成碎片，插图直接消失。多模态模型是"看着整页"工作的：代码进围栏块、表格画成 Markdown、页眉页脚水印自动丢弃，2-up 双联页和双栏排版有写死的阅读顺序规则。
工程上最值得偷的是检查点设计：每页转录结果落盘，中断后重跑同一条命令，已完成的页直接跳过，一份额度不重花。挂机转书撞上限额？明晚接着来。
路线二：云端 OCR 编排（pdf2epub-paddle）
单文件 Python 脚本，349 stars，MIT。定位很克制：不是 OCR 引擎，是云服务的编排层——识别全在云端 PaddleOCR Jobs API（版面分析 PP-DocLayoutV3），本地只干四件事：提交任务、盯进度、确认元数据和目录、打包 EPUB。
两个设计细节：异步 Job 而不是同步请求（整本书同步 API 必超时）；结果 JSON 是唯一中间产物（云端只识别一次，之后重新打包不再调 API）。人在环里只出现两次——确认书名作者、过目目录，其余全自动。
怎么选
| 本地大模型挂机 | 云端 OCR 编排 | |
|---|---|---|
| 硬件 | 要能跑多模态模型 | 无要求，Python 3.8+ |
| 成本 | 模型额度 | 云 API Token |
| 代码块/表格 | 强项 | 依赖版面分析质量 |
| 隐私 | 全本地 | 整本书上云 |
| 断点 | 按页检查点 | 任务级恢复 |
有本地算力、书里代码多，走路线一；零硬件、书是纯文字，路线二一条命令的事。版权内容注意：转换自己拥有的副本自用没问题，传播是另一回事。
聊两句：你手机/网盘里躺了多久没读的扫描书？是什么书？（我先来：《TCP/IP 详解》卷一，躺了两年，转成 EPUB 之后两周读完前半本。）评论区报书名，我置顶我的转书清单和踩坑记录。
前面写过 LVS 和双模型流水线，主页可翻；下一篇是 Cursor 用一个月才懂的三件事。关注不迷路。