Closed n0099 closed 1 year ago
TL;DR:
这对于以r/datahoarder为代表的 https://archiveteam.org 人们是重大利好,现在又可以回到19年3月b吧事件之前那样递归备份总主题帖量<100k
的特定贴吧中的绝大多数主题帖回复贴楼中楼了
但出于 https://en.wikipedia.org/wiki/Digital_preservation 目的为了避免客户端接口
特有pre/postfilter策略的影响,应该使用3大网页端接口
之一再爬一遍前100k条主题帖的tid,然后再用客户端接口
爬主题帖回复贴列表
和回复贴楼中楼列表
而对于总主题帖量>100k
的吧,在找到任何其他能够绕过针对吧首页主题帖列表
的主题帖数量限制的获取吧内tid
接口前,我能想到的只有使用1k个国外代理ip按照10rps限速使用主题帖回复贴列表
客户端接口rn=2
(不能通过rn=1
只获取1L,因为[1] [2])从tid1(百度员工yujie
于mp3吧
:1)一直爬到目前的tid83.5亿左右,从而获取百度贴吧所有主题帖的元数据,其自然也就包括了fid-tid
pair,这可谓是典型的 https://en.wikipedia.org/wiki/German_tank_problem
https://www.reddit.com/r/DataHoarder/comments/oomv6u/comment/h6079pv/
https://wiki.archiveteam.org/index.php/imgur#How_to_help_if_you_have_lists_of_URLs
https://wiki.archiveteam.org/index.php/URLs
而这正如同2020年1~3月间我和 @BANKA2017 合作通过「当时我google检索tieba域时偶然发现的移动端网页端
遗留举报回复贴接口 https://tieba.baidu.com/mo/q/postreport?pid=1 可以绕过任何对pid软删除(比如吧务删帖
系统吞贴
,但作者被系统永封
没试过)的检测,从而形成404空洞极少的连续pid分布」,基于当时tbm数据集中所得出的爬到的04\~19年每天的最小(第一条)pid和最大(最后一条)pid,使用带标准差偏移的正态分布曲线试图拟合出每日贴吧发贴量波峰波谷(晚上=中午>下午>凌晨),从每日pid空间中使用该分布随机选取20000个pid进行爬取,最终获得的110m个pid-吧名-作者百度用户名
pair数据集:https://n0099-my.sharepoint.cn/:f:/g/personal/n_n0099_partner_onmschina_cn/EtP8LpKT869LnK409s9xMdQBeJgxKk93sM-hWUvMQIZLKA
很有意思,但我也得过一会才能研究
可追溯的历史帖数量确实大大增加了,不过貌似对我没什么影响
可得starry神不在乎简中互联网有没有记忆
rt 当时是缩小到了20k主题帖 好像是几个月后又进一步缩小到了10k https://github.com/n0099/TiebaMonitor/blob/981fc6d3d077f3ba6a79f27e1b2e245f46492335/c%23/crawler/src/Worker/ArchiveCrawlWorker.cs#L10-L12
这个限制在当时是应用于所有能显示
吧首页
的接口,包括网页端 客户端c/f/frs/page
wap网页端( https://community.wvbtech.com/d/1805 ) 移动端网页端 如果对这些接口请求的 $pn>limit$ (对于客户端接口
是 $pn>limit*rn\text{(每页数量参数)}$ 因为只有客户端接口
的pn参数
是真的指页数,也就是 $客户端pn=rn*网页端pn$ 而网页端pn
实际上是指SQL OFFSET),那么贴吧服务端只会返回pn=1
的主题帖而刚才我又试了下发现不知何时起他们又改成了100k条主题帖(网页端参数
rn=50&pn=100000
) 以有着共有主题数14534787个,贴子数 993077918篇 众人皆帝数33828556
的李毅吧为例:而客户端(基于 https://github.com/n0099/TiebaMonitor/blob/e7d7240aebeee74d04f7b5d4748af69dff3ed5b0/client_tester.php#L30 )不是简单的增加到100k,而是
客户端接口
特色之根据提供参数和client_version
取值排列组合而不同: 对于有些(知名贴吧?(已经死了的)核心区?热门分区
排序?)贴吧,client_version>=8.0.0(.0)
时限制是12k条,而client_version<8.0.0(.0)
或其他普通的贴吧(即便有着大量历史主题帖)时没有限制 已经试过用于避免热门分区
的sort=5
但没有效果还注意到只有
客户端接口
的返回的主题帖列表
跟其他3个网页端接口
不同(但发帖时间都是2021-05-12
),这说明3个网页端接口
后端至少在分页逻辑上是一致的,而客户端接口
后端做了额外的分页前prefilter(比如前几年搞的客户端投票贴
在网页端不显示,遗留的基于flash的网页端投票贴
在客户端不显示)以于2004年建吧有着46852条主题帖(因此可以翻到最后的937页之
rn=50&pn=46800
)的模拟城市吧为例: 网页端的第937页: 客户端的第937页(可见甚至没有返回够50条主题帖,说明除了prefilter还存在着应用于分页后的postfilter):