包含合集的UP主分页只能获取前20个视频

[sliots]

问题描述
获取该UP主视频时，发现分页只能获取前20个视频
https://space.bilibili.com/1632770256
https://space.bilibili.com/1632770256/video

[nICEnnnnnnnLee]

查询UP主所有视频有两种方法。

第一种，像https://space.bilibili.com/1632770256/video。
优点是可以进行分页查询
缺点是相关的api只能获取最基本的信息。比如，如果BV是多P视频，那么只有第一P的信息；如果是不同BV组成的合集，那么只有该合集信息，以及合集第一个BV的BV号。

使用这种方式的话，每个BV又要更进一步进行查询，因为我们不知道这个BV是否是最简单的单P视频。这样的话网络请求实在是太多了。

第二种，像https://www.bilibili.com/list/1632770256。
优点是可以一步到位，把相关的视频信息都拉出来
缺点是无法按照页数进行分页查询，它的查询逻辑是给定BV号后面的若干视频。
比如要查第5页，那么必须知道第4页最后一个视频，然后是第3页...以此类推。第1页需要的信息为空。
另一个缺点，就是它虽然有所有的BV信息，但是却并不知道单个BV是否属于多BV合集

[nICEnnnnnnnLee]

6.26版本，我们的做法是综合两者。比如，分页大小为20，查询第5页的信息。
首先，根据第一种的API，我们构造分页大小为1,页数为81的请求，找到第81个BV的信息。
然后，根据第二种的API，我们查询第81个BV在内的20个BV。

对于只有单P、多P视频的UP来说，这种做法是没有问题的。
对于含有多BV合集的UP来说，问题很大。

第一种的API只能查询到多BV合集的第一个BV(这个合集里的其它BV是get不到的)，而第二种是全部。
两种API查的BV在数量以及排序上面有了很大的分歧。

[nICEnnnnnnnLee]

现在，我们的做法仍然是综合两者。具体的，举例来说，分页大小为20，查询第5页的信息。
首先，根据第一种的API，我们构造分页大小为1,页数为81的请求，找到第81个BV的信息。

然后，根据第一种的API，我们构造分页大小为1,页数为101的请求，找到第101个BV的信息。

再然后，根据第二种的API，我们查询第81个BV在内的20个BV。
如果结果包含有第101个BV，那么在该BV位置结束(不包含该BV)。
如果没有，找到最后一个BV，查询不包含该BV在内的后20个BV...以此类推，直到包含有第101个BV结束。

这个方法有两个缺点：

• 无法确认BV在UP主投稿的视频中具体的顺序位置，自定义文件名中的参数pn有可能不准确。
• 单个分页查询可能漏掉多BV合集的某些视频。主要是多BV合集是持续更新的，时间跨度大的话可能出现在相邻分页甚至跨更多页。
  当然，如果目的是从首页开始逐页进行整体查询的话，那么问题不大。