在前面补一个结论，供不想仔细看的人了解一下情况。
百度修改了接口，8月13日左右陆续有人秒传
不能转存，部分人仍然可能转存成功但
距离不能使用只是时间问题。
今后极大概率不会再有秒传链接，不用期待还能有什么招数拯救秒传，百度能改死第二次就能改死第三次。
極彩花夢，民间字幕组。
之前算是随手发了喵传(
https://bbs.summer-plus.net/read.php?tid-1841982.html)，当时稍微说了一下原理。
不过本人是一直不看好秒传的，如果百度要改很简单就能改，比如slice-md5忽然从前256k改成前512k，这对百度来说是很简单很简单的。
但是对于使用秒传转存资源分享的人而言，这无疑是毁灭性的打击。无论如何，百度或者别的国内网盘，都可以非常简单修改这些或那些分享资源的方式，修改一次接口就能让多少人的辛苦付诸东流。
上一次是要求参数必须有slice-md5，以此让所有短链失效。
但这一次，似乎不是那么简单就能解决的了。
在前几天就有人反馈转存失败，但当时不少人测试得出似乎是ip或者账号的问题。
当时测试，按正确的请求，接口会返回errno为2。
终于在今天，转存失败的情况剧增。
接口会固定返回errno为2。
而正常发起rapidupload请求……似乎比以前复杂太多。
以前请求rapidupload，主要需要的就是 md5 + slice-md5 + size + filename 。
但是现在请求，请求方式从GET变为了POST，
GET参数需要：rtype + bdstoken + app_id + channel + web + clienttype + dp-logid ；
POST参数需要：uploadid + path + content-length + content-md5 + slice-md5 + target_path + local_mtime +
data_time +
data_offset +
data_content 。
好了相信到这里大家应该知道很离谱了。
——但是，就算别的参数能获取能模拟，data_content
非常长非常长（测试的一次为349529个字符），秒传是否要改成一大篇一大篇呢？
而且按目前秒传的行为……似乎模拟会非常困难。
我还没有仔细看各个参数是如何运作的，但就目前粗略的判断而言
——秒传，应该是需要抛弃了。
这不是能否复现请求与否，
而是
资源分享者禁不起这样的折腾；
这可能不再能得过且过，因为百度接连修改接口，永远指不定下一个“秒传”会变成什么样；
这也绝对不只是百度会有的问题，其它国内网盘也无从确认是否会如此，所以不用对其它的国内网盘抱有侥幸心理。
以上，总之应该是一个浪潮汹涌的落幕了。
如果百度秒传还能复现，我们或许会稍微更新一下脚本——但应该没什么意义，
因为重要的不是百度，而是分享资源的人。
补上一点临时得出的结论。
现在rapidupload接口非常非常复杂，并且尚不确定短期内百度是否会再次修改，至少短期内我们不会重制秒传脚本。
GET参数所有参数都是比较好处理的，POST参数主要是 uploadid 和 data_content 两个。
在模拟秒传行为时，会上传若干份（不定）文件分片，中途会请求一次rapidupload，
但目前发起rapidupload请求并不需要先上传分片，
也就是仍然可能能够直接发起rapidupload请求转存文件！uploadid个人不太清楚是怎么来的，但应该好处理。
主要就是data_content，应该是文件的部分内容的特殊形式——非常魔幻的是，对同一个文件进行重复模拟，每一次的data_content都不一样。
如果要让秒传苟延残喘，应该主要的问题就是要知道这个data_content是什么了。
一个强调，我个人还是不建议继续使用秒传或者使用国内网盘的，这绝对不只是百度会有的问题。
参数测试的一些结论。
GET参数部分：
rtype：固定为1，不重要。
bdstoken：可以从页面上直接获取，不重要。
app_id：固定为250528，不重要。
channel：固定为chunlei，不重要。
web：固定为1，不重要。
clienttype：固定为0，不重要。
dp-logid：不知道是什么，但是这个参数是非必要参数，可以不携带。
——所以GET参数部分是非常简单的，必要参数中只有一个bdstoken会变动，但其可以很简单地在页面上获取。
POST参数部分：
uploadid：是根据前面分片上传时superfile请求来的，不知道本来是怎么来的，但是这个参数是非必要参数，可以不携带。
path：路径+文件名。
content-length：文件大小。
content-md5：文件的MD5，加密后的。
slice-md5：还是文件的前256k的MD5！还是！正常请求会是加密后的，但是使用未加密的slice-md5也是能够转存的。
target_path：路径。
local_mtime：非必要参数，可以不携带。
data_time：不知道是什么时间戳，更改后不可转存。
data_offset：不知道是什么，更改后不可转存。
data_content：应该是文件的部分内容进行加密的产物，但是还不知道是如何计算出的。每一次请求该值都会改变，但使用之前的值是能够转存的。
经测试可得出，
data_content应该是与data_time和data_offset相绑定的。对同一个文件可以有若干组这三个参数的组合，可能这若干个组合何时都能成功转存，可能参数组合有时间限制（还无从得知）。
——所以POST参数部分相比之前，问题在于data_content与data_time、data_offset的参数组，当然还有data_content参数本身。
时间精力有限，还没能分析data_content。如果其有办法通过较短的形式复现，我们会考虑重制秒传脚本——但也只是死马当活马医。
当然直接取data_content原值可能也是能够复现秒传的，但一个data_content就小400k，一个文件的秒传就直接到一张图片的大小，真的就是破罐子破摔了。
……经测试，将一组有效的data_content、data_time、data_offset用在另一个账号上，转存失败。
可能是data_content中有一些辨识账号的信息，如此一来
可能无法复现网页端秒传接口。
目前的结论，没戏。有戏也真的就是死马当活马医。
我们不会重制秒传脚本，各位也早日拥抱国外网盘吧。
