不上传文件也能转格式？拆解一个纯浏览器端的 EPUB 工具链的设计思路
在线文档转换工具几乎都有一个共同前提：你得先把文件传上去。对小说、内部资料、
未公开的稿件来说，这个前提本身就是风险。这篇文章介绍一个反其道而行的方案------
iloveepub，一个所有处理都在浏览器本地完成的 EPUB 工具站，并从技术角度拆解
它为什么可行、边界在哪里。
一、问题：「上传式转换」的三个隐性成本
主流在线转换站（包括很多知名产品）的架构是：文件 → 上传服务器 → 服务端转换 → 回传下载。这个模式对用户有三个隐性成本：
- 隐私与版权风险：文件真实离开了你的设备。转换方承诺「24 小时删除」无法被用户验证------历史上不止一家工具站的承诺与实际行为不符。
- 速度受带宽限制：一本 200MB 的漫画 EPUB，上传就要等半天，转换完还要再下载一遍，总耗时里网络占了绝大部分。
- 服务端算力成本必然转嫁：要么限次收费，要么塞广告，要么两者都有。
而 EPUB 这类格式的处理（解析、重组、格式转换）本质上是对一个 zip 包做结构操作，计算量并不大，完全在客户端能力范围内。这就是纯浏览器方案的技术立足点。
二、纯浏览器方案为什么成立
iloveepub的技术选型可以概括为"标准 Web API + 几个成熟的客户端库"：
| 环节 | 方案 | 说明 |
|---|---|---|
| 文件读取 | File API / ArrayBuffer | 文件字节停留在内存，不经过网络 |
| PDF 类型检测 | pdf-inspector（WASM） | 懒加载 + Web Worker，毫秒级判断 PDF 类型 |
| PDF 页渲染 | pdf.js | 逐页渲染到 canvas，保真路线用 |
| PDF 生成 | pdf-lib | 纯 JS 生成 PDF，无服务端依赖 |
| EPUB 解析/组装 | 自研引擎 + jszip | EPUB 本身就是 zip + XML，zip 层操作用 jszip |
几个值得注意的工程细节：
WASM 懒加载。pdf-inspector 这类 WASM 模块体积不小，如果进首屏 JS 会严重拖慢加载。它的做法是懒加载 + Web Worker，只有用到对应工具时才拉取对应 chunk。jszip 同样单独切 chunk（gzip 后约 60KB），不污染页面初始负载。
转换全程零网络请求。这是这类方案最硬的可验证性质------不是营销话术，而是可以直接验证的事实：打开浏览器 DevTools 的 Network 面板，再做一次转换，你会发现整个处理过程中没有任何携带文件数据的请求发出。文件从磁盘读进内存，处理完通过 Blob URL 或下载 API 落盘，全程不离开设备。
断网可用。页面加载完成后，转换本身不依赖网络（这是上一个性质的直接推论）。
三、工具清单与各自的技术路线
目前上线的工具覆盖了 EPUB 处理的主要场景：
| 工具 | 路线 | 典型场景 |
|---|---|---|
| EPUB → PDF | EPUB 解析 → 分页渲染 → pdf-lib 生成 | 打印、分享给不读电子书的人 |
| PDF → EPUB | pdf-inspector 解析提取 → 重排版组装 | 小屏/墨水屏上读文字版 PDF |
| EPUB → TXT / Markdown | 文本层提取 | 做笔记、全文检索、喂给 LLM |
| EPUB → KEpub | Kobo 优化格式转换 | Kobo 阅读器的章节级统计与进度 |
| Merge / Split EPUB | zip 层拼接/拆分 OPF 与 spine | 连载合并成一本、大部头拆卷 |
| Compress EPUB | 图片重采样 + 资源去重 + 重打包 | 给墨水屏设备腾存储 |
| EPUB Reader | 浏览器内渲染阅读 | 不装软件直接打开 EPUB |
| Metadata Editor | 元数据查看/修改 | 改封面、作者、书名 |
几个场景展开说一下：
PDF → EPUB 是需求最大也最容易做坏的一条线。它的正确姿势是先做 PDF 分类检测：pdf-inspector 在几十毫秒内判断这份 PDF 是文字版、扫描版还是混合版。扫描版（整页是图片）没有文字层可提取，纯浏览器方案做不了 OCR------此时正确的产品行为是明确报错「扫描版无法转换」，而不是硬转出一本空书让用户下载后发现白屏。这个「守门」逻辑值得所有做转换工具的产品借鉴。
EPUB → Markdown 在 LLM 时代的价值在上升。把书变成干净的 Markdown 文本后，全文检索、笔记摘录、与 AI 对话讨论内容，都比在阅读器里截图方便得多。
Compress 走的是 zip 层优化：EPUB 体积大头通常是过度采样的插图，重采样加重复资源去重后重新打包，对图册类书籍效果明显。
四、如何亲自验证「不上传」
与其相信隐私声明，不如花 30 秒验证一下。任何声称「本地处理」的工具都可以用同样的方法检验：
- 按
F12打开 DevTools，切到 Network 面板 - 勾选
Preserve log（保留日志） - 上传文件并完成一次完整转换
- 检查请求列表：处理过程中应该没有任何 POST/PUT 请求携带你的文件数据
如果转换时你看到大流量的上行请求，那「本地处理」就是话术。这套验证方法适用于所有同类工具站，不限于这一个。
五、边界与局限（诚实版）
纯浏览器方案不是没有代价，列清楚比回避更有意义：
- 不做 OCR：扫描版 PDF 只有图像像素没有文字层，浏览器端没有靠谱的 OCR 路径，这类输入会被明确拒绝而不是产出损坏结果。
- 大文件受内存限制：WASM 在内存中处理，上百 MB 的文件在低配手机上可能有压力，站内对超大文件有明确提示。
- 极端复杂排版的保真度：EPUB → PDF 的重排版路线以可读性优先，不承诺像素级还原原书设计。
六、适用人群
- 墨水屏/Kindle/Kobo 用户：文字版 PDF 转 EPUB、KEpub 输出、大书压缩
- 网文/连载读者：批量合并章节文件、拆卷
- 做笔记和知识管理的人：EPUB → Markdown/TXT 提取
- 对文件隐私敏感的任何人：内部资料、未出版稿件、私密书库
免费、无注册、无次数限制，界面支持中英文等多语言。地址：iloveepub，感兴趣的可以自己去验证第三节的方法。
如果这篇对你有启发，比起记住这个网站，更值得记住的是它背后的架构判断：能在客户端完成的处理就不要搬到服务端------省掉的不只是服务器账单，还有用户最不该交出去的信任。