Skip to content

Blog

WebNR:给 Legado 用户的一个独立网页端替代选择

直接答案: 如果你喜欢 Legado 的“自己决定内容来源、自己管理书架、阅读器只负责把内容整理成可读体验”这一思路,但希望直接在电脑、平板或手机浏览器里打开,不依赖 Android App 常驻,WebNR 可以作为一个独立的网页端替代选择。它不是 Legado 官方网页端,也不与 Legado 项目存在隶属关系;WebNR 采用自己的浏览器架构,并逐步用独立测试样本兼容常见的 Legado 数据与规则行为。

本文核验日期为 2026 年 8 月 9 日。当前 WebNR 已经可以在浏览器中导入本地 TXT、导入允许跨域访问的文本 URL、安装为 PWA、保存本地书架与阅读进度、使用翻页或滚动阅读、书签、排版和文字转语音,并连接 WebNR 自有书源目录。任意 Legado 书源 JSON 目前还不能直接作为完整的 drop-in runtime 执行,因此“网页端替代”描述的是一组正在扩大的真实使用场景,而不是对全部 Legado 功能的一比一复刻。

直接打开 WebNR 阅读器

为什么会需要一个真正独立的网页端

Legado 的核心使用方式长期围绕 Android 客户端展开。官方入门文档仍然从 Android 安装、本地文件访问和书源导入开始;书源可以从本地文件或网络地址导入,规则负责把第三方页面中的搜索、书籍信息、目录和正文转换成阅读器可以展示的内容。Legado 入门文档书源导入文档 都体现了这套模型。

Legado 也存在配套的 Web 端书架项目,但它的公开说明要求手机和电脑位于同一局域网,并由手机端开启 Web 服务;网页本身更像 Android 阅读器的远程界面。gedoor/legado_web_bookshelf 的 README 明确写出了这一依赖关系。

WebNR 选择的是另一条路线:浏览器本身就是阅读器运行时。 读者打开 app.webnovel.win 后,书籍正文、书架与阅读进度直接保存在当前浏览器配置中。日常阅读不要求另一台 Android 设备提供后台服务,也没有“手机端开着,电脑端才能读”的拓扑。

这也是“网页端替代”这句话真正想表达的东西:把 Legado 用户熟悉的“本地书架 + 可配置来源 + 独立阅读器”体验迁移到一个浏览器原生环境,而不是给 Android App 做一个遥控面板。

今天打开 WebNR,可以完成哪些 Legado 式任务

1. 本地文件直接进入书架

WebNR 当前正式支持 TXT。本地文件在浏览器内读取、解码并写入 IndexedDB;UTF-8 之外,现有导入路径也会处理 GB18030、Big5 等常见旧编码。文件导入完成后直接进入阅读器,不需要上传到 WebNR 内容服务器。

对于已经把小说整理成 TXT 的 Legado 用户,这条路径最简单:选择文件,开始阅读,之后重新打开浏览器仍能在本地书架看到它。

2. 从 URL 导入文本

如果一个 HTTP/HTTPS 地址直接提供文本,并且服务器允许浏览器跨域访问,WebNR 可以从 URL 导入。浏览器 CORS 是这里最重要的边界:Android 原生应用可以主动请求很多网站,网页则必须遵守服务器返回的跨域权限。

因此同一个文本地址在 Android 客户端里可以访问,在网页里仍可能被浏览器拒绝。WebNR 把这种情况视为明确的运行环境差异,而不是通过公共代理替用户绕开目标网站的访问策略。

3. 连接 WebNR 书源目录

WebNR 已经有自己的 source/repository 目录格式,并已接入项目自建示例、青空文库 starter、Standard Ebooks starter 等经过项目审核的来源。它们可以用于发现作品、查看目录信息并进入后续导入流程。

这一层与 Legado “书源”概念的目的相近:阅读器与内容来源分离。区别在于 WebNR 当前运行的是自己的目录格式,而 Legado 使用更丰富的规则体系描述搜索、详情、目录和正文抓取。

4. PWA、书架和阅读进度

WebNR 可以安装为 PWA。应用外壳支持离线再次打开,书籍正文和进度保存在浏览器本地。阅读界面目前包含滚动和分页模式、字号等排版设置、深色模式、书签和文字转语音。

这部分是 WebNR 最适合独立网页运行的区域:浏览器、PWA、IndexedDB 和 Service Worker 共同承担传统桌面/移动阅读器的一部分职责。

它和 Legado 现在最大的差距在哪里

最大的差距不是“网页有没有书架”,而是规则运行时

Legado 的价值很大一部分来自高度灵活的自定义书源:规则可以描述搜索、书籍详情、目录、正文、分页、替换净化、headers、charset、变量、Cookie,以及更复杂的脚本或 WebView 行为。官方书源文档把书源理解为一套从第三方网络内容中提取并整理阅读内容的规则。Legado 书源导入说明 可以作为最基础的入口。

WebNR 今天还没有把任意 Legado JSON 直接交给浏览器执行。这里必须分阶段做,因为网页环境同时存在三类约束:

  • 浏览器 CORS 与跨域安全模型;
  • Cookie、登录态、动态脚本和 WebView 能力差异;
  • 任意第三方规则执行带来的权限与安全风险。

因此 WebNR 的兼容路线采用 capability level 和 versioned fixtures,而不是一句“支持 Legado”覆盖所有情况。

当前规划顺序是:

  1. JSON 导入与检查。 识别字段、保留未知字段,告诉读者哪些可以解释、哪些会忽略、哪些需要更高能力。
  2. 常见声明式规则。 覆盖 search、book info、TOC、content、pagination,以及 CSS、XPath、JSONPath、正则、headers、charset 和 replacement。
  3. 受控状态。 支持明确域名与权限范围内的变量、Cookie 和有限状态。
  4. 受限脚本。 必要 JavaScript 放入有限时间、内存和能力的隔离环境。
  5. Bridge/WebView。 把普通浏览器无法安全完成的动态页面、复杂登录和 WebView 行为交给可选本地 Bridge,而不是建设一个中心化公共代理。

这个顺序的目标是让现有 Legado 定义尽量少改甚至不改就能进入 WebNR,同时保持浏览器端的权限边界可解释、可测试。

为什么不直接复制 Legado 的 Web 端

现有 Legado Web 书架与 WebNR 解决的是不同问题。前者公开说明自己是“阅读3.0”的配套 Web 端,需要连接手机端服务;WebNR 则希望网站本身可以独立运行。

独立运行意味着数据模型、存储、跨域请求、脚本能力、PWA、部署、安全策略和测试方式都需要重新设计。WebNR 因此采用 clean-room 兼容:依据公开文档、公开格式以及项目自建 fixtures 实现行为,不复制 Legado 客户端代码来建立一个换壳版本。

这也让两个项目可以保持清晰关系:Legado 是 Legado,WebNR 是 WebNR;两者在“自定义来源 + 阅读器”的用户需求上有交集,WebNR 争取让迁移成本越来越低。

2026 年还多了一层现实背景

截至本文核验日期,gedoor/legado 的 GitHub 主仓库公开页面只保留了一份公告,项目内容已经移除,公告同时强调停止侵权相关行为。当前官方 GitHub 仓库 可以直接看到这一状态。

这让“兼容 Legado”的边界更需要写清楚。WebNR 不恢复已经删除的代码或内容,也不把来源规则的公开可下载等同于目标站点内容获得授权。WebNR 的官方来源目录优先接入公版、自有、明确授权或具有清晰开放访问条件的内容;第三方 Legado 定义可以用于兼容研究和隔离测试,但进入推荐目录需要另外完成目标站条款、robots、访问要求和健康审计。

因此“Legado 网页端替代”描述的是用户体验方向和兼容目标,不是对原项目内容的镜像或延续。

哪些人现在就适合用 WebNR

WebNR 当前最适合下面几类 Legado 用户:

  • 主要阅读自己已有的 TXT,希望电脑、平板和手机浏览器都能直接打开;
  • 希望安装一个 PWA,而不是额外安装桌面程序;
  • 想把浏览器作为独立阅读终端,不希望电脑阅读依赖手机端 Web 服务;
  • 使用公版、作者授权或自己维护的文本目录;
  • 愿意使用 WebNR 当前已经审核通过的来源,同时等待更完整的 Legado JSON 兼容;
  • 希望书籍正文和阅读进度默认留在浏览器本地。

如果你的日常阅读高度依赖复杂 Legado 规则、登录 Cookie、动态 WebView 或任意 JavaScript,Android Legado 目前仍覆盖更多场景。WebNR 的目标不是用文案掩盖这段差距,而是逐项把可测试的能力迁移到网页环境。

迁移时可以怎么开始

最省事的顺序是:

  1. 打开 WebNR 阅读器,先导入一份本地 TXT,确认阅读器和浏览器存储正常。
  2. 查看 Legado 书源查找与验源指南,理解 WebNR 当前的书源目录、安全和授权边界。
  3. 试用现有 WebNR sources,确认“发现—导入—阅读”的完整路径。
  4. 对你依赖的 Legado JSON 记录具体字段和失败阶段,作为 compatibility fixture 或 issue 提交,而不是只写“这个书源不兼容”。

后续兼容报告会按版本列出支持字段、规则能力、Bridge 要求和 fixture 测试结果。这样一个书源能否迁移,会逐渐变成可以自动验证的问题。

浏览器体验必须由真实浏览器测试兜底

WebNR 把“网页端替代”写进公开介绍后,用户体验要求也随之提高。仅仅 next build 成功无法证明读者真的能够打开应用、点进导入、选择 TXT、看到正文、返回书架并在刷新后继续看到自己的书。

从这次更新开始,项目把真实 Chromium E2E 加入 Quality CI。测试从生产静态构建启动本地 HTTP server,然后模拟桌面和移动浏览器完成:

  • 首次打开与 Legado 辅助定位可见;
  • PWA manifest 与 Service Worker 注册;
  • 本地 TXT 文件选择、导入和正文渲染;
  • 返回书架、刷新页面后 IndexedDB 书架仍然存在;
  • 用键盘 Enter 再次打开书籍;
  • CORS 允许时的 URL 文本导入;
  • 非 TXT 文件与非法 URL 的可恢复错误提示。

这些测试成为后续每个 PR 的持续门禁。换句话说,“作为网页端替代选择”不只是一句介绍,它会对应一条持续运行的浏览器用户旅程。

WebNR 希望最终做到什么

长期目标可以概括为一句话:让 Legado 用户熟悉的自定义来源阅读方式,在浏览器里拥有一个真正独立、可安装、可测试的实现。

WebNR 会继续保持自己的产品边界:网页优先、本地数据、明确权限、来源与内容授权分离、兼容结论由 fixtures 证明。随着 Legado adapter、规则运行时、Bridge 和更多来源接入,网页端能覆盖的阅读场景会逐步扩大。

现阶段最准确的描述因此是:WebNR 已经是一个可以独立使用的浏览器阅读器,也可以作为 Legado 用户的网页端替代选择;它正在从 TXT、目录和基础阅读体验出发,逐步扩展到更完整的 Legado-compatible 工作流。

参考资料

2026 年哪里能合法免费看小说?公版、作者授权与 TXT/电子书资源目录

直接答案: 想找长期稳定、来源清楚的免费小说,优先顺序可以很简单:先看明确公版或由作者授权的数字图书馆,再看开放电子书项目和机构馆藏,最后才把搜索引擎、镜像站和社区分享当作发现线索。对 WebNR 用户而言,当前最容易直接阅读的是明确允许分发的 TXT;EPUB、扫描 PDF、特殊编码文本和只提供作品页的馆藏,应该先作为发现链接,等阅读器具备对应解析器和逐本权利判断后再开放直接导入。

本文于 2026 年 8 月 8 日重新核验来源项目的官方页面、版权说明、访问方式和 WebNR 当前能力。今天同时上线一个新的 Standard Ebooks Starter 发现源,读者可以把四部经典小说的官方作品页加入 WebNR 来源列表:

添加 Standard Ebooks Starter

这个源只提供官方作品页链接,不复制 EPUB,也不把电子书下载地址伪装成 TXT。此前已经上线的 Legado 书源查找与验源指南 解释了为什么“规则文件公开”与“内容可以合法获取”必须分开判断;本文把重点放在读者真正可以使用的免费阅读路线。

先看一张表:不同“免费来源”其实不是同一种东西

来源类型 读者能得到什么 WebNR 当前适合的方式 最容易忽略的边界
作者授权或项目原创 TXT 直接文本文件 可以直接导入或建立静态目录 授权范围是否允许再分发
公版电子书项目 在线阅读、EPUB、作品页、目录 Feed 先做作品发现;TXT 可直接读,EPUB 等解析器完成后再接入 公版状态随国家/地区而变化
国家图书馆与数字馆藏 作品页、扫描件、全文或元数据 作品发现和跳转 “可查看”不等于“可批量下载或再分发”
Wikisource 等协作文本库 网页正文、导出文件、版本历史 语言/作品级 adapter 页面许可、原作版权和译文版权可能不同
搜索与聚合 API 元数据、可读状态、落地页 发现层,不当作内容许可证 API 返回“可见”不代表内容可自由复制

这里最关键的判断是:免费访问、公共领域、开放许可、机构允许下载、允许机器访问、允许第三方再分发,是六个不同问题。 一个页面在浏览器里免费打开,只说明此刻可以访问;WebNR 若要把它变成长期可维护的书源,还需要知道来源是谁、作品权利状态、请求方式、格式、编码和失败边界。

第一组:最适合普通读者长期收藏的免费项目

Standard Ebooks:适合想要排版精良英文经典的人

Standard Ebooks 把公版文学制作成高质量电子书,并提供在线阅读、兼容 EPUB、Kindle/Kobo 格式以及作品源码。项目说明由 Standard Ebooks 制作的内容采用 CC0 1.0;每本书的页面又单独提示作品在美国是否被认为已经没有版权限制,并提醒美国以外读者核对所在地法律。

今天核验的四个官方页面是:

这些页面都能直接在线阅读,也提供电子书下载。WebNR 目前仍以 TXT 为正式支持格式,因此今天的集成选择“链接到官方作品页”,而不是做一个看似方便、实际没有经过 EPUB 安全测试的下载按钮。这样读者马上获得稳定入口,同时阅读器不会虚假宣称已经支持一种格式。

Standard Ebooks 还提供 OPDS/Atom/RSS 形式的电子书 Feed,不过完整 Feed 存在不同访问路径。今天的 Starter 不依赖这些 Feed;后续只有在明确符合公开或开源项目访问条件并建立固定测试后,才会升级为自动目录 adapter。

Project Gutenberg:目录巨大,但机器访问要走机器路线

Project Gutenberg 是最常见的英文免费电子书入口之一。它的目录以美国版权判断为基础,既有美国公共领域作品,也可能保留历史上经权利人授权发布的条目。因此“Gutenberg 上有”并不适合被简化成“全世界都属于公版”。

对普通读者,直接打开作品落地页最清楚。对程序和书源,项目明确区分主网站的人类访问与机器人/批量访问,并提供机器可读目录、镜像和离线元数据路线。WebNR 后续的 Gutenberg adapter 应当使用这些官方机器入口、缓存目录结果、保持低频,并尽量链接作品页,而不是让每个客户端反复抓取主站网页或把第三方镜像当作权威来源。

Gutenberg 因此很适合作为“大目录发现层”:它能回答“这本经典有没有合法免费版本”,但具体下载、再分发以及所在法域是否已进入公共领域,仍需要看单本作品与当地法律。

青空文库:日文经典入口已经可以在 WebNR 里发现

青空文库 是日本文学的重要免费数字项目。WebNR 已经上线 Aozora Bunko Starter,当前包含《吾輩は猫である》《羅生門》《走れメロス》《よだかの星》四个经过核验的官方图书卡链接。

青空文库的图书卡/书架数据有明确的再利用条件,但具体作品仍需考虑原作、译文等权利状态;文件格式还常见 ZIP、Shift_JIS、青空文库注记和 XHTML。WebNR 因此先把它做成作品发现源。等 ZIP、编码和 ruby 注记解析有版本化测试后,才适合讨论直接阅读。

这个策略对其他区域图书馆同样适用:先把稳定、官方、可解释的作品入口交给读者,再逐步增加格式能力。

Project Madurai:泰米尔语电子文本的区域性宝库

Project Madurai 是一个长期运行的志愿数字化项目,目标是制作并免费发布泰米尔文学电子文本。官方说明称收藏中的作品来自公共领域,或已经得到相应作者/权利方许可;其档案同时保留早期 TSCII 编码和较新的 Unicode HTML/PDF 版本。

它非常适合成为 WebNR 的区域来源候选,不过接入方式需要比“抓一个 TXT 链接”更细:不同年代文件的字符编码、HTML 结构、PDF 与纯文本能力不一致,早期档案还带有个人使用措辞。今天的决定是保留为高价值 adapter 候选,优先从明确 Unicode、作品状态和下载条件的条目建立 fixture,而不是一口气索引整个档案。

Project Ben-Yehuda:公版与明确授权并存的希伯来语数字图书馆

Project Ben-Yehuda 把希伯来文学制作成免费、可搜索的数字版本。项目自己的介绍明确说明,站内作品主要来自版权已经到期的内容,或取得了出版许可;作品列表还把“公共领域”“经授权发布”等权利状态直接作为筛选条件,并提供文本/电子书导出能力。

这类站点对 WebNR 很有价值,因为“作品为什么能公开”本身就是目录数据的一部分。今天把它加入区域来源队列,下一步应使用官方作品状态与导出接口做小规模 fixture,确保每个条目都保留原始作品页和权利标签。

第二组:非常有用,但更适合作为发现层

Wikisource:适合从网页和导出开始,不适合把整个站视为一种许可证

Wikisource 的不同语言项目拥有大量可阅读文本,并有 EPUB/PDF 等导出能力。它的优势是版本历史、校对和页面级来源清楚;复杂之处是原作、译文、编辑贡献以及不同语言项目的具体信息需要逐项处理。

WebNR 已把 Wikisource 留在 adapter 队列。合理设计是保存语言、作品页、导出方式和许可/版权模板,而不是只根据“Wikimedia”这个品牌给整站贴一个统一权利标签。

Project Runeberg:北欧文学很强,法域判断必须跟着作者和译者走

Project Runeberg 长期数字化北欧文学,并明确说明它按照版权期限谨慎发布作品。对于北欧经典发现,它提供了独特价值;对于全球读者,作者、译者、版本和所在地版权期限仍可能产生差异。

因此它适合做区域发现与逐本链接,不适合生成“整个 Runeberg 都可以任意再分发”的结论。

HathiTrust:Full View 很有价值,下载权限仍要看条目和数字化来源

HathiTrust Digital Library 汇集大量图书馆数字化内容。没有登录的用户也能阅读许多 Full View 条目;但整本下载能力受作品状态、登录资格以及数字化来源影响,Google 扫描的条目尤其可能有下载限制。

对 WebNR 来说,HathiTrust 很适合作为“是否存在机构完整视图”的发现信号,暂时不适合作为统一直链下载源。一个未来 adapter 应明确区分 Full View、Search-only、下载限制和作品落地页。

第三组:搜索能力很强,但元数据本身不是内容授权

今天还新增核验了几类发现候选:

  • Digital Public Library of America (DPLA):聚合元数据采用非常宽松的开放政策,很适合发现美国机构收藏;实际图片、扫描件或文本仍由各提供机构的 rights statement 决定。
  • Library of Congress JSON API:不需要 API key 就能查询大量公开元数据,适合低频目录发现;条目格式与权利状态具有异质性,需要保留作品页和逐项 rights 信息。
  • Google Books API / Full View:能提供书目、预览/可读状态和购买/落地信息;Full View 与下载能力会随作品权利和用户所在地变化,所以应把 accessInfo 当成“当前可读性信号”,而不是全局公版证明。
  • Internet Archive Texts:拥有庞大文本与元数据集合,但不同项目、借阅模型和单本作品的权利状态差异很大。WebNR 可以研究元数据/明确开放集合,通用“Internet Archive 全站下载源”则缺少足够窄的权利边界。

这些来源证明了一件很实用的事:一个好的阅读器目录不必把所有书都自己托管。发现层负责告诉读者哪里有可靠版本;导入层只处理已经满足格式、访问和权利条件的内容。

如果你只想“找一本文本马上读”,怎么选

可以按下面的顺序降低踩坑概率:

  1. 先搜索作者或项目官方页面。 作者自己发布的 TXT、明确授权下载页、项目原创内容最容易判断。
  2. 再找公版项目的作品页。 Standard Ebooks、Project Gutenberg、青空文库、Project Madurai、Project Ben-Yehuda、Project Runeberg 都比无来源 TXT 打包站更容易追溯。
  3. 需要更多版本时再去机构馆藏。 Wikisource、HathiTrust、DPLA、Library of Congress、Google Books 可以帮助确定版本、扫描件和可读状态。
  4. 看到“TXT 全集”“万能书源”先检查来源。 文件名、网盘地址和“免费”标签本身不能回答作者、版本、授权和法域问题。
  5. 给 WebNR 导入时看格式。 当前可靠路径是 TXT 与已验证的文本 URL;EPUB、ZIP、特殊编码和复杂网页规则应该等对应能力通过测试。

一个来源如果只有文件、没有作者和 metadata,并不必然不能用。WebNR 的规则是:可以从文件名生成展示标题,未知作者保持 Unknown;但绝不通过猜测补作者、许可、发布日期或热度。比起漂亮但虚构的目录,一个诚实的“未知”更容易在以后被纠正。

今天的来源审计与接入结果

本轮重新核验了现有 WebNR Originals 和 Aozora Bunko Starter,并扩展了免费阅读候选池。新增发现方向包括 HathiTrust、DPLA、Google Books Full View、Internet Archive Texts、Project Madurai 和 Project Ben-Yehuda。

深入审计后形成三个直接结论:

  • Standard Ebooks:通过,今天接入。 使用官方作品页和项目自己的 CC0/版权说明,只做 link-based discovery,不使用受条件约束的完整 Feed,也不复制 EPUB。
  • Project Madurai:通过读者价值审计,等待编码/权利 fixture。 免费电子文本价值高,先从 Unicode 和权利说明明确的条目做 adapter。
  • Project Ben-Yehuda:通过读者价值审计,等待权利状态/导出 fixture。 站点直接区分公版和授权发布,适合做保留权利标签的区域目录。

新的 Standard Ebooks Starter 因此成为 WebNR 第三个正式来源。它的作用不是取代 Standard Ebooks,而是给 WebNR 用户一个可验证的作品发现入口;任何阅读和下载仍回到官方作品页。

为什么今天没有直接接一个“大型 TXT 合集”

TXT 合集非常适合 WebNR,但“没有 metadata”与“没有来源依据”是两回事。前者可以解决:文件名就能先成为标题,未知字段保持未知。后者不能靠技术补齐:如果不知道文本来自哪里、是否公版或获授权,就不能因为文件格式方便而把它包装成官方推荐源。

所以接下来的 TXT 工作会优先寻找三类集合:作者明确授权发布、项目自身原创/开放许可、公共领域项目明确允许分发的文本包。Project Madurai、Project Ben-Yehuda 和部分区域数字项目都可能提供这样的材料,但要先逐项把许可措辞、编码和文件入口做成可重复测试。

下一步

今天之后,免费阅读目录会持续更新来源健康和接入能力,而不是停在一篇“资源推荐”。接下来最值得做的是:

  • 为 Project Gutenberg 建立目录缓存、作品落地页优先的低频 adapter;
  • 为 Wikisource 固定语言、导出与归属 fixture;
  • 为 Project Madurai 测试 Unicode/TSCII 编码边界;
  • 为 Project Ben-Yehuda 保留公版/授权状态并测试文本导出;
  • 等 WebNR 的 EPUB 安全解析器完成后,把 Standard Ebooks 从发现源升级为真正可读的格式适配器。

免费小说资源的长期价值来自三件事同时成立:读者找得到,来源讲得清,阅读器真的能稳定处理。 WebNR 会把这三件事分别验证,再把通过的部分逐步连起来。

2026 年 Legado 书源在哪里找?一份面向读者的查找与验源指南

直接答案: 2026 年寻找 Legado 书源时,最可靠的顺序是先找作者授权、公共领域、开放目录和自己维护的来源,再把社区分享的 JSON 当作待审计的规则文件。一个 GitHub 仓库公开可见,只能证明规则文件能够下载;它不能自动证明目标小说站允许抓取、内容可以再分发,或这条规则今天仍然可用。

本文于 2026 年 8 月 6 日核验公开页面、项目公告和目录政策。WebNR 今天同时发布了一个完全由项目维护、以 CC0 1.0 提供的示例书源,读者可以先用它确认“添加书源—浏览目录—导入 TXT—开始阅读”这一条链路是否正常:

把 WebNR Originals 添加到阅读器

这个示例源只包含 WebNR 原创文本,不代理第三方网站,也不依赖登录、验证码、付费墙或跨域绕过。它适合排除阅读器本身的问题:若示例源可以导入,而某个社区书源失败,问题通常位于目标网站、规则、权限、编码或网络边界。

先分清三件不同的东西

读者口中的“书源”常常混合了三个对象:

  1. 阅读器或规则引擎。 Legado 曾提供可以执行自定义来源规则的 Android 阅读器。
  2. 来源定义。 JSON、JavaScript 或其他规则文件,描述搜索、详情、目录和正文怎样提取。
  3. 内容与目标网站。 小说站、作者页面、公共领域图书馆、RSS、OPDS 或下载目录。

来源定义的开源许可只覆盖规则文件本身。目标网站的条款、robots、账号要求、作品版权和分发许可仍然需要单独判断。这个区分能解释一个常见现象:同一份规则仓库可能采用 GPL,但里面每条规则指向的网站具有完全不同的访问和版权条件。

2026 年最重要的变化:官方仓库已不再是书源入口

gedoor/legado 的 GitHub 首页目前只保留一份公告。公告写明项目内容已经删除,并明确规劝停止侵权相关行为。这个页面因此可以用于理解当前项目状态,却已经不能继续充当稳定的软件下载、规则文档或官方书源目录。

对读者最实际的影响有三点:

  • 旧教程中的官方仓库、Release 和示例路径可能已经失效;
  • “来自 Legado 社区”不等于“经过官方审核”;
  • 搜索结果里出现的镜像、旧发布页和第三方规则集合需要重新核对日期、维护者与法律边界。

WebNR 不会复制已经删除的项目内容,也不会把第三方站点抓取规则直接包装成“官方书源”。我们的兼容工作采用 clean-room fixtures:只根据公开格式和自建测试页面验证字段行为,并把真实第三方定义放入隔离的兼容语料库审查。

五类常见查找路径,风险差异很大

1. 作者、公版机构和开放目录

这是优先级最高的一类。作者自己发布的 TXT、RSS 或下载页,明确公共领域的馆藏,以及带有公开使用条件的 OPDS 目录,都能提供清楚的来源依据。

Project Gutenberg 提供机器可读目录和 OPDS。它目前的新入库政策聚焦美国公版作品,但目录中仍可能保留历史授权条目;其版权判断以美国法为准,其他法域的读者还要核对所在地法律和单本电子书内的许可。其网站政策要求应用使用可联系的 User-Agent、保持接近人工浏览的请求频率,并避免大规模直接链接到电子书文件。适合的做法是使用官方目录、链接到作品落地页,或下载公开目录后建立自己的低频索引;把它当作无限带宽的文件代理并不合适。

Standard Ebooks 也提供 OPDS 1.2/2.0、Atom 和 RSS。它的“新书发布”Feed 面向所有人,而完整电子书 Feed 的访问包含赞助、贡献者或符合条件的开源项目等路径。WebNR 已把它列为值得接入的候选,但在获得适用访问方式并完成测试前,不会把受限 Feed 伪装成公开源。

2. WebNR 自建来源

当原始集合有合法分发依据,却没有 WebNR 所需的目录格式时,我们可以建立自己的 adapter 或静态 catalog。来源不必提供完整 metadata:文件名可以成为显示标题,作者和更新时间缺失时保持 Unknown,绝不以当前时间或猜测值填空。

今天上线的 WebNR Originals 就是第一例。它的目录地址是:

https://app.webnovel.win/sources/webnr-originals

目录中的原创短篇《灯下索引》和来源定义均以 CC0 1.0 发布。这个源也作为版本化健康检查样本,后续会持续验证 YAML 解析、明确链接、TXT 导入、IndexedDB 保存和离线阅读。

3. 社区维护的 Legado 规则仓库

GitHub 上仍能找到 XIU2/Yueduyolo52/Yuedu 等社区集合。它们对于研究字段、错误模式和规则兼容很有价值,也常常包含维护者记录的失效反馈。与此同时,规则文件许可不能替代目标站授权,规则可导入也不能证明搜索、目录和正文仍然稳定。

WebNR 对这类集合采用两层处理:

  • 兼容语料库: 保存最小、脱敏、可复现的字段样本,用来测试解析器;
  • 推荐目录: 只有逐条完成目标站条款、robots、登录、限速、版权与健康检查的来源才可能进入。

因此,社区仓库可以成为“哪里能学习规则”的答案,却不是“一键全部导入”的推荐。

4. 公共文本馆和区域性数字图书馆

青空文库、Wikisource、各国公共领域项目和大学数字馆藏是很重要的候选。它们的作品状态通常按作者、版本、编辑贡献和所在法域分别判断。接入时应保留作品页、作者、许可模板或公共领域依据,并为不同国家的读者提示版权期限差异。

这类来源通常比小说抓取站稳定,也更适合建立 OPDS、RSS 或 WebNR 自有索引。代价是需要逐项处理编码、竖排标记、注释、扫描 OCR 和不同许可。

5. 聚合站、镜像和“万能书源”分享页

这一类最容易短期可用,也最容易突然失效。常见问题包括域名频繁更换、搜索接口从 GET 改为 POST、验证码、Cloudflare 挑战、Cookie、登录、付费内容、编码变动和移动端脚本依赖。规则作者可能及时修复,也可能停止维护。

WebNR 不会通过绕过验证码、登录、付费、DRM、robots 或访问控制来维持兼容。面对这类候选,最有用的输出是明确写出“需要 Bridge”“只适合用户本地导入”“进入隔离语料库”或“拒绝接入”,而不是用一个绿色图标掩盖风险。

一条书源至少要通过哪些检查

读者可以用下面的顺序快速判断:

检查 要回答的问题 失败时怎么做
来源 谁维护规则,最后一次更新是什么时候? 找维护记录或换源
分发依据 内容属于公版、作者授权、正规平台,还是未经说明的转载? 只保留链接或拒绝接入
访问条件 是否需要账号、Cookie、验证码、付费或地区权限? 使用官方 App,或标明 Bridge/账号边界
网站政策 robots、条款和请求频率允许什么? 降低频率、使用官方 Feed,或停止自动访问
健康 搜索、详情、目录和正文是否都能完成? 区分局部失败与全源失效
安全 规则是否执行任意 JavaScript、请求额外域名或读取敏感状态? 进入受限运行环境或拒绝
可重复性 是否有固定样本和可再次运行的测试? 先建立 fixture 再宣称兼容

一个真正可维护的来源还应公开“最后测试日期”和“已知限制”。只写“可用”无法帮助下一位读者判断问题发生在什么时候。

今天的候选审计结果

本轮发现并核对了六个候选方向,完成了三项深入审计,并交付一个通过者:

候选 当前决定 主要依据
WebNR Originals 已接入 项目原创、CC0、同源静态目录、固定 TXT 和健康检查入口
Project Gutenberg OPDS 通过目录价值审计,等待专用 adapter 机器目录有价值;需要逐本核对许可和法域,并遵守 User-Agent、低频请求与落地页链接政策
Standard Ebooks OPDS 延期 完整 Feed 存在访问条件;需确认开源项目访问方式
gedoor/legado 当前仓库 仅作状态与公告引用 项目内容已删除,首页发布侵权相关公告
XIU2/Yuedu 隔离兼容语料候选 有规则和失效反馈价值;目标站许可需逐条复核
青空文库及其他区域馆藏 继续审计 读者价值高;需处理逐作版权、格式和编码

这个表不会把“延期”写成失败,也不会把“没有数据”写成零价值。下一轮将继续审计公共领域和作者授权目录,并建立 Project Gutenberg 的低频、落地页优先 adapter 设计。

WebNR 与 Legado 的当前兼容边界

WebNR 今天原生读取的是 search_index.yml 目录,而不是直接执行 Legado JSON。此次更新增加了显式标题、作品页和下载链接字段,限制目录大小,拒绝非 HTTP(S) 链接,并停止用当前时间伪装缺失日期。

Legado 兼容将分阶段推进:

  1. 导入 JSON 并报告支持、忽略和未知字段;
  2. 在自建 fixtures 上实现常见搜索、详情、目录、正文与分页规则;
  3. 增加受控 Cookie、变量和权限;
  4. 在限时、限内存、限能力环境中处理必要脚本;
  5. 把普通网页无法完成的 WebView 与跨域行为放进可选 Bridge。

每个公开兼容结论都会附带 capability level 和 fixture-suite 版本。WebNR 会尽可能读取现有定义,但不会用“兼容”三个字承诺绕过网站本身的限制。

读者接下来可以怎么做

先添加 WebNR Originals,确认阅读器的书源和 TXT 导入链路。随后检查目标来源的维护日期、授权依据、访问条件和健康状态。遇到失败时,记录具体阶段:添加失败、搜索失败、详情失败、目录失败还是正文失败。这样的报告比“书源不能用”更容易被复现和修复。

后续来源目录会为每个通过者提供语言、格式、访问条件、最后测试日期、健康状态和替代来源。读者也可以通过 WebNR GitHub issue 提交公开目录、作者授权 Feed、失效报告或兼容 fixture;提交一个链接即可,缺失 metadata 可以在审计中保持未知。

参考与核验页面

核验日期:2026-08-06。平台公告、访问政策和社区规则会变化;WebNR 的来源目录将以最近健康检查和公开依据更新。

7 Web Novel Readers Compared: Open-Source vs Commercial | 2024 Technical Deep Dive

Introduction

Web novel enthusiasts have a growing number of tools to streamline their reading experience. From mobile apps that aggregate chapters from fan-translation sites to official platforms with proprietary content, the ecosystem of web novel reader software is diverse. This post provides a developer-focused analysis of the most relevant projects – both open-source and commercial – comparing features, architectures, and target audiences. We'll break down how these competitors stack up against our project (a new entrant in this space), identifying strengths, gaps, and opportunities. Advanced users and potential contributors will gain insight into implementation details, scalability considerations, and best practices for building a web novel reader.

7款网络小说阅读器深度对比:开源vs商业应用 | 技术架构与功能分析

喜欢网络小说的读者如今有越来越多的工具来提升他们的阅读体验。从能聚合同人翻译站点章节的手机应用,到带有自有版权内容的官方平台,网络小说阅读器软件的生态相当多样。本文会从开发者的角度,对最相关的项目——无论是开源还是商业的——进行分析,并将各自的功能、架构和目标受众进行对比。我们也会讨论这些竞争对手如何与我们的项目(此领域的新进者)相比较,找出它们的优势、不足以及潜在机会。本文面向高级用户和潜在贡献者,可帮助他们了解实现细节、可扩展性,以及构建网络小说阅读器的最佳实践。