小说网站解析

打开任何一个小说网站，小说首页铺满的网站都是封面图、排行榜和推荐位。解析这套视觉逻辑跟电商App几乎没区别——刺激点击，小说延长停留，网站把用户的解析注意力打包卖给广告主。但小说网站真正的小说骨架不在前端，而在后端那套解析系统里。网站

我最早注意到这件事，解析是小说因为一个做爬虫的朋友抱怨某网站改了章节页的HTML结构。他之前抓了三个月的网站数据一夜之间全乱套，正则表达式匹配不上了。解析我说你为什么不直接调接口？小说他愣了一下，说没想过。网站其实大部分小说网站的解析前端页面本身就是从接口拿的JSON数据，再渲染成HTML。与其去啃那堆嵌套div，不如直接找到XHR请求里的API地址。

以起点中文网为例。打开一本小说的目录页，按F12切到Network面板，刷新一下，你会看到类似/ajax/book/xxx/chapterlist这样的请求。返回的数据里每个章节都有chapterId、chapterName、updateTime这些字段。拿到chapterId之后拼接详情页URL，再请求一次，正文内容就在返回的JSON里。整个过程干净利落，比解析HTML省事得多。

但问题来了——付费章节拿不到。

这就是小说网站解析的核心矛盾：免费章节随便抓，付费章节层层设防。常见的防护手段有这么几种。一是正文图片化，把文字转成图片再切片，让你没法直接提取文本。二是字体加密，页面上的文字用自定义字体映射，你看到的是“你好”，源码里可能是“”这种乱码。三是接口签名，每次请求都要带一个根据时间戳和密钥算出来的token，过期不候。

字体加密这个事值得多说两句。它的原理不复杂：网站加载一个自定义的woff字体文件，这个字体里每个字形的Unicode编码跟正常字体不一样。比如正常字体里“的”对应U+7684，但在加密字体里可能对应U+E123。你直接读HTML源码得到的是U+E123，只有配合那个字体文件做映射才能还原成“的”。破解方法也有——下载字体文件，用fontTools这类库解析glyph的轮廓数据，跟标准字体做比对，建立映射表。不过网站也不傻，字体文件经常换，映射关系也跟着变，你得持续更新。

另一个容易被忽略的点是目录页的分页逻辑。有些网站目录页只显示最新100章，剩下的要通过“展开全部”按钮触发异步加载。这个按钮背后往往是一个POST请求，参数里带bookId和page。你不处理这个，抓下来的章节列表就是残缺的。

还有个坑是编码。国内小说网站主流用UTF-8，但部分老站还在用GBK。你用requests库直接r.text拿到的可能是乱码，得先r.content再用decode('gbk')转。这个细节不处理，后面所有解析都是白费功夫。

说回付费章节。技术上能不能绕过？能，但没必要展开。我更想说的是，解析小说网站这件事本身正在变得越来越麻烦。反爬策略从最初的User-Agent检测，进化到行为分析、设备指纹、验证码挑战。你写个脚本批量请求，人家服务端一眼就能从请求间隔的规律性判断出这不是真人。

所以现在做小说解析，纯技术手段只是一半。另一半是节奏控制——加随机延迟、模拟鼠标轨迹、轮换代理IP。听起来像在做渗透测试，实际上只是为了把一本连载小说完整地存到本地。

我自己的做法比较简单：只抓已完结的免费作品，用asyncio加aiohttp并发请求，每个请求之间sleep一到三秒的随机值。一本书两三百章，大概十几分钟跑完。不碰付费内容，不碰正在连载的热门书，够用就行。

解析这件事说到底就是跟网站开发者博弈。你更新防护，我更新绕过方案。但大多数时候，找到那个藏在Network面板里的API接口，问题就解决了一大半。