1. 从书荒到书仓阅读App资源接口到底在折腾什么如果你用阅读类App超过两年大概率经历过这样的循环某个书源突然搜不到书了换一个过几天又失效再换最后手机里存了十几个书源文件真正能用的没几个。这不是你运气差而是整个阅读App生态的底层逻辑决定的——书源接口本质上是一种寄生式的数据获取方式它的稳定性天然受制于目标站点的页面结构、反爬策略和域名变动。我接触阅读App书源这件事最早是从自己写规则开始的。当时的需求很简单追一本连载小说官方App广告太多想找个干净点的阅读器。后来发现阅读器本身只是个壳真正决定体验的是背后那套书源规则。于是从改别人的规则到自己抓包分析再到整理成可维护的接口记录前后折腾了三年多。这篇内容就是把我这些年积累的书源接口维护思路、聚合方案、TTS引擎选型、以及短剧类JSON接口的处理经验系统性地梳理一遍。需要先说清楚的是这篇不是给你一堆现成书源让你导入的帖子——那种东西生命周期极短发出来可能一周就废了。我要讲的是方法论怎么判断一个书源值不值得留、怎么自己动手修规则、怎么把零散的书源聚合成一个可用的资源库、以及当小说站变成短剧接口时该怎么适配。适合两类人看一是用阅读App但被书源失效折磨的普通用户二是想自己维护一套私有书源库的进阶玩家。关键词里提到的阅读App资源接口书源接口聚合书源纯净规则这几个词其实构成了一个完整的链条阅读App是载体资源接口是通道书源接口是具体实现聚合书源是管理手段纯净规则是质量保障。下面我按这个链条逐层拆开讲。2. 书源规则的本质一份翻译说明书2.1 书源不是资源是获取资源的指令集很多人对书源有个误解以为导入一个书源就等于拥有了一批书。实际上书源文件里存的全是规则没有一行正文内容。它做的事情是告诉阅读App去哪个网址、用什么方式请求、从返回的HTML里哪个位置提取书名、作者、章节列表和正文。打个比方书源就像一份菜谱。菜谱本身不能吃但它告诉你去哪里买菜、怎么切、怎么炒。如果菜市场搬了网站改域名或者菜的包装换了页面结构变了菜谱就得跟着改。这就是为什么书源会失效——不是书源坏了是它描述的那个菜市场变了。一个标准的书源JSON结构核心字段包括字段作用常见坑bookSourceUrl书源站点根地址域名换了这里必须同步改searchUrl搜索请求模板参数名和编码方式容易出错ruleSearch搜索结果提取规则最常失效的部分ruleBookInfo书籍详情提取规则简介和封面容易漏ruleToc目录章节列表规则分页目录处理麻烦ruleContent正文内容规则需要处理广告和分页2.2 规则语法CSS选择器、正则和JSONPath三件套阅读App的书源规则支持三种提取方式理解它们的适用场景是修规则的基本功。CSS选择器适合结构规整的HTML页面。比如classchapter-list的div下面有一堆a标签你可以写.chapter-list a直接拿到所有章节链接。它的优点是直观、好调试缺点是遇到动态渲染或者结构混乱的页面就抓瞎。正则表达式是万能工具但也是最容易写错的。比如从一段混杂的HTML里提取正文用正则div idcontent([\s\S]*?)/div能匹配但如果正文里嵌套了其他div就会提前截断。我的经验是能用CSS选择器就别用正则正则只留给那些结构实在没法用选择器描述的页面。JSONPath主要用在接口返回JSON数据的场景比如短剧接口。很多短剧App的数据是直接返回JSON的这时候用$.data.list[*].title这种写法比解析HTML高效得多。2.3 为什么纯净规则比功能多更重要新手选书源有个通病喜欢功能全的能搜书、能听书、能下载、能换源恨不得一个书源解决所有问题。但实际用下来你会发现功能越多的书源失效越快。原因很简单功能多意味着它依赖的接口多、页面多任何一个环节变动都会导致整体崩溃。所谓纯净规则我的定义是只做一件事且把这件事做到极致。一个只负责搜索和阅读正文的书源比一个集成了评论、推荐、书单的书源稳定得多。因为它的依赖面窄维护成本低。我在自己的书源库里会把书源按功能分层核心层只保留搜索目录正文三个规则其他花哨功能一律砍掉。这样即使某个站点改版我只需要修三个地方而不是十几个。提示判断一个书源是否纯净看它的ruleSearch里有没有嵌套太多无关字段。如果一个搜索规则里塞了评分、字数、更新时间、标签等一堆提取项这个书源大概率活不长。3. 聚合书源的搭建从散装到体系化3.1 为什么要做聚合而不是堆砌我见过有人手机里存了200多个书源搜索的时候要一个个切换体验极差。这不是聚合这是堆砌。真正的聚合书源核心价值在于一次搜索多源并发结果去重合并。阅读App本身支持多书源同时搜索但默认的并发策略比较保守。如果你导入的书源质量参差不齐搜索一次要等十几秒还夹杂大量重复结果。我的做法是先筛选再聚合最后分层。筛选的标准很简单连续测试三天搜索成功率低于80%的直接淘汰。测试方法也简单准备10本不同类型的小说玄幻、都市、历史、科幻各几本每天搜一次记录哪些书源能稳定返回结果。三天下来能留下的通常不到三分之一。3.2 分层管理的具体操作筛选完之后我会把书源分成三层第一层主力源5-8个。这些是搜索成功率高、正文质量好、更新及时的书源。它们承担日常90%的阅读需求。主力源的选择标准是稳不是全。哪怕它只能搜到某一类书只要稳定就值得留在主力层。第二层补充源15-20个。主力源搜不到的书用补充源兜底。这些书源可能更新慢一点或者只覆盖特定类型但作为补充足够用。第三层备用源不限。平时不用只在主力源和补充源集体失效时启用。备用源不需要经常维护但建议每季度检查一次把彻底死掉的清理掉。分层之后阅读App的搜索策略也要相应调整。主力源设为优先搜索补充源设为并行搜索备用源设为手动启用。这样日常搜索速度快遇到冷门书时再扩大范围。3.3 去重合并的规则设计聚合搜索最大的问题是重复结果。同一本书五个书源都搜到了显示五条看着就烦。阅读App支持结果去重但默认的去重规则比较粗糙只按书名匹配。我的做法是按书名作者双字段去重这样能过滤掉大部分同名不同书的干扰。具体操作是在书源管理里找到搜索去重选项把匹配字段改成nameauthor。如果App不支持自定义去重字段那就只能手动筛选或者用第三方的书源管理工具预处理。注意去重不是越严格越好。有些书源的书名会有细微差异比如斗破苍穹和斗破苍穹精校版严格去重会把它们当成两本书。我的建议是去重规则留一点容错空间宁可多显示一条也不要漏掉真正的版本差异。4. 短剧接口与JSON资源的适配思路4.1 短剧资源和小说资源的本质差异最近一年短剧类内容的需求明显上升。很多人想把短剧也接入阅读App但发现传统的书源规则根本用不上。原因在于小说站返回的是HTML短剧接口返回的是JSON。两者的数据结构完全不同。小说站的页面结构是标题正文的文本流而短剧接口返回的是剧集列表视频地址封面简介的结构化数据。用处理HTML的思路去处理JSON就像用筷子喝汤——工具不对。4.2 JSON接口的规则写法阅读App对JSON接口的支持主要靠ruleContent里的JSONPath语法。举个实际例子假设某个短剧接口返回这样的数据{ code: 200, data: { list: [ {title: 剧集1, url: https://example.com/1.m3u8, cover: https://example.com/1.jpg}, {title: 剧集2, url: https://example.com/2.m3u8, cover: https://example.com/2.jpg} ] } }对应的规则写法是{ ruleToc: { chapterList: $.data.list[*], chapterName: $.title, chapterUrl: $.url } }这里的关键是chapterList用[*]表示遍历数组chapterName和chapterUrl分别指向数组元素里的字段。和HTML规则相比JSON规则更简洁但前提是你得先搞清楚接口返回的字段名。4.3 短剧接口的常见坑短剧接口比小说接口更容易失效原因有三个第一鉴权机制复杂。很多短剧接口需要签名或者token这些参数会过期过期后整个接口就废了。处理办法是尽量找那些不需要鉴权的公开接口或者用阅读App的登录功能模拟获取token。第二视频地址有时效性。短剧的视频地址通常是带签名的临时链接几小时后就失效。这意味着你不能像小说那样缓存后慢慢看必须实时请求。这对网络环境要求更高。第三分页逻辑不统一。小说站的分页通常是?page2这种简单形式短剧接口的分页可能是游标式的需要从上一次返回里取nextCursor。这种分页在阅读App里处理起来比较麻烦需要用到ruleToc的高级配置。我的建议是短剧资源优先用专门的短剧App阅读App只作为补充。如果一定要接入选择那些接口稳定、不需要鉴权的源并且做好频繁维护的心理准备。5. TTS语音引擎的选型与调优5.1 为什么TTS体验差异这么大同样是用阅读App听书有人觉得声音自然流畅有人觉得机械刺耳。差异主要来自三个方面TTS引擎本身的质量、参数配置、以及文本预处理。阅读App支持多种TTS引擎包括系统自带的、第三方的、以及在线的。系统自带的引擎胜在稳定、离线可用但音质普遍一般。第三方引擎音质好但可能需要额外安装和配置。在线引擎音质最好但依赖网络且部分服务有调用限制。5.2 主流TTS引擎的对比引擎类型代表方案优点缺点适用场景系统内置各手机厂商自带离线、稳定、零配置音质一般、音色少通勤、无网络环境第三方本地各类开源TTS音质较好、可定制需要安装配置对音质有要求在线服务云端语音合成音质最佳、音色丰富依赖网络、可能收费居家、WiFi环境5.3 让TTS听起来不那么机器人的调参技巧选好引擎只是第一步参数调优才是关键。我总结了几条实用经验语速控制在0.9-1.1倍之间。太快了听不清太慢了容易走神。默认的1.0倍对大多数人来说偏快调到0.95左右比较舒服。适当增加停顿。在句号、段落之间增加200-300毫秒的停顿能显著提升可懂度。阅读App的TTS设置里通常有标点停顿选项把它打开。文本预处理很重要。小说正文里经常有……、—、特殊符号这些直接丢给TTS会读得很奇怪。我的做法是在书源的ruleContent里加一条替换规则把连续的点号替换成句号把破折号替换成逗号。这样TTS读出来就自然多了。提示如果你的阅读App支持正则替换可以在正文规则里加一条replaceRegex把[。]{2,}替换成单个标点避免TTS在连续标点处卡顿。6. 书源维护的日常一套可持续的工作流6.1 建立自己的检测机制书源失效是常态关键是尽早发现。我的做法是每周固定时间做一次批量检测用阅读App的书源检测功能或者用第三方的书源管理工具把所有书源跑一遍标记出失效的。检测的标准要明确搜索返回空结果、正文提取为空、目录加载失败这三种情况都算失效。检测结果记在一个表格里连续两周失效的书源直接淘汰偶尔失效的观察一周再决定。6.2 修规则的排查顺序发现书源失效后不要急着删先按这个顺序排查第一步检查域名。用浏览器打开书源地址看是否能正常访问。如果域名换了找到新域名替换即可。这一步能解决大约30%的失效问题。第二步检查搜索接口。手动构造搜索请求看返回的HTML结构有没有变化。重点看搜索结果的容器class名、书名和链接的标签结构。如果class名变了更新ruleSearch里的选择器。第三步检查正文规则。打开一本书的正文页看正文容器的id或class有没有变。很多站点改版时只改正文部分搜索和目录不变。第四步检查编码。有些站点从UTF-8改成了GBK或者反过来。编码不对会导致中文乱码看起来像失效其实只是编码问题。6.3 规则备份与版本管理修好的规则一定要备份。我的习惯是每次修改后把书源JSON导出按日期命名存一份。这样万一改错了可以随时回滚。备份文件建议存在两个地方本地和云盘。本地方便快速恢复云盘防止设备丢失。另外如果你维护的书源比较多建议用Git做版本管理。每次修改提交一次写清楚改了什么、为什么改。这样过几个月回头看能快速回忆起当时的思路。7. 关于长期更新这件事的现实预期7.1 没有一劳永逸的书源我必须坦诚地说任何声称永久有效的书源都是不现实的。书源的生命周期取决于目标站点的稳定性而站点的稳定性又受太多因素影响——服务器成本、内容合规、技术架构调整任何一个变量都可能让书源失效。所以长期更新的正确理解是建立一套可持续的维护机制而不是找到一个永不失效的源。机制包括定期检测、快速修复、分层管理、备份回滚。有了这套机制即使某个书源挂了你也能在半小时内恢复可用状态。7.2 自己动手能力比现成资源更重要我见过太多人到处求书源求到了用几天失效了再求。这种模式永远被动。真正解决问题的办法是学会自己修规则。修规则的门槛其实不高基础的CSS选择器和正则表达式花一个周末就能入门。剩下的就是熟练度问题修得多了自然就快了。我的建议是先从修改现成的书源开始把失效的源修好体会一下规则和页面的对应关系。然后尝试自己写一个简单的书源从搜索到正文完整跑通。这个过程走一遍你就再也不怕书源失效了。7.3 关于资源合规的边界最后说一个绕不开的话题书源的使用边界。阅读App本身是工具书源规则是技术实现但获取的内容是否合规取决于内容本身的授权状态。我的原则是只把书源用于个人阅读已获授权或公版的内容不传播、不牟利。这个边界每个使用者都应该心里有数。技术是中性的怎么用取决于人。我分享这些经验是希望帮助那些真正有阅读需求的人用更干净、更高效的方式获取内容而不是鼓励任何越界行为。这一点希望读到这里的你能理解。说到底阅读App书源这件事折腾的是技术服务的是阅读本身。工具会失效规则会过时但阅读的习惯和解决问题的能力是能陪你很久的东西。
阅读App书源接口维护指南：聚合书源与纯净规则实战
1. 从书荒到书仓阅读App资源接口到底在折腾什么如果你用阅读类App超过两年大概率经历过这样的循环某个书源突然搜不到书了换一个过几天又失效再换最后手机里存了十几个书源文件真正能用的没几个。这不是你运气差而是整个阅读App生态的底层逻辑决定的——书源接口本质上是一种寄生式的数据获取方式它的稳定性天然受制于目标站点的页面结构、反爬策略和域名变动。我接触阅读App书源这件事最早是从自己写规则开始的。当时的需求很简单追一本连载小说官方App广告太多想找个干净点的阅读器。后来发现阅读器本身只是个壳真正决定体验的是背后那套书源规则。于是从改别人的规则到自己抓包分析再到整理成可维护的接口记录前后折腾了三年多。这篇内容就是把我这些年积累的书源接口维护思路、聚合方案、TTS引擎选型、以及短剧类JSON接口的处理经验系统性地梳理一遍。需要先说清楚的是这篇不是给你一堆现成书源让你导入的帖子——那种东西生命周期极短发出来可能一周就废了。我要讲的是方法论怎么判断一个书源值不值得留、怎么自己动手修规则、怎么把零散的书源聚合成一个可用的资源库、以及当小说站变成短剧接口时该怎么适配。适合两类人看一是用阅读App但被书源失效折磨的普通用户二是想自己维护一套私有书源库的进阶玩家。关键词里提到的阅读App资源接口书源接口聚合书源纯净规则这几个词其实构成了一个完整的链条阅读App是载体资源接口是通道书源接口是具体实现聚合书源是管理手段纯净规则是质量保障。下面我按这个链条逐层拆开讲。2. 书源规则的本质一份翻译说明书2.1 书源不是资源是获取资源的指令集很多人对书源有个误解以为导入一个书源就等于拥有了一批书。实际上书源文件里存的全是规则没有一行正文内容。它做的事情是告诉阅读App去哪个网址、用什么方式请求、从返回的HTML里哪个位置提取书名、作者、章节列表和正文。打个比方书源就像一份菜谱。菜谱本身不能吃但它告诉你去哪里买菜、怎么切、怎么炒。如果菜市场搬了网站改域名或者菜的包装换了页面结构变了菜谱就得跟着改。这就是为什么书源会失效——不是书源坏了是它描述的那个菜市场变了。一个标准的书源JSON结构核心字段包括字段作用常见坑bookSourceUrl书源站点根地址域名换了这里必须同步改searchUrl搜索请求模板参数名和编码方式容易出错ruleSearch搜索结果提取规则最常失效的部分ruleBookInfo书籍详情提取规则简介和封面容易漏ruleToc目录章节列表规则分页目录处理麻烦ruleContent正文内容规则需要处理广告和分页2.2 规则语法CSS选择器、正则和JSONPath三件套阅读App的书源规则支持三种提取方式理解它们的适用场景是修规则的基本功。CSS选择器适合结构规整的HTML页面。比如classchapter-list的div下面有一堆a标签你可以写.chapter-list a直接拿到所有章节链接。它的优点是直观、好调试缺点是遇到动态渲染或者结构混乱的页面就抓瞎。正则表达式是万能工具但也是最容易写错的。比如从一段混杂的HTML里提取正文用正则div idcontent([\s\S]*?)/div能匹配但如果正文里嵌套了其他div就会提前截断。我的经验是能用CSS选择器就别用正则正则只留给那些结构实在没法用选择器描述的页面。JSONPath主要用在接口返回JSON数据的场景比如短剧接口。很多短剧App的数据是直接返回JSON的这时候用$.data.list[*].title这种写法比解析HTML高效得多。2.3 为什么纯净规则比功能多更重要新手选书源有个通病喜欢功能全的能搜书、能听书、能下载、能换源恨不得一个书源解决所有问题。但实际用下来你会发现功能越多的书源失效越快。原因很简单功能多意味着它依赖的接口多、页面多任何一个环节变动都会导致整体崩溃。所谓纯净规则我的定义是只做一件事且把这件事做到极致。一个只负责搜索和阅读正文的书源比一个集成了评论、推荐、书单的书源稳定得多。因为它的依赖面窄维护成本低。我在自己的书源库里会把书源按功能分层核心层只保留搜索目录正文三个规则其他花哨功能一律砍掉。这样即使某个站点改版我只需要修三个地方而不是十几个。提示判断一个书源是否纯净看它的ruleSearch里有没有嵌套太多无关字段。如果一个搜索规则里塞了评分、字数、更新时间、标签等一堆提取项这个书源大概率活不长。3. 聚合书源的搭建从散装到体系化3.1 为什么要做聚合而不是堆砌我见过有人手机里存了200多个书源搜索的时候要一个个切换体验极差。这不是聚合这是堆砌。真正的聚合书源核心价值在于一次搜索多源并发结果去重合并。阅读App本身支持多书源同时搜索但默认的并发策略比较保守。如果你导入的书源质量参差不齐搜索一次要等十几秒还夹杂大量重复结果。我的做法是先筛选再聚合最后分层。筛选的标准很简单连续测试三天搜索成功率低于80%的直接淘汰。测试方法也简单准备10本不同类型的小说玄幻、都市、历史、科幻各几本每天搜一次记录哪些书源能稳定返回结果。三天下来能留下的通常不到三分之一。3.2 分层管理的具体操作筛选完之后我会把书源分成三层第一层主力源5-8个。这些是搜索成功率高、正文质量好、更新及时的书源。它们承担日常90%的阅读需求。主力源的选择标准是稳不是全。哪怕它只能搜到某一类书只要稳定就值得留在主力层。第二层补充源15-20个。主力源搜不到的书用补充源兜底。这些书源可能更新慢一点或者只覆盖特定类型但作为补充足够用。第三层备用源不限。平时不用只在主力源和补充源集体失效时启用。备用源不需要经常维护但建议每季度检查一次把彻底死掉的清理掉。分层之后阅读App的搜索策略也要相应调整。主力源设为优先搜索补充源设为并行搜索备用源设为手动启用。这样日常搜索速度快遇到冷门书时再扩大范围。3.3 去重合并的规则设计聚合搜索最大的问题是重复结果。同一本书五个书源都搜到了显示五条看着就烦。阅读App支持结果去重但默认的去重规则比较粗糙只按书名匹配。我的做法是按书名作者双字段去重这样能过滤掉大部分同名不同书的干扰。具体操作是在书源管理里找到搜索去重选项把匹配字段改成nameauthor。如果App不支持自定义去重字段那就只能手动筛选或者用第三方的书源管理工具预处理。注意去重不是越严格越好。有些书源的书名会有细微差异比如斗破苍穹和斗破苍穹精校版严格去重会把它们当成两本书。我的建议是去重规则留一点容错空间宁可多显示一条也不要漏掉真正的版本差异。4. 短剧接口与JSON资源的适配思路4.1 短剧资源和小说资源的本质差异最近一年短剧类内容的需求明显上升。很多人想把短剧也接入阅读App但发现传统的书源规则根本用不上。原因在于小说站返回的是HTML短剧接口返回的是JSON。两者的数据结构完全不同。小说站的页面结构是标题正文的文本流而短剧接口返回的是剧集列表视频地址封面简介的结构化数据。用处理HTML的思路去处理JSON就像用筷子喝汤——工具不对。4.2 JSON接口的规则写法阅读App对JSON接口的支持主要靠ruleContent里的JSONPath语法。举个实际例子假设某个短剧接口返回这样的数据{ code: 200, data: { list: [ {title: 剧集1, url: https://example.com/1.m3u8, cover: https://example.com/1.jpg}, {title: 剧集2, url: https://example.com/2.m3u8, cover: https://example.com/2.jpg} ] } }对应的规则写法是{ ruleToc: { chapterList: $.data.list[*], chapterName: $.title, chapterUrl: $.url } }这里的关键是chapterList用[*]表示遍历数组chapterName和chapterUrl分别指向数组元素里的字段。和HTML规则相比JSON规则更简洁但前提是你得先搞清楚接口返回的字段名。4.3 短剧接口的常见坑短剧接口比小说接口更容易失效原因有三个第一鉴权机制复杂。很多短剧接口需要签名或者token这些参数会过期过期后整个接口就废了。处理办法是尽量找那些不需要鉴权的公开接口或者用阅读App的登录功能模拟获取token。第二视频地址有时效性。短剧的视频地址通常是带签名的临时链接几小时后就失效。这意味着你不能像小说那样缓存后慢慢看必须实时请求。这对网络环境要求更高。第三分页逻辑不统一。小说站的分页通常是?page2这种简单形式短剧接口的分页可能是游标式的需要从上一次返回里取nextCursor。这种分页在阅读App里处理起来比较麻烦需要用到ruleToc的高级配置。我的建议是短剧资源优先用专门的短剧App阅读App只作为补充。如果一定要接入选择那些接口稳定、不需要鉴权的源并且做好频繁维护的心理准备。5. TTS语音引擎的选型与调优5.1 为什么TTS体验差异这么大同样是用阅读App听书有人觉得声音自然流畅有人觉得机械刺耳。差异主要来自三个方面TTS引擎本身的质量、参数配置、以及文本预处理。阅读App支持多种TTS引擎包括系统自带的、第三方的、以及在线的。系统自带的引擎胜在稳定、离线可用但音质普遍一般。第三方引擎音质好但可能需要额外安装和配置。在线引擎音质最好但依赖网络且部分服务有调用限制。5.2 主流TTS引擎的对比引擎类型代表方案优点缺点适用场景系统内置各手机厂商自带离线、稳定、零配置音质一般、音色少通勤、无网络环境第三方本地各类开源TTS音质较好、可定制需要安装配置对音质有要求在线服务云端语音合成音质最佳、音色丰富依赖网络、可能收费居家、WiFi环境5.3 让TTS听起来不那么机器人的调参技巧选好引擎只是第一步参数调优才是关键。我总结了几条实用经验语速控制在0.9-1.1倍之间。太快了听不清太慢了容易走神。默认的1.0倍对大多数人来说偏快调到0.95左右比较舒服。适当增加停顿。在句号、段落之间增加200-300毫秒的停顿能显著提升可懂度。阅读App的TTS设置里通常有标点停顿选项把它打开。文本预处理很重要。小说正文里经常有……、—、特殊符号这些直接丢给TTS会读得很奇怪。我的做法是在书源的ruleContent里加一条替换规则把连续的点号替换成句号把破折号替换成逗号。这样TTS读出来就自然多了。提示如果你的阅读App支持正则替换可以在正文规则里加一条replaceRegex把[。]{2,}替换成单个标点避免TTS在连续标点处卡顿。6. 书源维护的日常一套可持续的工作流6.1 建立自己的检测机制书源失效是常态关键是尽早发现。我的做法是每周固定时间做一次批量检测用阅读App的书源检测功能或者用第三方的书源管理工具把所有书源跑一遍标记出失效的。检测的标准要明确搜索返回空结果、正文提取为空、目录加载失败这三种情况都算失效。检测结果记在一个表格里连续两周失效的书源直接淘汰偶尔失效的观察一周再决定。6.2 修规则的排查顺序发现书源失效后不要急着删先按这个顺序排查第一步检查域名。用浏览器打开书源地址看是否能正常访问。如果域名换了找到新域名替换即可。这一步能解决大约30%的失效问题。第二步检查搜索接口。手动构造搜索请求看返回的HTML结构有没有变化。重点看搜索结果的容器class名、书名和链接的标签结构。如果class名变了更新ruleSearch里的选择器。第三步检查正文规则。打开一本书的正文页看正文容器的id或class有没有变。很多站点改版时只改正文部分搜索和目录不变。第四步检查编码。有些站点从UTF-8改成了GBK或者反过来。编码不对会导致中文乱码看起来像失效其实只是编码问题。6.3 规则备份与版本管理修好的规则一定要备份。我的习惯是每次修改后把书源JSON导出按日期命名存一份。这样万一改错了可以随时回滚。备份文件建议存在两个地方本地和云盘。本地方便快速恢复云盘防止设备丢失。另外如果你维护的书源比较多建议用Git做版本管理。每次修改提交一次写清楚改了什么、为什么改。这样过几个月回头看能快速回忆起当时的思路。7. 关于长期更新这件事的现实预期7.1 没有一劳永逸的书源我必须坦诚地说任何声称永久有效的书源都是不现实的。书源的生命周期取决于目标站点的稳定性而站点的稳定性又受太多因素影响——服务器成本、内容合规、技术架构调整任何一个变量都可能让书源失效。所以长期更新的正确理解是建立一套可持续的维护机制而不是找到一个永不失效的源。机制包括定期检测、快速修复、分层管理、备份回滚。有了这套机制即使某个书源挂了你也能在半小时内恢复可用状态。7.2 自己动手能力比现成资源更重要我见过太多人到处求书源求到了用几天失效了再求。这种模式永远被动。真正解决问题的办法是学会自己修规则。修规则的门槛其实不高基础的CSS选择器和正则表达式花一个周末就能入门。剩下的就是熟练度问题修得多了自然就快了。我的建议是先从修改现成的书源开始把失效的源修好体会一下规则和页面的对应关系。然后尝试自己写一个简单的书源从搜索到正文完整跑通。这个过程走一遍你就再也不怕书源失效了。7.3 关于资源合规的边界最后说一个绕不开的话题书源的使用边界。阅读App本身是工具书源规则是技术实现但获取的内容是否合规取决于内容本身的授权状态。我的原则是只把书源用于个人阅读已获授权或公版的内容不传播、不牟利。这个边界每个使用者都应该心里有数。技术是中性的怎么用取决于人。我分享这些经验是希望帮助那些真正有阅读需求的人用更干净、更高效的方式获取内容而不是鼓励任何越界行为。这一点希望读到这里的你能理解。说到底阅读App书源这件事折腾的是技术服务的是阅读本身。工具会失效规则会过时但阅读的习惯和解决问题的能力是能陪你很久的东西。
原理与实现详解)
