不上传文件也能转格式？拆解一个纯浏览器端的 EPUB 工具链的设计思路

不上传文件也能转格式？拆解一个纯浏览器端的 EPUB 工具链的设计思路

在线文档转换工具几乎都有一个共同前提：你得先把文件传上去。对小说、内部资料、
未公开的稿件来说，这个前提本身就是风险。这篇文章介绍一个反其道而行的方案——
iloveepub，一个所有处理都在浏览器本地完成的 EPUB 工具站，并从技术角度拆解
它为什么可行、边界在哪里。

一、问题：「上传式转换」的三个隐性成本

主流在线转换站（包括很多知名产品）的架构是：文件 → 上传服务器 → 服务端转换 → 回传下载。这个模式对用户有三个隐性成本：

1. 隐私与版权风险：文件真实离开了你的设备。转换方承诺「24 小时删除」无法被用户验证——历史上不止一家工具站的承诺与实际行为不符。
2. 速度受带宽限制：一本 200MB 的漫画 EPUB，上传就要等半天，转换完还要再下载一遍，总耗时里网络占了绝大部分。
3. 服务端算力成本必然转嫁：要么限次收费，要么塞广告，要么两者都有。

而 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 秒验证一下。任何声称「本地处理」的工具都可以用同样的方法检验：

1. 按 F12 打开 DevTools，切到 Network 面板
2. 勾选 Preserve log（保留日志）
3. 上传文件并完成一次完整转换
4. 检查请求列表：处理过程中应该没有任何 POST/PUT 请求携带你的文件数据

如果转换时你看到大流量的上行请求，那「本地处理」就是话术。这套验证方法适用于所有同类工具站，不限于这一个。

五、边界与局限（诚实版）

纯浏览器方案不是没有代价，列清楚比回避更有意义：

• 不做 OCR：扫描版 PDF 只有图像像素没有文字层，浏览器端没有靠谱的 OCR 路径，这类输入会被明确拒绝而不是产出损坏结果。
• 大文件受内存限制：WASM 在内存中处理，上百 MB 的文件在低配手机上可能有压力，站内对超大文件有明确提示。
• 极端复杂排版的保真度：EPUB → PDF 的重排版路线以可读性优先，不承诺像素级还原原书设计。

六、适用人群

• 墨水屏/Kindle/Kobo 用户：文字版 PDF 转 EPUB、KEpub 输出、大书压缩
• 网文/连载读者：批量合并章节文件、拆卷
• 做笔记和知识管理的人：EPUB → Markdown/TXT 提取
• 对文件隐私敏感的任何人：内部资料、未出版稿件、私密书库

免费、无注册、无次数限制，界面支持中英文等多语言。地址：iloveepub，感兴趣的可以自己去验证第三节的方法。

---

如果这篇对你有启发，比起记住这个网站，更值得记住的是它背后的架构判断：能在客户端完成的处理就不要搬到服务端——省掉的不只是服务器账单，还有用户最不该交出去的信任。