小红书WEB端社区精选抓取之JS调试初探

前言

数据抓取，JS调试，看起来两者并没有什么关系，然而前者是目的，后者是方法，缺一不可。小红书之前火过一段时间，最近却没有听到太多它的声音了，不过据说用户量已经达到三亿，所以对它的数据还是有些兴趣的。

目的

调研过小红书的都知道，它的数据主要集中在App端，但是需要注册登录才能看到，另外在Web端也有部分数据暴露出来，只是数量很少。本文就对其Web端的“社区精选”栏目下的数据产生了兴趣，该栏目下的数据虽然也不多，不过想想应该属于精选内容，估计质量还不错吧，不管是从作者还是从笔记的内容来说。而且经过观察，该栏目下的数据是会更新的，尽管不知道更新频率是咋样的。那就开始吧，分析一下该页面的接口请求。

网络分析

一般来说网页上面显示的数据要么是在格式已经固定的html文档中，要么是需要让浏览器执行JS把具体内容的数据填入到这个框框里面，可以参考浏览器是怎样加载js代码的？。其实不论是哪种方式，具体的内容数据一定会在网络传输中出现。具体的内容数据经常出现在如下三个位置：
1. 数据就在格式固定的静态html文档中。
2. 数据在html文档中的JS代码中，后续通过浏览器执行JS代码再把数据填入到html文档指定位置处。
3. 数据不在html文档中，利用JS代码发起新的网络请求获取数据，然后再把数据填入到html文档指定位置处。

小红书的社区精选接口就属于以上第三种情况。

网络请求

先用浏览器打开小红书的社区精选页面吧，笔者比较常用Chrome浏览器，当然其他像Firefox、Safari等等浏览器应该都可以的，相关操作估计也差不多，本文的示例使用的是Chrome浏览器。URL：https://www.xiaohongshu.com/explore ，如下图所示：
可以看到卡片形式的精选笔记，能够看到每个卡片的封面图、标题、作者头像、作者昵称、点赞数等信息，一共有差不多20个卡片，点击查看更多时则提示让下载小红书App，也就是不能查看到更多的精选笔记了。如果点击任意一个卡片的话则会跳转到笔记详情页面去，这个页面里的信息就多了，但是本文不对笔记详情页面进行分析，只关注社区详情页面。

接着打开Chrome的开发者工具吧，进入开发者工具的方式有多种，笔者经常的操作是在页面随便找个地方点击右键，然后选择检查即可，如果对页面的什么地方感兴趣，也可以在那里右键选择检查，就可以看到该处对应的HTML DOM树的情况。然后我们选择Network选项卡，用于监控Chrome发出的网络请求，如下图所示：
Network选项卡下面的很多小按钮都可以研究一下，笔者打开或者选中了其中几个可以参考。

准备好了，刷新一下页面吧，看看都有哪些请求。能够看到请求非常的多，主要包括html文档、图片、JS、接口，等等。先看第一个请求吧，这个请求就是对www.xiaohongshu.com/explore.html文档的请求，可以点击Preview进行预览，如下图所示：
是不是很奇怪，这个预览的结果和页面的展示很不一样，少了那些重要的卡片内容。那么这时候就能够判断出来这个页面的具体内容不属于其所在位置的第一种情况！

数据就在格式固定的静态html文档中。

接着在这个html文档中找找看，看看能不能在JS代码或者什么别的地方找到卡片内容数据，先选到Response，然后点击下面的大括号能够好看一些，如下图所示：
从图中能够看出，在JS中存在部分数据，但是依然没有卡片内容数据。那么这时候就能够判断出来这个页面的具体内容不属于其所在位置的第二种情况！

数据在html文档中的JS代码中，后续通过浏览器执行JS代码再把数据填入到html文档指定位置处。

那么卡片内容数据只可能属于第三种情况了，也就是需要单独请求一个接口才能拿到卡片内容数据，这种情况其实很常见，根据经验可以在网络监控处选择xhr，能够过滤出使用XMLHttpRequest访问的接口，当然也可以不过滤，一个请求一个请求的看过去，如下图所示：
这时候我们就找到了数据具体内容所在的接口，那么下面就继续看这个接口吧：https://www.xiaohongshu.com/fe_api/burdock/v2/homefeed/notes?pageSize=20&oid=recommend&page=1

接口测试

上文中找到了数据所在的接口，但是如果直接在浏览器打开这个url地址，是得不到数据的，会有一个报错msg：Unauthorized，那么这是为什么呢？这说明浏览器打开这个url的请求与上文找到的请求存在不同点，这时候就要找到哪儿不一样。根据经验，请求时的方法是get还是post，headers里面是不是存在参数校验等问题。那么就需要对接口进行测试，笔者比较常用Postman，测试起来比较方便，另外像Brupsuit或者编写代码来测试都可以选择。使用Postman访问该接口，如下图所示：
从图中能看出，返回结果依然是Unauthorized，同直接在浏览器打开的效果一样，怀疑是headers里面存在某种校验，那么就把xhr的接口请求的headers拷贝到Postman里再试试看吧，xhr接口请求headers如下图所示：
从图中发现有个参数很可疑：x-sign，signature的缩写嘛，强烈怀疑是它的问题。那就先把这个参数加到Postman的headers里去试试，如下图所示：
从图中能看到，headers中带上这个x-sign之后，能够正常拿到返回数据，那么就能够确定就是这个参数做了计算与校验。

JS调试

以上知道了x-sign参数的重要性，但是我们还想知道这个参数是怎么构造出来的呢？xhr请求的时候带了这个参数，那么也就是JS代码中计算了这个参数并添加到了请求headers中。

以上内容编辑于：2020年6月28日 17:08

社区精选页面改版

这篇文章笔者之前没有写完，拖了这么久终于有点时间再接着写，然而发现这个页面改版了，找不到fe_api接口了，取而代之的是explore接口本身就携带了卡片数据，尽管这样更好抓取了，但是却让JS调试失去了用武之地，因此本文到这里就可以结束了，JS调试的部分后面有时间笔者再看看有什么地方是必须要用的吧。