本来想着做完了爱奇艺的接口就可以暂时告一段落了，结果在zsaim大佬的网站中还发现了另一篇高质量的文章https://zsaim.github.io/2019/05/06/Tencent-cKey9.1-Analysis/
之前我已经实现过腾讯视频的解析，可惜苦于没有生成ckey的办法，所实现的接口即使有会员cookie，但仍然只能下载非会员视频，火力不能全开啊。
所以当我看见了这篇教程的时候，简直是如获至宝啊。虽然和那篇爱奇艺cmd5x的分析一样，没看懂。不过好在大佬仍然给了Node.js的实现方法，一样通过腾讯云函数直接以接口的形式实现，http://api.lijishi.com/release/cmd5x/
想着已经有了ckey，直接在原有接口的基础上加上就可以了，但仔细想想，还不如自己重新做一个，何必去修改那座“屎山”。
Step1
在网页端的开发者模式下，搜索M3U8，并没有得到什么有效结果，但是却发现有一堆kvcollect……的东西带有M3U8关键字，分析一下，想必在这些请求之前就已经生成了M3U8，所以就顺着时间线往前翻。
在第一条kvcollect请求之前的有一条proxyhttp的请求，请求方式为post，而且post很多很多参数，看起来非常像M3U8的请求连接，返回结果更是不负众望，直接就是非常详细的M3U8信息。
可以看到，post的参数中，有三组，分别为buid、adparam和vinfoparam
其中的buid固定为vinfoad，可以忽略不计，而另外两个就要好好分析了。
adparam中，有太多的参数了，但仔细分析分析，变化的没几个，只有url、coverid、vid、flowid、uid、tkn、opid、atkn、appid、rfid这几个。
- 其中，url、coverid和vid都是和所解析的视频息息相关，但获取并不难，一样是直接在网页中搜索就能得到，几乎可以忽略不计。
- 此外，通过和cookie的对比，可以发现，uid对应vqq_vuserid，tkn对应vqq_vusession，opid对应vqq_openid，atkn对应vqq_access_token，appid对应vqq_appid。
- 至于rfid，通过多次刷新可以发现，不过就是一串固定的字符8fbfbb360af08628d01a2f8cfc05149f_，加上时间戳而已。
- flowid倒真是费了我一番功夫，到头来才发现，就是一个随机数，加上_10201（platform）而已，气得我口吐芬芳啊。
分析完adparam再分析vinfoparam，才发现我刚才真是天真了，这个的参数更多。
不过再仔细分析一波就会发现，套用我同事的口头禅，啥也不是！
同样是变化的参数没几个，guid、flowid、ehost、tm、logintoken、unid、vid、defn、ckey
- 发现了吗，flowid已经有了，ehost和vid都是视频链接中可得的，tm更是不用说了。
- 剩下的guid和unid，通过多次尝试可知，同样为固定值不变，分别为f43616973df5c7173b04c5570b550e53和2b719ec2136e11eb981ca0429186d00a
- 而logintoken是被url编码过的，通过解码，发现就是cookie的全部。
- defn其实更熟悉，第一次尝试解析的时候就已经知道了，代表着清晰度，可选项为sd、hd、shd和fhd，分别对应270P、480P、720P和1080P。
- 最后的参数ckey也是我们已知的，根据大佬的教程，传入platform、version、vid、guid和tm，通过js计算，即可得到正确的ckey
至此，所有的参数我们都集齐了，可以召唤神龙了！
通过python的request调用，携带cookies和headers，即可得到M3U8链接。
PS：腾讯还真良心，一条视频配四五条链接，实测发现得到的视频都一样，应该是为了备份，随便选哪个都行。
Step2
和之前实现的爱奇艺解析一样，本来到这是应该结束的，但cookie的问题依然困扰着我。之前的初代解析就是因为cookie过期的太快，几乎等同于没实现，毕竟很难应用于实际。所以二代解析我考虑和爱奇艺一样，实现最大化的cookie同步自动化。
其实在之前的参数搜寻中也能发现，就那么几个cookie的参数反复被使用，而且其中有几个几乎不变。经过反复实现，才发现变化的就一个vqq_vusession，而且这玩意令人发指，有效期6600s（应该是），也就是不到俩小时，这要是不自动化，这接口等于又废了。
不过反过来一想，这参数过期的这么快，腾讯也要有更新的方法吧，而且应该是在获取M3U8之前就要更新，所以在M3U8获取之前的请求都有可能是更新cookie的请求。
还真别说，腾讯够良心，请求命名auth_refresh，中学水平，给一个大大的赞。
看看参数，还行，只需要五个，而且其中type参数也是固定的qq。再经过多次尝试， 发现vappid和vsecret也是固定的，那也就剩下g_vstk和g_actk了，可这俩真是难住我了，cookie里也没有，也没发现这两个的请求链接。可这俩的命名，ac啊，tk啊，vs啊，怎么看怎么感觉和cookie里那几个有关系。好在通过查询资料发现，其实这俩就是通过一个time33()算法，把vqq_vusession和vqq_access_token进行变换得来的。
好了，这下算是齐全了，通过链接，发现返回的可用cookie就只有vqq_vusession，这也恰好证明了我们之前的推测，这个参数才是最关键的。
而且通过测试发现，即使用一个已经过期的vqq_vusession去请求，也能获得一个新的vqq_vusession，十分友好。搭配上腾讯云函数的定时执行，每小时获取一个新的，像爱奇艺解析一样存在云端，妥妥的全自动化更新。
· 后记
这下算是圆满了，填了一个之前我自己挖下的坑，满足感MAX！
一如既往，我所实现接口开放给所有想白嫖的人http://api.lijishi.com/release/qqv2
还是要强调，以上仅供交流学习，请勿用于非法用途，侵删。
-
相关资料