瓜海鸣潮唤今汐。
视听瑝珑寻龙影。
频频保底泪湿衣！
== 哈哈，看过道友上篇文章，这回我可懂了！不过这次为何不能提这四字灵兽了，之前不是有篇文章直接说出它的真名了吗？？
=> 不，你不懂我的悲伤 ╥﹏╥...… 哎，话说回来，本次斗法之后我有点小担心，因为它越来越强了，所以这次不能让它知道我已知晓了它的招式弱点。
=# 等等，我新来的，还不晓得这 苦瓜视频 是何意呢？
== 哎~不要被标题误导啦，你把每行诗开头第一字连起来看看就好了，记得千万不要说出那四个字，其它的就不要问了。好啦好啦，道友快开始吧。
=> 真是急性子呐，给，这是本文结构。
[ol]
[/ol]
惊闻灵兽进阶
被困二次元小世界数十年，近日侥幸脱困（指四月番完结），突然收到其它道友的消息，称某灵兽度过天劫、已踏入 二阶 境界（指网站使用了更为严格的反爬策略）。
重要说明
因为赶时间（瓜海鸣潮啦！）所以没有详细讲解分析过程，仅记录关键的步骤。
另外，我建议大家不要盯着电脑端的网页版了，现在的反爬策略已经有些强度，建议大家转向手机网页版或者其它的解析源等等。
以后我可能不会紧跟着网站的变动而更新了，因为我关注的 UP 去了 B 站……我也要再次探索二次元小世界了（七月番即将启动！）。
下载链接的变动
简要说明
[ol]
[/ol]
关于链接的改动看图！
image-20240629232030282.png (1.72 MB, 下载次数: 0)
下载附件
2024-7-1 01:08 上传
再经过测试，确定目前（指发文的此刻）只需要 webid 、并且它不能随意修改。
image-20240701002333757.png (112.07 KB, 下载次数: 0)
下载附件
2024-7-1 01:08 上传
webid 的第一个部分
首先，webid 分为两部分，通过符号 - 分割，如：A-B 这种形式。
第一个部分可以从视频播放页，如 https://www.ixigua.com/7383684722985009699?wid_try=1 中提取，它就是 window['UIFID'] 属性或者 window['UIFID_TEMP]' 属性的值啦。
image-20240629235314758.png (289.14 KB, 下载次数: 0)
下载附件
2024-7-1 01:08 上传
虽然 webid 的第一个部分位于视频播放页的 HTML 中，但想要获取它最初需要访问两次。
import requests
# 需要保留 cookie
CLIENT = requests.Session()
# 这内容太长，所以省略了
headers = {}
url = "https://www.ixigua.com/7383684722985009699"
params = {"wid_try": "1"}
# 第一次访问是为了获取服务器设置的 `cookie`
# 此时返回的是一个主要包含 JS 代码的 HTML，这些 JS 会生成一个 cookie 用于第二次请求。
# 现在可忽略第一次请求的内容，因为不影响后续的操作
response = CLIENT.get(url, headers=headers, params=params)
# 第二次访问可以获取到视频播放页的内容了
response = CLIENT.get(url, headers=headers, params=params)
# 之后就可以访问其它视频播放页，只要获取到视频页的内容，就可以提取出 UIFID 咯
# 另外，这个 UIFID 似乎是固定的…………不需要重复获取
webid 的第二个部分
// webid 的第二个部分的生成逻辑
s = webid 第一个部分的值 + 第一次处理后的链接中的 expired 值 + 'bytedance';
result = md5(s)
如图所示！红色中的结果是相同的，证实了上述的公式。
image-20240630184657375.png (273.33 KB, 下载次数: 0)
下载附件
2024-7-1 01:08 上传
怎么找到的呢？根据 webid 第二个部分（包括后面的 fid、wid）的长度是 32 位，判断它是 md5 处理，搜索全局搜索 md5 算法的关键值 1732584193（不做过多解释，具体请必应搜索），最终定位到位置！
为了便于测试，我会将 window.UIFID 的值（也就是 webid 第一部分的值）替换成 123456，这样找的时候能快速发现相关的线索。
可以通过全局搜索 return new e(t).finalize(n) 快速定位到这个位置！
image-20240630192026448.png (105.14 KB, 下载次数: 0)
下载附件
2024-7-1 01:08 上传
番外
因为以后我可能不会更新了，所以还是将 wid、fid 的生成逻辑说明吧，现在没有校验不代表以后不会，下面就更加迅猛了。
还是建议不要盯着电脑的网页版了。
wid 的生成逻辑
如图所示：
最开始的 webid （也就是下图标号 1 处）来自于视频播放页的 HTML 中哟。也就是说它和 window['UIFID'] 在同一个 HTML 文档中啦。
image-20240630191608217.png (205.07 KB, 下载次数: 0)
下载附件
2024-7-1 01:08 上传
fid 的生成逻辑
// 可以为任意的内容，只要满足 32 位长度、16 进制数组成即可
如图所示：
image-20240630234251323.png (258.57 KB, 下载次数: 0)
下载附件
2024-7-1 01:08 上传
那么上述的 cookie fpk1 是怎么生成的呢？其实它是在计算浏览器指纹。既然如此 fid 的值就可以任意改了！
image-20240701001529216.png (235.69 KB, 下载次数: 0)
下载附件
2024-7-1 01:08 上传
end
