Source audit · 2026-09-01

微信读书电脑端书籍导出工具:技术路线与风险审计

不是“哪个按钮能下载”的罗列,而是从源码追到正文:登录态怎样进入工具、章节从哪里取得、怎样还原文本与图片、最终如何组装成 Markdown、HTML、TXT、EPUB 或 PDF。

适用边界:仅讨论用户有权阅读并为个人研究、检索或无障碍使用而处理的内容。本文不提供绕过付费、访问控制或批量规避平台限制的操作指南,也不构成法律意见。

12个仓库纳入源码与定位审计
9条可在电脑端运行的正文导出主线
5种相互独立的内容获取架构
3个按不同目标可优先试验的候选

Executive verdict

先说结论:不存在“通用、稳定、低风险”的一键下载器

现有工具的本质,是在“复用浏览器已获授权的显示结果”与“复刻网页阅读器的私有数据链路”之间取舍。前者更接近屏幕上可见内容,后者更容易保留目录、样式与图片,但对内部接口和登录态耦合更深。

文本分析优先:lbq110 / weread-exporter

通过 Playwright 截获 Canvas 的逐字绘制,再按坐标重建行、段落与双页顺序;图片从当前 DOM 补入。输出 Markdown、分章文件、原始 JSON 和图片,便于后续做语料分析。

2026 活跃Canvas Hook无许可证声明
结构化 EPUB 优先:finlater / weread.koplugin 中的脚本

复用网页 Cookie,读取目录与章节分片,校验并还原正文、CSS、章节图片包,然后直接组装 EPUB。资产保真度最高,代码也最活跃,但它依赖私有接口,且凭证管理要求最高。

2026 高活跃API 分片AGPL-3.0
多格式但先做兼容性试验:drunkdream / weread-exporter

项目最成熟、格式最全,采用浏览器响应注入和 Canvas Hook,再生成 EPUB/PDF/MOBI/TXT;但当前登录失败与“不能下载”的开放 Issue 很多,明文 Cookie 文件也需要谨慎处理。

2,105★82 个开放 IssueCookie 明文

关键判断:如果目标是分析文字,选择“渲染层捕获 → Markdown”更便于审计;如果目标是保留目录、图片和样式,选择“章节接口 → EPUB”更完整。不要因为某个工具能输出 EPUB,就误以为它比只输出 TXT 的工具更稳定——输出转换通常只是最后一步。

Architecture map

所有工具都能拆成同一条流水线

差异集中在第二步“正文获取”。登录、目录、素材与成书只是围绕这一核心的工程选择。

① 建立登录态二维码登录、浏览器持久化 Profile、Cookie 文件、浏览器扩展现成会话,或服务端托管凭证。
② 取得正文截获 Canvas、注入网页运行时、请求章节分片、观察预渲染 DOM、截图,或读取 Android 缓存。
③ 规范化按坐标重排行段、HTML 清洗、字符解码、图片地址改写、目录层级与章节边界恢复。
④ 组装输出Markdown / TXT 适合分析;HTML / EPUB 保留结构;PDF 偏向视觉复刻。
A · Canvas 绘制截获截住 fillText 等绘图调用,以坐标恢复文字。代表:lbq110、drunkdream。
B · 网页运行时注入拦截响应并暴露阅读器内部还原函数,再取已还原 HTML。代表:whale4113。
C · 章节接口分片直接请求目录与正文分片,在本地校验、还原并打包。代表:finlater、Tampermonkey、wereadx、Toolbox。
D · DOM / 截图采集观察 #preRenderContent 或逐页截图,自动翻页。代表:WeReadScan 两个分支。
E · 设备缓存从已 Root Android 的应用私有目录读取缓存并还原。代表:weread_decrypt;不属于纯电脑端路线。

Portfolio comparison

全量候选对比

星标、开放 Issue 和最近推送时间均为 2026-09-01 的仓库快照。它们只反映社区与维护信号,不等于可用性证明。

项目运行方式正文获取核心输出登录态维护信号判断
lbq110/weread-exporterPython + PlaywrightCanvas fillText 坐标捕获;DOM 补图片Markdown、分章、JSON、图片持久化浏览器 Profile304★;2026-07 推送;3 Issue;未声明许可证文本分析首选
drunkdream/weread-exporterPython + pyppeteerCDP 响应注入 + Canvas HookMD、EPUB、PDF、MOBI、TXTcache/cookie.txt2,105★;2026-03 推送;82 Issue;未声明许可证成熟但脆弱
finlater/weread.koplugin 脚本Python CLI;亦服务 KOReader章节接口分片 + 校验/还原 + 图片 tarEPUBCookie jar / Cookie 字符串,可续期658★;2026-08 推送;AGPL-3.0结构保真首选
WeReadExporter-Tampermonkey浏览器用户脚本同源章节接口 + 浏览器内还原Markdown、HTML、TXT;复制/半自动整书复用当前网页版会话30★;2025-12 推送;1 Issue;未声明许可证上手最轻
whale4113/weread-downloaderBun/TypeScript + PuppeteerAST 定位网页还原函数,CDP 注入后调用分章 TXT、合并 TXTPuppeteer 浏览器会话28★;2025-08 推送;2 Issue;MIT技术精巧、强耦合
bunnyburrow-wereadPython CLI + pyppeteer读取 Vue Store 中已加载章节 HTML.rdata.zip → EPUB每次二维码登录,默认无痕82★;2023-01 推送;许可证不明确设计清楚但陈旧
Algebra-FUN/WeReadScanPython + Selenium主分支逐页截图;HTML 分支观察预渲染 DOMPDF 或单文件 HTML二维码登录1,001★;2023-09 推送;11 Issue;未声明许可证只作历史参考
88825/wereadxDeno Deploy Web 服务章节接口分片 + 服务端还原HTML/ZIP(前端打包)服务端存储用户凭证87★;2023-12 推送;MIT不建议交出会话
WeReadToolboxPySide6 GUI + Playwright章节接口分片 + 本地还原PDF、MD、TXT、EPUBPlaywright 浏览器上下文55★;2025-12 推送;alpha;未声明许可证实验性 GUI
weread-exporter-skillClaude Code Skill + Pythondrunkdream 路线的封装/衍生沿用上游多格式沿用上游16★;2026-01 推送;未声明许可证不是独立架构
weread_decryptGo CLI + Root Android 缓存读取应用私有目录中的 .res 缓存HTML 或 TXT不走网页;依赖设备与 VID45★;2023-07 推送;未声明许可证附录路线
Tencent/WeChatReading官方 Agent Skill官方网关;书架、目录、笔记、统计等笔记/元数据,不导出正文官方 API Key198★;2026-07 推送;README 标注 Apache-2.0能力边界基准

Repository audits

逐项目源码审计

以下“做法”来自实际源码;“能否稳定运行”只在有端到端证据时才下结论。本次没有使用任何用户账号或目标书籍,因此不把静态检查冒充下载成功。

1. lbq110/weread-exporter:把 Canvas 重新变回文字

源码export_precise.py 在页面初始化前改写 Canvas 2D 的 fillText,记录每个被绘制字符的内容与 x/y 坐标。导出器按坐标聚合字符为行,再合并为段落;遇到 y 坐标回绕时识别左右双页,并按左页、右页排序。

源码图片不是从 Canvas 中识别,而是扫描可见 DOM 中的阅读器图片,筛出微信读书资源域名,并按页面 y 坐标与文字混排。每章可保存 Markdown、原始捕获 JSON 和图片;最终再合并全书。

项目说明二维码登录落在持久化 Chromium Profile,因此后续可以复用会话;项目明确要求账号本身已有阅读权限,并说明仅 App 可读的书不支持。

优点不需要在本地复制网页的还原算法;输出很适合搜索、分段和语料分析。脆弱点依赖字体绘制与版面坐标;复杂注音、脚注、数学公式、跨页段落和不可见图片可能失真。本次验证Python 静态编译通过;未做真实登录与整书抓取。

2. drunkdream/weread-exporter:浏览器注入 + 多格式成书

源码通过 Chrome DevTools Protocol 拦截阅读器响应,将 hook.js 注入页面;Hook 代理 Canvas 上下文调用,把页面实际绘制的内容转换为 Markdown。控制器按章节和页翻动,将捕获结果汇总。

源码后处理链使用 Markdown、BeautifulSoup、ebooklib 与 WeasyPrint 生成 EPUB/PDF/TXT,MOBI 依赖 KindleGen。也就是说,多格式是“同一份捕获内容的多种封装”,并非五条不同的正文获取方案。

源码Cookie 保存在 cache/cookie.txt,注入流程中还存在输出 Cookie 值的日志路径;调试日志、终端录屏或备份目录都可能泄露登录态。

Issue2025–2026 年的开放 Issue 包含扫码后仍循环登录、无法下载、书籍打不开等;2026-08-31 甚至出现使用 Playwright 重构登录与完整性的提议。这说明“最近仍有人维护”不等于当前网页登录链已经稳定。

优点格式覆盖最广、社区样本最多、命令行功能成熟。脆弱点登录、Canvas Hook、浏览器版本、PDF 原生依赖和 KindleGen 均可能成为故障点。本次验证Python 静态编译通过;未执行会触发账号或网站请求的流程。

3. finlater/weread.koplugin:直接复刻网页阅读器的数据面

源码scripts/fetch_weread_epub.py 接受浏览器 Cookie jar 或 Cookie 字符串,先续期会话并读取阅读器初始状态,再请求章节目录。对每章,它分别拉取正文、样式等分片,检查返回体完整性后还原内容。

源码若目录提供章节素材包地址,脚本读取 tar,筛出图片并改写 XHTML 中的引用,最后写入 EPUB 的 manifest、spine、导航、CSS 与图片。与 Canvas 路线相比,它更接近原始电子书结构。

源码Cookie 可以从文件读入并保存更新值;这利于无头运行,也意味着 Cookie 文件本身就是高敏感凭证。脚本还提供阅读进度上报相关开关,若只是导出,应避免启用会改变账号状态的功能。

优点目录、XHTML、CSS、图片与 EPUB 封装最完整;近期维护活跃且许可证明确。脆弱点强依赖未公开的网页章节端点、请求参数与响应格式;接口变化会直接中断。证据强度仓库文档给出 134 章、282 张图片、约 18.3 MB EPUB 的验证记录;本报告未独立复现。

4. WeReadExporter-Tampermonkey:在已登录网页里完成请求与还原

源码用户脚本运行在 weread.qq.com/web/reader/*,复用当前页面的同源登录态。它拦截 XHR 以取得图书与进度信息,也会请求目录和章节分片,并在浏览器内完成内容还原。

源码HTML 可直接复制;Markdown 由 Turndown 转换,TXT 是进一步去标签的结果。界面支持单章与整书的半自动处理。项目 README 中的 EPUB 截图更像“HTML/EPUB 内容效果”展示,源码主流程和自述明确的稳定输出仍是 Markdown、HTML、TXT。

供应链脚本从第三方 CDN 加载 jQuery 与 Turndown。即使代码本身不开服务器,远程依赖一旦被替换,也能在已登录的微信读书页面上下文运行;更稳妥的部署应固定并本地审阅依赖。

优点无需搬运 Cookie,安装后在浏览器页面中直接使用;最适合少量、交互式导出。脆弱点依赖网页内部接口和远程脚本;2026 年已有“点击 Markdown 无响应”Issue。本次验证JavaScript 语法检查通过;未安装到真实登录浏览器。

5. whale4113/weread-downloader:从网页脚本中动态“借出”还原函数

源码Puppeteer 通过 CDP 拦截阅读器 HTML 与工具脚本响应。项目用 Acorn 解析 JavaScript AST,在压缩后的网页脚本中按特征定位内部还原函数,然后把函数挂到 window;同时复制页面初始状态供后续章节读取。

源码章节加载完成后,脚本从状态树取得当前分段的编码内容,在页面上下文调用刚暴露的函数,还原 HTML,再用 Cheerio 提取纯文本保存为 TXT。交互式章节选择和缓存降低了重复抓取量。

优点不在仓库里硬编码完整还原逻辑,能随当前网页脚本动态取函数。脆弱点AST 特征依赖被压缩脚本中的结构与字符串;网页实现一改,定位可能无声失败。当前信号仅 28★,2026 年有“not working”Issue;应视为研究样本,不作为首选生产工具。

6. bunnyburrow-weread:先保存“原始包”,再离线生成 EPUB

源码二维码登录后从书架进入目标书,直接读取页面 Vue Store 的 reader 状态。它通过调用页面组件的换章方法,让每章 HTML 进入 Store,再把章节 HTML、目录 JSON、图书元数据、CSS 和图片写入 .rdata.zip。

源码项目把下载、完整性检查、EPUB 生成拆成三个命令:先保留可检查的中间包,再离线将 HTML 转为 XHTML、生成 OPF/NCX/封面与资源清单。这是本批项目中数据工程边界最清楚的设计之一。

优点原始数据与成书解耦,失败可重做,便于审计缺章。脆弱点直接依赖旧版 Vue 组件私有字段和 CSS 选择器;自 2023 年后未推送,现网页大概率已变。结论值得借鉴中间格式设计,不建议直接作为 2026 年主工具。

7. WeReadScan:视觉复刻和 DOM 复刻是两条不同分支

源码主分支是“翻页扫描仪”:Selenium 控制阅读器,逐页对正文 Canvas 元素截图,再将图像二值化/压缩并合成 PDF。它不需要理解文字编码,但 PDF 中的文本可搜索性和重排能力取决于后续 OCR。

源码html-variant 分支则注入 MutationObserver,观察 #preRenderContent,把预渲染章节复制到自建 HTML 根节点,最后导出单文件 HTML。这条路线效率更高,却依赖一个原作者仓库现已不可访问的脚本思路和旧 DOM 结构。

Issue开放 Issue 包含截图不全、登录后崩溃和“现在还能爬吗”;结合三年未维护,应视为历史方案。

适用只求视觉留档、允许 OCR、对排版像素级接近更看重时,截图路线仍有概念价值。不适用需要干净正文、精确段落、可访问性、低体积或稳定自动化。

8. wereadx:能在电脑浏览器使用,但本质是托管服务

源码服务端持有微信读书凭证,调用书籍目录、章节分片接口,执行内容校验与还原;前端内置 JSZip 与 FileSaver 完成下载。Deno KV 同时保存 token、VID、skey、rt 等凭证字段。

项目说明公开服务限制每月下载次数且明确不支持付费内容;自部署依赖 Deno Deploy、Deno KV 和数据库。它还包含自动更新阅读时长等会修改账号状态的功能,已经超出单纯导出器范围。

优点提供完整 Web UI,跨桌面系统使用。主要风险把高敏感会话交给服务端;若不是自己审计并部署,信任边界远大于本地脚本。结论不建议为正文导出使用第三方公共实例。

9. WeReadToolbox:把接口分片路线包装成桌面 GUI

源码Playwright 浏览器上下文负责登录和请求;程序先取目录,再按图书格式请求多组章节分片,本地恢复 HTML/TXT 和 CSS。PySide6 界面管理书架、下载队列和导出,后处理器可以生成 EPUB、Markdown、TXT、PDF。

代码质量仓库包含若干临时命名文件、硬编码测试路径和大量仍在演进的界面代码;README 只有 alpha 下载链接与两句技术说明,没有依赖锁定、构建复现或许可证。

优点唯一把现代接口路线做成完整桌面图形界面的候选。脆弱点发布物来自网盘,源码与二进制对应关系难验证;macOS 支持仍有人请求。结论适合隔离环境试验,不应直接导入主账号 Cookie 或长期 Profile。

10–12. 不应和独立正文导出器混为一谈的三个项目

  • 衍生weread-exporter-skill 主要把 drunkdream 路线包装成 Claude Code Skill 和安装器;安装脚本会执行 pip install -e . 与用户级插件安装。它改善调用体验,不产生新的正文获取架构。
  • 附录weread_decrypt 要求 Root Android,并读取应用私有目录下的缓存文件,再导出网文 TXT 或出版书 HTML。它回答的是“设备缓存怎样还原”,不是“电脑如何通过网页导出”。
  • 官方Tencent/WeChatReading 提供搜索、书架、目录、阅读进度、笔记、书评与统计,但没有章节正文导出能力。它是安全、受支持的元数据/个人笔记路线,也是判断第三方工具越界程度的重要基准。

Security & compliance

最值得担心的不是文件格式,而是登录态和规则边界

凭证暴露面:从低到高

  1. 浏览器用户脚本:不导出 Cookie,但脚本与远程依赖能在登录页面上下文运行。
  2. 专用持久化 Profile:会话集中在本地目录,可隔离,但复制该目录可能复制登录态。
  3. Cookie jar / 明文 Cookie:便于自动化,也最容易被日志、云同步、Git 或备份泄露。
  4. 第三方托管服务:服务端获得可代表用户访问的凭证,是最大信任扩张。

建议的最小风险实验边界

  • 使用独立浏览器 Profile,不复用日常浏览器配置。
  • 只测试自己已购买、会员期内可读或公版/自上传内容。
  • 先导出单章并比对段落、脚注、图片和章节顺序,再扩大范围。
  • Cookie/Profile 不放入 Git、网盘、聊天记录或截图;测试结束后主动退出会话。
  • 禁止把导出结果再分发,尤其不要形成公开下载服务。

协议风险:微信读书用户协议明确限制反向工程,以及获取、复制、挂接运行客户端与服务器交互数据,并点名未经授权的插件、外挂或第三方工具。本文涉及的运行时注入、私有接口分片和设备缓存路线均可能触及这些条款;“账号有权阅读”并不自动等于“可以用任意技术批量导出”。采取行动前,应确认适用法律、平台条款、版权许可和你的具体用途。

账号稳定性:高频整书请求、伪装浏览器或自动上报阅读时长,不只是技术问题,也可能触发风控。报告不建议使用 stealth、绕过验证码、模拟阅读时长或公共托管服务。

Decision guide

按你的真实目标选择,而不是按“支持格式最多”选择

1

要做全文分析 / RAG / 搜索

先试 lbq110/weread-exporter。Markdown、分章与原始 JSON 便于检查和二次处理;先用一章校验段落、标点、脚注、图片位置。若 Canvas 版式导致失真,再试 API/HTML 路线。

2

要保留目录、图片、样式

先评估 finlater 的独立 Python 脚本。它生成真正的 EPUB 结构,证据和维护状态最好。代价是你必须妥善管理 Cookie,并接受私有接口变化与条款风险。

3

只想少量复制一章

优先浏览器内的 Tampermonkey 路线。它避免手工导出 Cookie,操作面小;但应把远程依赖改为固定、可审阅版本,并不要把“整本”当作默认动作。

不建议作为第一选择

  • drunkdream:先用单章验证登录与完整性;开放 Issue 显示当前兼容性风险较高。
  • WeReadScan:仅在必须保留视觉版式且接受 OCR 时考虑。
  • wereadx 公共服务:不要把主账号会话交给第三方托管端。
  • WeReadToolbox 网盘二进制:缺乏可复现构建与许可证,先在隔离环境审计。

若目标其实是“分析掌阅里的微信读书”

先判断掌阅安装的是 Android 微信读书 App 还是网页版封装。没有 Root 时,macOS Finder 只会看到 MTP 暴露的公共存储,通常看不到 App 私有目录。此时更现实的路径是在电脑端登录同一微信读书账号,用网页端工具处理账号已授权可见的内容;设备缓存路线需要 Root,风险和复杂度都高得多。

Method & limitations

这份报告验证了什么,没有验证什么

已完成

克隆并阅读 12 个候选仓库;追踪认证、目录、正文、图片和成书代码;记录 2026-09-01 的仓库元数据与开放 Issue;对可直接检查的 Python/JavaScript 文件做静态语法验证。

未完成

没有使用用户账号、Cookie 或目标书;没有发起章节下载;没有绕过付费或验证风控;没有证明每个项目在今天能完整导出任意一本书。

判定规则

“源码”表示直接从实现得到;“项目说明”表示作者自述;“Issue”表示社区故障信号;推荐同时考虑正文保真、维护活跃、凭证暴露、许可证与平台耦合。

可复现性提示:第三方仓库会变化。复核时应固定到本报告日期附近的 commit,而不是只看 README;星标与 Issue 数也会继续变化。任何真实试验都应从单章、小流量和可撤销会话开始。

Primary sources

来源与证据入口

技术判断优先使用项目源码、项目 Issue 与腾讯官方材料。未使用下载站转载、营销软文或二手教程作为核心证据。

  1. lbq110/weread-exporter:Playwright + Canvas Hook 源码
  2. drunkdream/weread-exporter:Hook 与多格式导出源码
  3. drunkdream Issue #128:循环登录
  4. drunkdream Issue #129:Playwright 重构提议
  5. finlater:电脑可运行的 EPUB 抓取脚本
  6. finlater:API 与验证记录
  7. WeReadExporter-Tampermonkey 源码
  8. whale4113/weread-downloader 源码
  9. bunnyburrow-weread 源码
  10. WeReadScan 主分支与 HTML 分支
  11. WeReadScan Issue #42:现状询问
  12. wereadx 服务端源码与部署说明
  13. WeReadToolbox alpha 源码
  14. weread-exporter-skill 衍生封装
  15. weread_decrypt Android 缓存路线
  16. 腾讯官方 WeChatReading Skill
  17. 官方书籍信息/目录能力边界
  18. 微信读书用户协议