一、案例背景与采集目标
打开 B 站的排行榜页,一屏就是几十条视频,每条写着标题、UP 主、分区、播放量、弹幕数和点赞数。它是「此刻全站最火的视频」的一张快照,看着简单,信息量却很大:哪些分区在热、哪类内容吃香、哪位 UP 主又上榜了,扫一眼就能看出来。
它和我们上一案例采过的热搜榜是同一类东西——随时间变化的榜单;区别在于 B 站的字段更硬:数字多、单位杂,而且这个站点额外提供了一条公开的数据接口。这一案例就把「榜单的两条取数路径」都走一遍。
1.1 这一篇用哪些真实站点
示范站点有两个入口,指向同一张榜:一是B 站全站排行榜网页,地址 https://www.bilibili.com/v/popular/rank/all;二是 B 站自己对外提供的排行榜公开接口,地址 https://api.bilibili.com/x/web-interface/ranking/v2?rid=0&type=all,返回的是一段 JSON。两个入口都已实测可直接访问,不用登录。
延伸站点用于横向对照,都是公开榜单:微博热搜榜 https://s.weibo.com/top/summary、百度热搜榜 https://top.baidu.com/board?tab=realtime、知乎热榜 https://www.zhihu.com/hot,以及抖音热榜。它们的字段与 B 站不同,只做结构对照,不并表。
1.2 这个案例要拿到什么
- 榜单每条视频的排名、BV 号、标题、UP 主、分区;
- 六个互动数字:播放量、弹幕数、点赞数、投币数、收藏数、转发数;
- 把时长从秒换算成「分:秒」,把发布时间从时间戳换成本地时间;
- 每条都打上采集时刻,因为这张榜每小时都在变;
- 按分区与 UP 主分别汇总,看「谁在热」与「什么内容在热」。
1.3 为什么值得走一遍公开接口
| 对比项 | 采网页榜单 | 请求公开接口 |
|---|---|---|
| 打开方式 | 要驱动浏览器渲染页面 | 直接返回一段 JSON |
| 字段 | 页面上显示多少就是多少 | 比页面多出 aid、cid、封面图、历史最高名次等 |
| 单位 | 播放量常写成「1.2亿」「715.3万」 | 直接给整数,省去换算 |
| 稳定性 | 页面一改版就要重新适配 | 字段名相对固定,改动更少 |
| 请求门槛 | 无 | 要带浏览器的 User-Agent,不带会被判为异常请求(返回 -352) |
一句话:有公开接口的站点,优先走接口。接口给的是结构化数据,字段全、单位干净,还不用跟页面样式较劲。但有两条纪律必须守:一是带上它要求的请求头,二是控制频率,别把公开接口当成免费提款机。
1.4 这个案例真正的难点在哪
采到数据不难,难在把数字摆正。具体有五个坑:第一,接口要带浏览器的 User-Agent,不带时直接返回 -352 拿不到数据;保持浏览器默认请求头即可,不需要额外加 Referer 之类的头;第二,这个接口还有频率风控,短时间内连着请求几次,同样会被 -352 拦下,所以必须放慢节奏;第三,单位对不上,页面上写「1.2亿」,接口给 120000000,两者要能对上;第四,时长是秒、发布时间是时间戳,都不能直接读;第五,榜单每小时变,不记采集时刻,两次结果就没法比较。
1.5 这张榜单能回答什么问题
- 分区格局:今天哪些分区上榜最多,是动画区还是知识区;
- UP 主产能:一位 UP 主在榜上占了几条,是偶然爆款还是稳定输出;
- 内容形态:上榜视频普遍多长,是十几秒的短视频还是五十分钟的长片;
- 互动质量:播放量高不等于互动好,用点赞、投币、收藏与播放量的比值能看出差别。
目标站点与交付产物
下表是本篇用到的真实站点。绿色是课堂可稳定复现的示范站点;橙色是延伸站点,多数有登录墙或风控,课堂上只讲结构、原理与合规边界,不教绕过。
| 项目 | 内容 |
|---|---|
| 示范站点 | 哔哩哔哩(B 站)全站排行榜 https://www.bilibili.com/v/popular/rank/all 榜单页 + 公开接口双通道;接口 https://api.bilibili.com/x/web-interface/ranking/v2?rid=0&type=all 返回 JSON(实测榜单 100 条),但必须带浏览器的 User-Agent,不带会返回 -352;接口另有频率风控,连着请求同样被拦;榜单每小时刷新 |
| 延伸站点 |
|
| 交付产物 |
|
| 难度 | ★★☆ 中 |
| 合规提示 | 只采平台公开榜单的元数据;不下载视频文件、不采集用户隐私;接口请求间隔 ≥1 秒,控制频率,不做高频轮询。 |
二、数据源与字段设计
数据源有两个入口:B 站全站排行榜网页(给人看的)和排行榜公开接口(给机器读的)。本案例以接口为主、页面为辅——接口拿全字段,页面用来核对数字对不对得上。
2.1 站点信息表
| 站点全称 | 网址 | 页面形态与接口 | 规模与角色 |
|---|---|---|---|
| B 站 · 全站排行榜(网页) | https://www.bilibili.com/v/popular/rank/all | 公开排行榜页,含排名 / 标题 / UP 主 / 播放量 / 弹幕数 / 点赞数 | 榜单约 100 条,另设各分区排行榜;不用登录 |
| B 站 · 排行榜公开接口 | https://api.bilibili.com/x/web-interface/ranking/v2?rid=0&type=all | 返回 JSON,data.list 是榜单数组,元素含 bvid / stat / owner / duration 等 | 同一次返回约 100 条,字段比页面更全;rid=0 表示全站榜 |
| 微博热搜榜(对照) | https://s.weibo.com/top/summary | 榜单页,字段为排名 / 话题 / 热度值 | 只做结构对照,字段与 B 站不同,不并表 |
| 百度热搜榜(对照) | https://top.baidu.com/board?tab=realtime | 静态榜单页,结构稳定 | 可作兜底站点,热度含「万」写法 |
| 知乎热榜(对照) | https://www.zhihu.com/hot | 页面及接口返回含标题与热度 | 有登录墙,只讲结构,不作为示范站点 |
2.2 接口字段对照表:JSON 的位置归到统一字段
接口把数据分层放在嵌套结构里,取值要一层层点进去。先把「接口里的位置」与「统一字段」的对应关系写成一张表,交给 AI 它就不会取空。
| 接口里的位置 | 含义 | 统一成的字段 | 备注 |
|---|---|---|---|
data.list[].bvid | 视频唯一编号 | BV 号 | 拼视频链接要用它 |
data.list[].title | 视频标题 | 标题 | 保持原文 |
data.list[].owner.name | 上传者昵称 | UP 主 | 嵌套在 owner 里 |
data.list[].owner.mid | 上传者数字号 | UP 主 ID | 统计「UP 主产能」时用它分组 |
data.list[].tname | 所属分区名 | 分区 | 比分区编号 tid 好认 |
data.list[].stat.view | 播放次数 | 播放量 | 整数 |
data.list[].stat.danmaku | 弹幕条数 | 弹幕数 | 整数 |
data.list[].stat.like | 点赞数 | 点赞数 | 整数 |
data.list[].stat.coin | 投币数 | 投币数 | 整数 |
data.list[].stat.favorite | 收藏数 | 收藏数 | 整数 |
data.list[].stat.share | 转发数 | 转发数 | 整数 |
data.list[].duration | 时长(秒) | 视频时长(秒) | 要换算成「分:秒」 |
data.list[].pubdate | 发布时间(Unix 时间戳) | 发布时间 | 要换算成本地时间 |
data.list[].pic | 封面图地址 | 封面图链接 | 只记地址,不下载图片 |
2.3 完整字段表
| 字段名 | 字段含义 | 示例值 | 口径与备注 |
|---|---|---|---|
排名 | 在榜上的名次 | 1 | 接口按 data.list 的顺序返回,第 1 条即第 1 名;页面上的名次应与它一致 |
BV 号 | 视频的唯一编号 | BV1c3HL6qEyq | 接口字段 bvid,拼视频链接要用它 |
标题 | 视频标题 | 《诡异的她》第一季全集·纯享 | 接口字段 title,保持原文,不改写 |
UP 主 | 上传者昵称 | 编剧六一 | 接口 owner.name |
UP 主 ID | 上传者数字号 | 95272526 | 接口 owner.mid,做「UP 主产能」统计时用它分组 |
分区 | 视频所属分区 | 影视剪辑 | 接口 tname;分区名比编号 tid 好认 |
播放量 | 累计播放次数 | 7152912 | 接口 stat.view,是整数 |
弹幕数 | 累计弹幕条数 | 14345 | 接口 stat.danmaku |
点赞数 | 点赞数 | 352038 | 接口 stat.like |
投币数 | 投币数 | 175645 | 接口 stat.coin,B 站特色字段 |
收藏数 | 收藏数 | 224398 | 接口 stat.favorite |
转发数 | 分享数 | 57558 | 接口 stat.share |
评论数 | 评论条数 | 12917 | 接口 stat.reply |
视频时长(秒) | 时长,单位是秒 | 2950 | 接口 duration,注意是秒不是分 |
视频时长 | 换算后的时长 | 49:10 | 由秒换算,便于阅读与比较 |
发布时间 | 视频发布时间 | 2026-10-04 19:30 | 接口 pubdate 是 Unix 时间戳(秒),要换算 |
视频链接 | 视频地址 | https://www.bilibili.com/video/BV1c3HL6qEyq | 由 BV 号拼接 |
封面图链接 | 封面图地址 | http://i2.hdslb.com/bfs/archive/….jpg | 只记地址,不下载图片 |
榜单类型 | 全站榜 / 分区榜 | 全站榜 | 接口用 rid 区分,rid=0 为全站榜 |
采集时刻 | 本次采集的时刻 | 2026-10-08 09:00 | 榜单每小时变,必须记录 |
2.4 单位与格式换算规则(这一节的重头戏)
接口给的多半是干净的数字,但网页上不是。两条路一对照,就必须有一套换算规则把它们对齐。
| 原始写法 / 原始值 | 含义 | 换算结果 | 说明 |
|---|---|---|---|
1.2亿 | 页面上播放量的写法 | 120000000 | 亿 = 100000000 |
715.3万 | 页面上播放量的写法 | 7153000 | 万 = 10000;页面做了四舍五入,接口给的是精确整数 7152912,两者会差一点 |
2950(秒) | 接口给的时长 | 49:10 | 2950 秒 = 49 分 10 秒 |
59(秒) | 不足一分钟的时长 | 00:59 | 要补前导零,写成 00:59 而不是 0:59 |
1791113400 | 接口给的发布时间 | 2026-10-04 19:30 | Unix 时间戳(秒)换算成本地时间 |
把接口返回的一条记录单独拎出来看,就明白字段都藏在哪一层了:
{
"code": 0,
"message": "OK",
"data": {
"note": "根据稿件内容质量、近期的数据综合展示,动态更新",
"list": [
{
"bvid": "BV1c3HL6qEyq",
"title": "《诡异的她》第一季全集·纯享",
"tname": "影视剪辑",
"duration": 2950,
"pubdate": 1791113400,
"owner": { "mid": 95272526, "name": "编剧六一" },
"stat": { "view": 7152912, "danmaku": 14345, "like": 352038,
"coin": 175645, "favorite": 224398, "share": 57558, "reply": 12917 }
}
]
}
}
AI 助手小贴士|接口的字段藏在 owner、stat 这些嵌套结构里,直接取外层会拿到空值。让 AI 先把一条记录的完整结构打印给你看,确认字段路径再批量取。
打开 WorkBuddy 或任意 AI 对话工具,试试这样问:请先请求这个接口,只取第 1 条记录,把它完整的字段结构(包括 owner 和 stat 里面的每一项)列给我看,先不要取全部。
课程思政|数据安全与法治素养 · 公开接口也有使用规矩
接口是公开的,不等于可以随便抓。控制频率、带上规范的请求头、只取榜单这类公开数据、不下载视频文件——这些都是使用公开数据的基本礼仪。技术上的「能」,不能替代规则上的「该」。
三、零代码操作步骤
工具与技能|先看清三个角色,再动手
本篇全程零代码:你把要求说清楚,AI 去执行,你负责验收。三个角色分工如下——浏览器技能指的是腾讯开源的 BrowserSkill,它能让 AI 直接操作你电脑上真实的浏览器(可复用已经登录的状态),自己开一个独立窗口干活,不打扰你正在看的网页;遇到验证码、登录或确认弹窗,它会停下来交给你本人处理。
| 角色 | 负责什么 | 在本案例里具体做什么 |
|---|---|---|
| 你 | 确认字段清单、验收结果、清洗与合规把关 | 盯字段清单、核对结果、处理异常(如验证码) |
| WorkBuddy | 接中文指令:探字段 → 批量采 → 清洗 → 导出交付物 | 拆解本篇的采集任务并跑完全量、产出交付物 |
| 浏览器技能 BrowserSkill | 以真实浏览器打开页面:跑脚本渲染、滚动 / 翻页 / 点开详情、截图留证;可复用本机浏览器已登录状态,遇到验证码或登录弹窗会停下来交给你处理 | 打开排行榜网页与公开接口,对照两边的字段 |
五步操作主线(全课程统一,每一篇都按这个顺序推进):
- 定目标与字段:先看本篇第二节的字段表,把「要哪几列、每列什么口径、要多少条」说清楚——字段清单就是验收标准,说不清就会拿回一张字段乱七八糟的表。
- 现场踩点(浏览器技能 BrowserSkill):先打开
https://www.bilibili.com/v/popular/rank/all看榜单长什么样,再看接口返回的 JSON 有哪些字段。 - 小样试采(WorkBuddy):只取第 1 条记录探字段(重点看 owner 与 stat 里面有什么),再放开。
- 核对与清洗:① 请求有没有带浏览器的 User-Agent、两次请求之间有没有留间隔;② 播放、弹幕、点赞、投币、收藏是不是都取到;③ 时间戳有没有转成可读日期。
- 导出与归档:导出交付物(数据明细表 / 可筛选明细页 / 数据看板 / 可复用的技能包),文件名带上采集日期,并写清数据来源、采集时间与已知局限。
用浏览器技能 BrowserSkill 打开 https://www.bilibili.com/v/popular/rank/all(哔哩哔哩(B 站)全站排行榜),把这一页每条记录能采到的字段名和示例值列出来,先不要采集。下面是在 WorkBuddy 里完成本案例的流程。你依然不写一行代码,但要负责说清要求、核对结果。
- 先确认两个入口都能打开。让人先访问网页 https://www.bilibili.com/v/popular/rank/all 看一眼榜单长什么样,再请求接口
https://api.bilibili.com/x/web-interface/ranking/v2?rid=0&type=all。 - 先探字段。要求只取第 1 条记录,把它完整的字段结构列出来(重点看 owner 与 stat 里面有什么),先不要取全部。
- 说清请求头与节奏。明确告诉它「请求这个接口要带浏览器的 User-Agent,并且两次请求之间留出间隔」。
- 先取 10 条做小样本。按字段表取前 10 条的排名、BV 号、标题、UP 主、分区与六个互动数字,看字段齐不齐。
- 做两次换算。说「把时长从秒换算成 分:秒,把发布时间从时间戳换算成 YYYY-MM-DD HH:MM」。
- 补上视频链接与封面。说「用 BV 号拼出视频链接 https://www.bilibili.com/video/ 加 BV 号,封面图只记地址不下载」。
- 记采集时刻。要求整批结果新增一列「采集时刻」,填同一个时间点。
- 放开全量并导出。小样本核对无误后取全站榜全部约 100 条,导出 Excel;有余力再换个 rid 取一个分区榜做对照。
四、提示词模板与追问技巧
下面这段可以直接复制。它的关键是把两个入口、请求头、字段路径、换算规则、采集时刻这几件事一次说清。
请帮我采集 B 站全站排行榜。
【两个入口,指向同一张榜】
网页:https://www.bilibili.com/v/popular/rank/all
公开接口:https://api.bilibili.com/x/web-interface/ranking/v2?rid=0&type=all
优先用接口取数,网页只用来核对数字。
【接口的注意事项】
- 请求头带浏览器的 User-Agent;两次请求之间留出间隔,不要连着发(会被 -352 拦);
- 请求之间间隔 1 秒以上,不要并发;
- 如果一次拿不全,明确告诉我实际拿到了多少条。
【需要字段】按这个顺序(共 16 个):
1. 排名(接口 data.list 的顺序,第 1 条即第 1 名)
2. BV 号(bvid) 3. 标题(title)
4. UP 主(owner.name) 5. UP 主 ID(owner.mid)
6. 分区(tname) 7. 播放量(stat.view)
8. 弹幕数(stat.danmaku) 9. 点赞数(stat.like)
10. 投币数(stat.coin) 11. 收藏数(stat.favorite)
12. 转发数(stat.share) 13. 评论数(stat.reply)
14. 视频时长(秒,duration) 15. 发布时间(pubdate,Unix 时间戳)
16. 视频链接(用 BV 号拼:https://www.bilibili.com/video/ 加 BV 号)
【换算要求】
- 视频时长:秒 换成 分:秒,例如 2950 换成 49:10,59 换成 00:59;
- 发布时间:Unix 时间戳 换成 YYYY-MM-DD HH:MM;
- 播放量、点赞等数字保持接口给的整数,不要四舍五入。
【输出要求】
1. 先在对话里给我前 10 条的预览,我确认后再导出全部;
2. 文件名 bili_rank_20261008_09.xlsx;
3. 整批新增一列「采集时刻」,填同一个时间(如 2026-10-08 09:00)。
【合规要求】只取公开榜单,不下载视频文件、不下载封面图片,控制频率。
4.1 三条常用追问指令
追问一(补分区榜):
请把接口里的 rid 改成某个分区的编号,再取一次那个分区的排行榜,
新增一列「榜单类型」区分全站榜与分区榜,最后把两张榜合并成一张表。
追问二(按 UP 主汇总):
请按 UP 主分组,统计每位 UP 主在榜上占了几条、总播放量和平均点赞数,
从多到少排列。
追问三(两期对比):
这是我隔一小时再采的榜单。请按 BV 号对齐两期数据,
找出新上榜、掉榜,以及播放量增长最快的 5 条视频。
AI 助手小贴士|「先预览 10 条再全量」这一条一定要写进提示词。接口字段多,第一次取数很容易在某个嵌套层上取空,先小样本确认能省下反复返工的时间。
打开 WorkBuddy 或任意 AI 对话工具,试试这样问:请先只取前 10 条,按字段表给我预览,特别确认 UP 主、分区、投币数这几列有没有取到,我确认后你再取全部。
五、结果核对、清洗与保存
先看接口取回的结果样例(示例数据:条目为教学示意,非真实榜单;字段形态与真实返回一致):
| 排名 | BV 号 | 标题 | UP 主 | 分区 | 播放量 | 弹幕数 | 点赞数 | 收藏数 | 视频时长 | 采集时刻 |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | BV1c3HL6qEyq | 《诡异的她》第一季全集·纯享 | 编剧六一 | 影视剪辑 | 7152912 | 14345 | 352038 | 224398 | 49:10 | 2026-10-08 09:00 |
| 2 | BV1Uppw6yEMr | 啊啊7月新番你到底给我下了什么药啊!!【泛式】 | 泛式 | 动漫杂谈 | 1891580 | 9480 | 227286 | 62515 | 16:02 | 2026-10-08 09:00 |
| 3 | BV1YtHs62EHZ | 被 解 救 的 杰 戈 | 蔚蓝丶羽翼 | 鬼畜剧场 | 2387716 | 2192 | 163476 | 37989 | 7:13 | 2026-10-08 09:00 |
5.1 五项核对
- 条数:接口实际返回多少条,是不是接近 100,有没有中途被限流截断;
- 字段:UP 主、分区、投币数这几列最容易取空,逐一抽查;
- 换算:抽一条把时长秒数自己换一遍,看与「分:秒」列对不对得上;
- 发布时间:时间戳换算出来的日期合不合理,是不是落在最近几天;
- 采集时刻:整批是不是同一个时刻,别混进别的批次。
5.2 清洗指令,直接复制
请对本次榜单结果做以下清洗:
① 去掉标题的首尾空格与多余的换行;
② 视频时长统一成「分:秒」,不足 1 分钟的补前导零(如 00:59);
③ 发布时间统一成 YYYY-MM-DD HH:MM;
④ 播放量、弹幕、点赞、投币、收藏、转发、评论这几列保持整数,不要加千分位;
⑤ 新增一列「互动率」= 点赞数 除以 播放量,保留两位小数;
⑥ 新增一列「时长区间」:短(不超过 1 分钟)/ 中(1 到 10 分钟)/ 长(超过 10 分钟);
⑦ 按排名升序排列。
5.3 保存与归档约定
bili_rank_20261008_09.xlsx ← 本次原始榜单(接口取的全字段)
bili_rank_20261008_09_clean.xlsx ← 清洗版(含换算列与互动率)
bili_rank_all.xlsx ← 累积长表:每次的快照纵向合并
bili_rank_up.xlsx ← 按 UP 主汇总的榜单
bili_rank_log.txt ← 日志:采集时刻、条数、异常
5.4 从榜单能看出什么
把「分区」和「互动率」两列配合着看,往往比只看播放量更有意思:
- 分区分布:按分区统计条数,看今天哪几个分区占了榜单大半;
- 互动质量:同样上亿的播放量,点赞率高的说明观众更愿意「动手」,只是路过看一眼的比例低;
- 时长偏好:短、中、长三类各占多少,能反映当下观众愿意花多长时间看一条视频。
AI 助手小贴士|清洗时数字列最怕被自动加上千分位逗号(7152912 变成 7,152,912),一加逗号后续就没法计算。让它把这几列明确保持为数字格式。
打开 WorkBuddy 或任意 AI 对话工具,试试这样问:请确认播放量、点赞、投币、收藏这几列是数字格式而不是文本,不要出现千分位逗号,我要用它们做计算。
课程思政|工匠精神与严谨求实 · 一个数字也要对得上
「1.2亿」写成 120000,看着只差几个零,结论却会天差地别;时长 2950 秒抄成 2950 分,更是离谱。数据工作里没有「大概差不多」,每个数字都要能说出它是怎么来的。把换算规则写清楚、把原文留着、把结果抽查一遍——这份较真,就是专业。
六、常见问题与合规红线
6.1 五个高频问题
| 现象 | 原因 | 怎么处理 |
|---|---|---|
| 接口返回空数据或报错 | 请求头里没有浏览器的 User-Agent(返回码 -352),或短时间连着请求触发了频率风控 | 在提示词里写明:请求要带浏览器的 User-Agent,两次请求之间留出间隔 |
| UP 主、分区这几列是空的 | 字段藏在 owner、stat 等嵌套结构里,只取了外层 | 让 AI 先打印一条记录的完整结构,确认字段路径 |
| 时长列变成一堆几千的数字 | 接口给的是秒,没有换算 | 按规则换成「分:秒」,不足 1 分钟补前导零 |
| 两次采集的播放量对不上 | 榜单每小时变,两次本就不同;也可能没记采集时刻 | 每次记录采集时刻,比较时按 BV 号对齐 |
| 数字列多了逗号、没法计算 | 被当成文本并加了千分位 | 明确要求保持数字格式,不加千分位 |
6.2 三条合规红线
- 只取公开榜单的元数据,不下载视频文件、不下载封面图片;视频本身受著作权保护。
- 控制频率,请求之间间隔 1 秒以上,不并发、不高频轮询;公开接口也不是免费提款机。
- 结论要留白,榜单名次受平台推荐机制影响,不能把「上榜」直接等同于「质量最好」。
另外提醒一句:「采集时刻」这一列一定不能省。榜单每小时都会变,没有这一列,两份结果放在一起就像两笔对不上的账,谁也说不清谁对谁错。
课程思政|诚信与职业操守 · 数据要真,结论才立得住
榜单反映的是真实的观看选择,正因为它真实,分析才有价值。一旦有人动手把播放量刷上去,这份数据就失去了意义。做数据的人,第一件事是尊重数据的真实性——不篡改、不编造、不为了好看的结论去挑选数字。
七、随堂自测(10 题)
点击选项即可判分,答错的题会立刻显示解析。
1B 站的排行榜公开接口,正常取数必须带上哪个请求头?
- A. User-Agent(浏览器标识)
- B. Cookie(登录凭证)
- C. Accept-Encoding
- D. Content-Type
2接口里 duration = 2950,它表示什么?
- A. 2950 毫秒
- B. 2950 秒,换算成「分:秒」是 49:10
- C. 2950 分钟
- D. 2950 帧
3页面上播放量写成「1.2亿」,还原成整数应该是?
- A. 12000
- B. 1200000
- C. 12000000
- D. 120000000
4接口返回的榜单里,名次是怎么确定的?
- A. 接口有一个单独的 rank 字段直接给出
- B. 要按播放量重新排序才能得到
- C. data.list 的顺序就是名次,第 1 条即第 1 名
- D. 必须打开网页才能知道
5为什么每次采集都要记录采集时刻?
- A. 因为榜单每小时都在变,不记时刻两次数据没法比较
- B. 因为接口强制要求
- C. 因为文件名需要时间戳
- D. 因为服务器会校验时间
6BV 号(bvid)的用处是?
- A. 它就是播放量
- B. 它是视频的唯一编号,可以用来拼视频链接
- C. 它是 UP 主的编号
- D. 它是分区编号
7页面上显示 715.3万,接口却给 7152912,最可能的原因是?
- A. 接口的数据是错的
- B. 页面的数据是错的
- C. 页面做了四舍五入,接口给的是精确整数
- D. 两边统计口径完全不同
8下面哪一项超出了本案例的合规边界?
- A. 只采榜单上的公开元数据
- B. 按小时采一次榜单
- C. 把结果用于课堂分析
- D. 把上榜视频下载下来长期保存并转发到别处
9想稳定地拿到全字段,优先级最高的做法是?
- A. 优先走站点提供的公开接口
- B. 先让浏览器截图再识别文字
- C. 把页面另存为 PDF 再解析
- D. 手工一条条抄写
10接口里 duration = 59,换算成「分:秒」应该是?
- A. 59:00
- B. 00:59
- C. 0:059
- D. 59