bilibili(1)-爬取视频信息进行数据分析

Posted 2023-04-21

参考技术A 感谢@雄哥和@逊哥的帮助才得以完成这篇文章，不然，还不知怎么应对IP限制。
项目地址： https://github.com/UranusLee/bilibili_spider

通过chrome可以看出来B站视频统计信息是通过js加载，打开开发者工具可以到stat?aid=31的json文件。

再分析json文件的加载方式，基本可以得到所需要的headers参数。

因为之前一直都在爬取豆瓣、知乎、拉勾这些有特殊headers的网站，所以，为了省事，还是全部headers都加上。

进行爬取的时候，发生了一点问题，通过不断测试，基本可以断定B站有IP访问限制，基本上是1分钟150次以下不会封IP，封闭IP一次为5分钟，所以考虑用代理IP，拿着买好的稳定的IP，刻不容缓的加入进来。

总共爬取下来710多W条数据，用了三四天的时间，期间网络断掉，或者IP地址停用，一直耽搁，之所以不准备继续下去是因为数据还准备做一个B站每年数据分析，所以选用了aid=11883351这条数据作为截止可以比较好的对应上每年7月初的一个数据对比分析

发现有播放数为-1的值，总共占数据总量的2%，故而删除。

可以看出基本上播放量，弹幕，评论回复，收藏，硬币，分享基本就是长尾数据，有大量的小数值的数据，但是整体的平均值受极值的影响较大。相比较而言view播放量更加有研究性。

1.播放量占比分析

总共分为<500,500-1000,1000-5000,5000-20000,>20000。
播放量整体还是大量的淹没视频，播放量小于500的达到了整体视频的48.8%，而播放量20000以上的只占到5.4%，按照“二八原则”，视频达到3338以上的播放量即达到B站视频实际效用的界限。

2.分年份分析B站视频增长速度

以每年7月份为周期分析

通过aid可以查到所有爬下的数据所属的时间，再按照概率分析大概的时间就可以得出每一年7月份的视频量。

整体的视频数量增长速度实际上是大致按照每年翻倍的速度来增长，整体增长曲线抛开10-11年，整体增长平和。

2010-2011年之间，必定是发生了事才会导致视频量突增，才会导致视频总量增长率超过800%。通过查询，基本确实如之前所假设一样，10年因为Ac fun（A站）确实发生了严重的几次弹幕冲突，A站关闭了弹幕系统，加上很多人打出“ACG滚出ac”的标语，大量的A站up主转移至B站，开始了B站的逆袭。

14年一年视频增长率唯一一次跌至94%，是因为14年动画版权问题，禁止了私自上传动画，视频量比预期下跌了大概8W左右。今年更加夸张的是2018年还没有到07月份，视频总量已经达到2200W左右。

3.参与率分析用户活跃度

弹幕成本是最低的，大概平均27.8人次观看，就会出现一次弹幕（包括非会员的观看次数，但是无法发弹幕，提高了弹幕成本），分享成本不仅仅是会员，非会员没有登陆也可以分享，这确实42.58人次的成本仅仅高于弹幕成本，说明B站整体视频风格更加多元化。121.58的投币成本受限于B站的投币系统，B币少，并且获得有难度，导致投币成本远高于其他几项。

4.投币分析

B站投币有“不牛不投，不服不投”的潜性规则，往往一个视频的投币量可以反应视频的质量和B站的流行趋势。
排名第一的是 【哔哩哔哩2017拜年祭】 ，94.1W投币
排名第二的是 【古筝】千本樱——你可见过如此凶残的练习曲 ，79.6W投币
排名第三的是 【哔哩哔哩2016拜年祭】 ，77.2W投币
然后是敖厂长的两连击
【敖厂长】让你耳朵怀孕的FC游戏 ,74.6W投币
【敖厂长】打脸!魂斗罗水下八关存在 ,73.0W投币

其实可以看出前三名中，两次拜年祭以及用户群体的自发投币，整个拜年祭已经成为B站文化的一部分，是每年最核心的一部分。当然也不缺乏敖厂长这种良心up主，每一次对于过往游戏的解疑和介绍，还有那无所不能的哥们，宅男但不失真心，牛逼但非常人亲。

文化的多元化才是整个B站撑起一片天的本质原因，我曾经在B站中过《极乐净土》的毒，看过外国人在中国成了网红，听过古筝弹奏魂斗罗、弹奏日本电音。这是一个大熔炉，每个人都可以找到自己喜欢的东西，我突然想起了广告模块的一个高分视频，弹幕量只有300，但是播放量有2000多万次，我不知道是B站运营人员清空了一部分的弹幕和评论，但是一个广告在B站，在这个无数个平时看都不看广告的年轻人，能够看上2000多万次，几乎人均一次。我才觉得我真正的知道。

----------------------------------------------------分割线-------------------------------------------
数据分析的部分有点意犹未尽，今天实在是困了，今天稍晚或者明天会继续对于B站各个模块继续进行深挖，包括弹幕的语义分析、通过弹幕揣摩剧情、哪种视频可以火、up主的影响力、视频质量建模等。

bilibili弹幕爬取与比对分析

最近受人之托研究了下b站的数据爬取做个小工具，最后朋友说不需要了，本着开源共享的原则，将研究成果与大家分享一波，话不多说直接上干货

需求分析

给定up主uid和用户uid，爬取用户在该up主所有视频中发的所有弹幕

需求拆解

获取up主所有视频

打开b站，随便搜索一个up主，打开所有视频页面，f12看异步请求就一目了然了

接口地址:https://space.bilibili.com/ajax/member/getSubmitVideos?mid=up主的uid&pagesize=30&tid=0&page=1&keyword=&

直接通过GET请求访问，该接口限制pagesize为100，数目超过就会返回错误，但是该接口会返回一个总数与页数，所以我们首先请求一次，获取相关参数再分批次请求，获取到数据后对vlist进行json数据解析就可以，我们主要获取的是aid，也就是av号

?

获取视频所有弹幕

使用firefox浏览器打开视频，f12后搜索list.so请求会发现弹幕xml文件，同样也是GET请求

接口地址:https://api.bilibili.com/x/v1/dm/list.so?oid=112062851  http://comment.bilibili.com/cid..xml

但是在百度的过程中发现了一个直接读取xml文件的地址，更加方便

接口地址：http://comment.bilibili.com/cid.xml

这个cid就是弹幕xml的文件编号，通过分析异步请求，发现了返回这个cid的返回接口

接口地址：https://api.bilibili.com/x/player/pagelist?aid=视频av号&jsonp=jsonp

?

需要注意的是返回的是一个数组，这说明如果视频弹幕过多的话可能有多个xml文件，我们需要遍历获取

弹幕xml文件分析

文件格式内容如下所示

?

可以看到里面d标签的文字内容就是发送的弹幕，但是我们还需要对弹幕的发送者与我们给定的用户进行对比，所以需要对d标签的属性p进行分析，p属性使用逗号隔开的一系列数据，其中各个参数属性如下

<d p=”弹幕出现时间,模式,字体大小,颜色,发送时间戳,弹幕池,用户Hash,数据库ID”>123123</d>

我们只需要获取里面的第7个参数用户的唯一标识即可

难点分析

用户id转换

在弹幕xml文件中获取的用户标识是用户uid经过hash后的编码，所以我们需要进行转换后才能对比校验，经过使用在线hash网站中的一个个hash函数尝试比对，发现hash算法为crc32b，crc32是一个常见算法，用于文件校验，但是crc32b百度了一圈也搜索不到是个啥东西，无奈出国google了一下，crc32b只是将crc32算法加密后的结果转换成了16进制，下面提供c#实现的功能函数

        /// <summary>
        /// CRC32校验算法
        /// </summary>
        protected static ulong[] Crc32Table;
        //生成CRC32码表
        public static void GetCRC32Table()
        
            ulong Crc;
            Crc32Table = new ulong[256];
            int i, j;
            for (i = 0; i < 256; i++)
            
                Crc = (ulong)i;
                for (j = 8; j > 0; j--)
                
                    if ((Crc & 1) == 1)
                        Crc = (Crc >> 1) ^ 0xEDB88320;
                    else
                        Crc >>= 1;
                
                Crc32Table[i] = Crc;
            
        
        //获取字符串的CRC32校验值
        public static ulong GetCRC32Str(string sInputString)
        
            //生成码表
            GetCRC32Table();
            byte[] buffer = System.Text.ASCIIEncoding.ASCII.GetBytes(sInputString); ulong value = 0xffffffff;
            int len = buffer.Length;
            for (int i = 0; i < len; i++)
            
                value = (value >> 8) ^ Crc32Table[(value & 0xFF) ^ buffer[i]];
            
            return value ^ 0xffffffff;
        

        public static string GetCRC32bStr(string sInputString)
        
            return GetCRC32Str(sInputString).ToString("x");
        

通过代码GET请求保存xml文件

在保存xml文件的过程中发现输出流转为文字永远是乱码，经过查看请求网页中header中的值，发现返回的xml数据流是压缩格式的

?

所以我们对GET请求的方法进行了一些设置，首先Accept-Encoding需要与真正的访问请求保持一致，然后设置自动解压，下面提供c#示例

        public static String HttpGet_BiliBiliXmlFile(string Url)
        
            HttpWebRequest request = (HttpWebRequest)WebRequest.Create(Url);
            request.Method = "GET";
            request.ContentType = "text/html;charset=UTF-8";
            request.Headers[HttpRequestHeader.AcceptEncoding] = "gzip, deflate, br";
            request.Headers[HttpRequestHeader.AcceptLanguage] = "zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2";
            //自动解压
            request.AutomaticDecompression = DecompressionMethods.GZip | DecompressionMethods.Deflate; 
            HttpWebResponse response = (HttpWebResponse)request.GetResponse();
            Stream myResponseStream = response.GetResponseStream();
            StreamReader myStreamReader = new StreamReader(myResponseStream, Encoding.UTF8);
            string retString = myStreamReader.ReadToEnd();
            myStreamReader.Close();
            myResponseStream.Close();

            return retString;
        

功能到这里就全部分析完毕了，最后打个广告，自己写的ASP.NET MVC快速开发框架，希望支持一波

地址：https://gitee.com/grassprogramming/FastExecutor