接口系列——睿站BV号的时代来了
昨天（23）号开始，B站的视频号从我们喜闻乐见的av号变成了bv号，内容也从熟悉的数字变成了一串12位看起来没有规律的字符串。不过背后自然是有其算法的不过也没啥能力去深究，昨晚得知此事后特地去看了看，顺带记录在这个重要历史时刻的研究记录
一开始注意到地址栏的BV号，之前做接口时很清楚，对于不同的编号而言，av号其实只是我们能直接接触到的编号，实际上对于睿站的系统中有很多意义与适用范围不同的编号。 - AV号，就是视频编号，内部参数为aid，就是我们常见的定位并识别一个视频页的编号，也是大众所认知中的唯一一个编号
- 分P号，内部参数cid。其实我们都知道一个视频底下up可以上传多个p，而为了区分这多个p每个会有独立的cid，实际上，只有结合cid和cid才能唯一确定一个视频，虽然我也不清楚为啥不能直接用cid直接确定。cid与aid相似，会长一些，但是规律没有研究过
- Media号，看起来像是个媒体编号，其实指的就是PCG内容，最常见的就是番剧，还包括纪录片内容。内部编号mid，网页参数显示为md，如果你到过一个番剧介绍页，应该能留意到顶部的md号。但是，并不一定能用mid来确定唯一的番剧，具体原因也不明晰，真正的要确认一个番剧的编号，需要用到下面的编号
- Season号，即季度ID，内部参数sid。从BiliPlus提供的开放接口，要定位到一个bangumi需要的是sid，具体原理其实我没有自己详细地去拆和番剧相关的接口，未来有时间以后可能会有新的发现
- ss/ep号，这两个主要是出现在和PGC内容相关的播放页上，就是你看到的番剧或者纪录片的播放页地址栏里面的东西。首先这东西确实有着它的区分作用，但实际上对于这个视频它最后还是要被处理成aid来进行请求的，因此番剧的每一话也是有独立的av号的，也能通过直接输入地址栏的方式访问。至于ss/ep到aid的转换其实相当粗暴。没有是用到什么接口，而是直接在返回的页面内联的js代码上直接写入了aid(不知道啥操作)，不过到目前也没有研究过睿站的后端组成（当然用go是知道的，不过对go不熟悉，估计应该是用了模板引擎）
那么这次换成BV号之后，我发现对于视频调后端接口时那还是用的av号，因此进行了简单的溯源，最先发现的是在请求页面的Header上面，但是我之前没有注意到，刚才我去查关于PGC相关的播放页的时候，这个相同的位置带的是ep号，大概是已经很久就有了也无从求证，不过因此猜测应该是之前就有了，只不过现在还在而已。 具体实现方法，首先我们请求一个页面 > https://www.bilibili.com/video/BV1N7411U7m7
不用等页面载入完成，我们直接按F12打开开发者工具，切换到Network标签页。现在这里面啥也没有，我们需要按F5再次载入一遍
受限于篇幅我就不一一讲解开发者工具面板的各个功能了，这个基本上可以说是除第三方软件之外最方便的抓包方式了，在这些请求列表中往上翻，找到第一个请求，很明显那就是浏览器发往这个地址的第一个GET请求，后续的请求都是来源于这个页面里面的资源载入的。 
再详情页往下翻，在其返回的请求头(Response Headers)中，找到vikingrMCCache一行，可以发现我们要找的av隐藏在这里
这部分是我自己找到的，不过应该是有跟方便直接调用接口的方法，不过那会已经两点了得先睡了。
今早我想起来我之前为了番剧数据中心做的一个轮子，其主要是请求睿站相关接口获取信息的库，其中有一个接口是获得视频统计信息的，这个接口需要的参数很简单，就一个aid，而且方法也是用GET，因此我们可以直接在浏览器去请求它。接下来我们只要手动构造这个URL > https://api.bilibili.com/x/web-interface/archive/stat?aid=98737218
但是你直接点击上面的链接是不能访问的，因为浏览器在跳转页面时会在其请求的Headers中携带Referer，通过识别是外站的来源是直接拒绝，所以我们要做的是先复制一遍，再到浏览器地址栏当中手动粘贴。
返回的JSON数据有浏览器插件进行格式化，因此在没有此类插件的情况下可能就是一堆数据堆一块了。 此时我们有了新发现，原先的这个接口我们能在其中找到bvid，也就是说，我们做到了通过av号查询bv号。
那能不能通过bv号查询av号呢？其实最开始提到的方法也能实现，但是确实相当麻烦，而后我无意间翻评论区时有人提到了这个接口，虽然不是同一个域，但也能达到了我们的目的 > https://api.bilibili.com/x/web-interface/view?bvid=BV1N7411U7m7
不过，这上面的链接是可以直接点击访问的！（搞不懂他的业务逻辑），其实大概看了里面的数据可以发现，其实这个接口的功能和上一个是差不多的，但是这个接口更全，不仅有标题和视频简介，还有封面地址和分p信息，可能这个就是用于渲染页面信息的主要接口了，上面那个似乎是比较稳定的统计？观察感觉是给视频左上角看的，因为这个接口里面有版权相关的信息。
关于av号以后的编号，有可能会保留一段时间过渡后逐步完全消失，也有可能会一直存在于接口调用过程中，要怎么规划就要问他们了。不过在引入bv之后，似乎av号的顺序不再是按顺序的了，虽然大家都很期待一亿av号，不过其实已经有了4e和9e的av号了，似乎是随机的，但是比较奇怪的是，后来我借用轮子去写的一个简单的遍历工具从980w开始往上探，发现找到的几乎都是最近发布的，但是其实在这986w这些地方，av号相当分散，不知道是因为这些还没有过审还是因为压根没有视频，这个就不得而知了。 不过，我还是完成可一个一亿av号的小工具，中途测试过程中没有上限速接口跑到20次/s才发现还是会被卡ip，后来用关路由大法下楼一趟回来之后就解了，平时我自己写的工具当中频率一般是限10次/s，所以这个频率还是很可观的。 今天似乎一整天都在码字，要不就是在忙或者写这个工具，看起来今天似乎又要继续加班了。
最后贴上这两个视频地址备忘： BV1Q541167Qg av455017605 BV1cT4y1G7o6 av925122218