标签: 115

  • 网络蚂蚁、快车,迅雷,BT、PT、网盘、下载这门技术不会失传

    好不容易周末在家,身子一躺,窝在床上,就想要好好欣赏一部电影,而且念头一来,冲动一起,真的连 1 秒钟都不愿意耽搁。

    这时候通常就会去在线网站看,可我发现问题没这么简单。

    这两天窝在家,我就想着重温一下小李子演的那部《泰坦尼克号》,可是当我在主流的优爱腾找了一圈,要么是干脆没有:

     

    要么是有删减,《泰坦尼克号》里那消失的 33 分钟,该有的敏感情节没有,不该有的广告的摧残又太多。

     

    更让我难以接受的,是这删减版的视频画质。。。

     

    所以没办法咯,在线看视频或许能很及时,但如果这个及时是建立在有删减、有广告、需要 VIP、还画质不达标的基础上,那我只能搬出祖传艺能,下载。

     

    是的,摆在我面前的有两条路,一条路是求助于网盘,去找别人分享过来的未删减高清资源,但 8 秒教育片的和谐警告仿佛就在昨日,网盘下载可以说前路未知;

     

    而另一条路呢,就是我们再熟悉不过的种子磁链 BT 下载了,可随着 115 的疲软,好像这条路也不那么好走了。

     

    虽然办法总比困难多,只要愿意花时间,哪怕是未删减的《泰坦尼克号》也有机会去在线网站上一睹为快。

     

    但不妨碍我下个结论,和十几年前相比,现在想从网上轻松下载,并不那么容易。

    这个结论或许有悖发展规律,不知道大家发现没有,明明在曾经那个拨号上网,网速不佳的年头,下载就已经成了互联网应用的主流,可为什么随着光纤的普及,曾经风光一时的下载工具却渐渐淡出了我们的视线呢?

    今天,就让我们一边回顾历史,一边找寻答案。

    中心化下载

    时间回到 1998 年,在一穷二白的中国互联网上,有一群电脑玩家正在从有限的宽带中,汲取着国外的资源。

     

    但毫无疑问,那时的下载是中心化的,无论是遵从 HTTP,还是 FTP,下载意味着我们要从资源提供方的服务器上,直接获取资源。

     

    这样的下载姿势,相当考验网络环境,但问题就在于,那时的网络环境并不那么美好,一旦断线,就得从头来过。

    一个不到几 M 大小的软件,光下载就需要几十分钟,在那个按时计费的拨号上网年代,下载何其奢侈。

    所以,如何把有限的宽带资源应用到极致,是摆在下载器面前,不得不面对的一座大山。

     

    为了解决这个问题,各路技术大佬们八仙过海,各显神通,有断点续传,防止重下的网络吸血鬼;也有另辟蹊径,利用电子邮件本地高速下载的 Mr Cool。

     

    当然,也在这个时候,还在上海交通大学读书的洪以容利用当时可以利用的一切技术手段,造就了世上第一款支持多点连接、断点续传的下载工具,「NetAnts」。

     

     

    与传统断点续传一个连接不一样的是,这只小蚂蚁可以同时创建多个连接下载同一文件,当一路连接效率下降时,空闲出来的资源就被让给其他连接,最大限度的利用宽带资源。

     

    可以这么说,自网络蚂蚁把多点连接、断点续传带到了世间,国内用户再也不用提心吊胆的盯着下载,祈求成功了,这只小蚂蚁会帮你把资源一点点搬到自己的硬盘上。

     

    不过这款纯良心的网络蚂蚁并没有想着一统江湖,而是造福大众后突然停止了新版本的开发,就此归隐山林。

    但新时代的一角已被掀起,后来者哪会就此止步不前,滴滴,名为下载新时代的快车即将到站。

    1999 年诞生的快车(FlashGet),很快迎头赶上成为了下载器中的教父——

     

    不仅继承了网络蚂蚁的全部优点,在更多线程支持、文件管理方面还给出了更优的答卷,这个国货之光,一度为 219 个国家提供过下载服务,不是作者刻意宣传,而是酒香不怕巷子深,就像现在许多个人汉化软件一样,网际快车也吸引了一大批爱好者,他们自发、无偿的将快车引进了自己的网络。

     

    如果说快车是一步一个脚印,让自己成为了装机必备,那在快车发车的同一时间,有一款收费工具也饱受好评。

    没错,影音传送带,当时唯一一款利用流媒体技术,下载只能在线播放的影音文件的下载器。

     

    虽然中心化的下载在当时大行其道,但随着网速越来越快,上网人数越来越多,对资源提供方的服务器要求也就越来越大。

     

    这就造成了一个很尴尬的局面,用我的人越多,下载速度反而越慢,甚至为了避免服务器挂掉,限速、限量的不便时有发生。

     

    千禧年后,BitTorrent 协议被提了出来,这种用户越多,下载越快的下载方式,逐渐盖过了中心化下载的风头。

     

    说会国内,有一只不得不提的小蓝鸟,别想歪,说的是迅雷。

    去中心化下载

    2002 年迅雷的创始人邹胜龙从硅谷回家创业,仅在第二年的 8 月开发出了迅雷,寓意下载速度能达到迅雷不及掩耳之势。

    但当时下载界的王者还是网际快车,迅雷只是个初出茅庐的小菜鸟,可谓夹缝中生存。

     

    那到底是什么给了迅雷反超快车的机会呢?说起来或许你不信,这个机会是《魔兽世界》给的。

     

    快车本是作者侯延堂在工作之余的产物,虽然如日中天宛若教父,但缺钱缺运营是快车不得不面对的问题。

    而就在这个快车发展的关键节点,快车的作者却奔赴了艾泽拉斯大陆,整整停更一年有余。

     

    这被伺机而动的迅雷抓住了机会,在快车不再更新的那一年里,迅雷接连推出了 29 个版本,平均 25 天一次,仅用了一年的时间就抢占了快车手中 40% 的市场份额。

     

     

    如果说快车停更为迅雷发展让了路,那让迅雷大步向前走的原因,就是 P2P 的 BT 下载了。

     

    在 BT 下载里,没有中心服务器存储资源,每一个参与下载的人,既是资源的下载者,又都是资源的上传者,众人拾柴火焰高,参与下载的人越多,下载的速度也就更快。

     

    至于茫茫网络中,你要怎么才能找到正在下载这个资源的其他人,就不得不提 Tracker 追踪服务器了。

    一个简单的 BT  种子中包含了文件的名字、大小,顺带着还有 Tracker 服务器的地址,这个 Tracker 服务器是干嘛的?

     

    简单说,这是个记录了下载者联系方式的「通讯录」。

     

    当你下载种子的时候,下载器会去联系种子内置的 Tracker 服务器,告诉服务器:我要开始下载这个文件了啊。

    然后服务器会记录下你的 IP,并把上传者的 IP 返回给你,你下载的同时不是也在上传嘛,新来的下载者也能以此找到你,在所有人知晓,且认可的互帮互助下,每一次 BT 下载都能形成一个良性闭环。

     

    中心化下载的「用户越多,速度越慢」的问题,在去中心化的 BT 下载里,则是「用户越多,速度越快」。

     

    迅雷下载器在这个 BT 下载里,不仅仅是攒局,还起到了帮用户找寻网络,加入网络的责任,但你猜迅雷做了什么?

     

    从传统 P2P 网络下载数据后,并不回传或者很少回传,而是只将数据上传给其他迅雷用户,吸血的恶名自此而来,但对于普通用户来说,迅雷那下载速度的提升是实实在在的。

    我记得 2008 年想看个《钢铁侠》,首选的关键词都是「片名+迅雷」的姿势。

     

     

    但迅雷登顶王座没几年,整个 BT 下载环境急转直下,不是吸血太多,而是版权成了下载工具的又一道坎。

    或许你会说,不对啊,BT 下载不是去中心化的嘛?但你要知道,前面提到的 Tracker 服务器成了最好的靶子。

    2009 年前后,随着 BT 服务器接二连三的倒下,BT 下载正式进入冰川期,你说迅雷?

     

    因为吸血机制的存在,不仅要面临着被下载站点封杀,P2P 网络加入黑名单的局面,而且美国电影协会六大电影制片公司联手,于 2008 年将迅雷告上法庭,迅雷最后支付了几千万的赔偿。

     

    现在的 BT 下载,热门资源下载速度还可以,但是冷门资源下载速度特别慢,虽然参与下载的人很多,但是主动上传分享却不多,遇到热门资源大家一哄而上,下载完成立马就跑。

     

    核心问题归纳起来就是,没有约束的 BT 下载,只是一盘散沙。所以你常常会遇到,冷种、死种、断种的问题,BT 下载再也没有过去那般安逸了。

     

    这个时候 PT 下载应运而生。

     

    既然没办法约束所有人都能做到无私上传,那就划定个小圈子,筛选一群志同道合的爱好者,所有想进入这个圈子的下载者,都被记录了上传、下载量。

     

    你在这个圈子里下载的每个种子都是对应你的账号,如果有人长期只下载不上传,那么分享率就会很低;如果有人把种子文件外泄,别人使用你的种子去下载,同样也会记录在你的账号上。

     

    而规定考核期限一到,你的分享率不达标,就会被踢出圈子,也就无法下载了。

     

    正因为这样严格的限制,PT 下载反而是现在最安逸的去中心化 P2P 下载,没有之一。

     

    网盘下载

    说了这么多,你发现诡异的地方没?迅雷的没落从来不是因为别的下载器取代了它,甚至可以说,在迅雷之后,再也没有一家独大的下载器龙头了。

     

    就像无数经验教训告诉我们的那样,打败你的不是同行,而是跨界来的新人,这个新人叫网盘。

    我们不再去谈网盘具体的发展史,而是直接快进到 2013 年,这是一个极为特殊的节点,因为在这一年,国内网盘市场开启了一轮前无古人,后无来者的网盘大战。

     

    在 2013 年以前,提供个人网盘服务的公司,采用的都是付费模式,但在 2013 年 8 月 12 日,金山快盘个人版宣布自即日起推出「100G空间永久免费」计划。

     

    这一下成了网盘大战的导火索,仅在 4 天后,360 网盘推出 360G 的免费空间。

    又过了 6 天,百度网盘宣布「只需花 1 元即可获得 1T 永久存储空间」,你仔细看看前面的金山和 360,憋了那么久,推出的服务还是百 GB,而到了百度这里,直接就给上升到了 1TB。

     

    这可不是菜市场买菜,多送你一把青菜,网盘方服务器的网费、电费、维护费都是一笔不小的开支。

    但 360 明显没有被百度吓到,在百度提出「1 元 1T」后,立马做出回应,宣布在原有 360G 免费空间基础上加送 666G 免费空间,合计 1T 多的免费空间。

     

    你说互联网大吧,圈子就那么小,360 此举,明显是跟百度网盘叫板。

     

    百度会因此放弃嘛?没有,2013 年 8 月底,百度网盘再次强势表态,把「1 元 1T」升级到了「1 元 2T」。

    可还没等到 360 回应,同为巨头的腾讯突然出招,9 月 2 日,腾讯微云宣布:登陆腾讯微云手机客户端即可获得 10T 免费存储空间。

     

    好家伙,1T、2T 在腾讯这波操作面前,显得扭扭捏捏,压力明显又回到了 360。

    你猜 360 做了什么?9 月 3 日,360 网盘宣布:360 网盘推出无限空间,绝杀。

     

    不到 1 个月的时间,这场网盘大战,让国内个人网盘容量从几十 G 飙升到上千 G,而且几乎纯免费,整个网盘市场,被这突如其来的大战,快速催熟。

     

    先不说这些参与网盘大战的网盘下场如何,反正铺天盖地的宣传,彻底改变了人们下载资源的思路。

    去中心化的获取资源,又中心化的下载资源,独特的网盘下载成了人们找资源时的第一反应。

    毕竟你说你是愿意等传统下载器慢慢下载,还是愿意直接用网盘的一键转存?下载速度都那样,后者还能在线看,网友会怎么选,不言而喻。

     

    结语

    所以在经历过了网盘的洗礼后,下载资源这件事一直是网盘和 BT 下载二分天下,不单单是下载器的没落,下载这门手艺活也显露颓势。

    这是时代的选择,脱胎于互联网空白时期的下载器,当时受限于上网方式,受限于上网速度,下载工具是装机必备的刚需。

     

    但随着高速宽带的普及,随着浏览器等内置下载器的完善,还有版权保护,分享资源方式的改变,在线服务的出现,下载变得越来越被动。

     

    那你说在很多年后,当在线服务越来越好,可以满足 95% 以上网民需求时,看到关于下载的故事,会感到惊讶吗?

     

    会,肯定会的,明明在线就能搞定,为何还要存储本地呢,这不是多此一举嘛。

    但是,我也同样相信,下载这门早期网民应知应会的基本技能,绝不会失传。

     

    无论云端处理有多快,云端空间有多大,无论你有没有经历过下载器落寞、网盘 8 秒教育视频审核,落袋为安,只有下载到本地硬盘,才算真正拥有它。

     

    为什么我会那么固执的选择下载?是为了那 5% 的小众需求,也是为了那观影时的 1 秒冲动。

    这个圈子的人或许不多,但那里有我,也希望有你。

  • 如何解决115转存助手出现“上传失败!可能参数不正确(?):target invalid” 问题?

    请马上升级115转存助手到v3.5版本,解决“上传失败!!! 可能参数不正确(?):target invalid” 问题
    产品

    最近有网友反馈,今天115转存出现“上传失败!!! 可能参数不正确(?):target invalid” 问题。

    解决办法:

    请升级到最新的v3.5版本(4.2日更新)。

    脚本更新地址:https://gist.github.com/Nerver4Ever/953447c9ecd330ffc0861d4cbb839369

    最新更新日期: 2022.04.02 v3.5 修复不能选择保存位置;优化超时提醒。 安装与更新:点击旁边 “Raw” 按钮

    更新日志:

    1、因115页面调整和接口改变导致无法保存指定目录,以及出现参数不匹配等问题;
    2、优化“超时”提醒,缓解因“操作超时”提示失败,导致使用者心中的不安

    ### 主要功能:
    * 提取的时候带目录,本脚本目录用“|”分割
    * 支持带目录转存,包括支持 用“|”,支持json格式(格式为{“dir_name”:””,”files”:[],”dirs”:[]})
    * 支持搜索页面的提取
    * 优化了操作进度提示
    * 支持直接选择导入sha1链接文件(符合格式的.txt和.json)
    * 支持选择导入的位置
    * 支持在导入的位置,自动创建目录
    * 支持自动在文件名中增加分隔符,以及自动去分隔符
    *支持转存不创建子目录

    ### 注意:
    * 提取时遇到不能下载的文件获取到sha1链接(本脚本用40个0替换)是暂时有效的,等文件能下载了就会失效
    * 转存时未过滤空目录,或者由于转存失败会导致空目录存在
    * 使用时,不要最小化浏览器和切换tab页面,即:需要保持操作页面始终可见
    * 适用于chrome或者<del>v23版本的</del>(新版已经支持v24)115,以及导入的文件需要为utf-8编码
    * 如果转存失败,请检查链接或者在chrome上进行尝试,115pc端偶尔抽风;或者可能与其他脚本冲突,导致显示元素不完整
    * 遇到问题,反馈时请描述你使用的【浏览器】,【浏览器版本】,【什么操作】,【链接】,【错误提示】,要不然无法进行错误复现。

    ### v3.3起 注意:
    [!].为保证【转存】时【自动去除分隔符】正确运行,请勿同时多开进行转存操作(包括同时多页面转存,或者跟其他工具同时转存)
    [!].请使用chrome和115pc最新版,以及Tampermonkey最新版!!!!
    [!].请保证你的网络和浏览器能访问代码中的依赖库!!!

     

    ### 最近更新日志:
    v3.5 143.2022.0402.1
    fix:因115页面调整和接口改变导致无法保存指定目录,以及出现参数不匹配等问题;
    fix:优化“超时”提醒,缓解因“操作超时”提示失败,导致使用者心中的不安感
    update:因为1,暂时下线添加任务时,默认指定为当前目录功能

    v3.4 143.2022.0202.1
    fix:由于含有/:等字符导致文件夹或者文件不能下载到本地的问题——转存和提取遇到“:”“|”等9个字符会自动替换
    fix:不再兼容用“#”作为目录分隔符,即新版目录名称中可以含有“#”
    fix:子目录创建时,有同名文件夹,处理跟根目录相同处理
    fix:修复在线的json进行“尝试转存”失败的情况
    fix:弹窗时保存的位置可能数据还在获取,再次加长延迟:从200ms变成1000ms
    add:新增新设置:【列表模式下:悬浮条显示”获取sha1链接“】与【缩略图模式下:显示”获取sha1链接“】
    add:新增获取“脚本与环境信息”,入口在油猴设置处,方便报bug时准确

    v3.3.2 143.2022.0126.1
    针对网络问题,只能将不稳定的依赖库置于源代码内

    V3.3.1 143.2022.0122.1
    fix:缩略图模式下,如果文件夹设置了封面,”获取sha1链接“按钮会覆盖整个区域。
    fix:如果链接里有重复文件,转存后自动去除分隔符,重复的文件只改了一个,另外几个没有去除
    fix:缓解“添加任务”弹窗,脚本修改保存位置比115修改快,导致自动修改位置失败的bug

    v3.3 143.2022.0114.1
    [*]. 新增懒人操作1:对在线的sha1文本文件(.txt,.json)可进行【尝试转存】,防止浏览器卡住,要求sha1文本文件小于2MB
    [*]. 新增懒人操作2:打开【添加链接任务】弹窗时,“保存到”的位置自动定位到当前目录
    [*].【转存】时【自动去除分隔符】,已经不需要勾选【强制在保存处新建根目录】,并且速度更快了(即:不自动生成根目录成功,也可以应用自动去除分隔符 )
    [*]. 自动创建的根目录,已从时间戳改为人类能看懂的时间
    [*]. 点击【开始sha1转存】,此前有概率不能关闭【添加链接任务】弹窗,此版本应该改善很多
    [*].【转存】与【提取】的操作加了“超时”操作,【提取】另外完善对404文件的处理,对于操作中卡住的情况应该改善很多
    [*]. 用导入的文件名作为自动创建的根目录时,”.”变”,”的行为已经修正
    [*]. 提取时如果目录名含有”|”,为保证导入的目录结构正确性,会修改”|”为”/”
    [*]. 优化了在创建子目录过程中ui卡住的问题,自测自用没有问题,但不保证
    [*]. 其他ui优化,如此前在分享页面出现【链接与sha1转存任务】按钮等做了调整,其他不再一一列举

    v3.2.1 143.2021.1220.1
    v3.2.1替换了cdn.jsdelivr.net的源;否则无法使用正常

    v3.2 143.2021.1211.1
    1.新增“获取选中项的sha1”:方便手机上或者多选提取,文件和目录可一起选择,列表模式与缩略图模式下皆可(感谢@qbz95老哥的打赏支持!)
    2.优化小文件提取:新版本对于小文件(128KB以下)不进行向服务器发包,如果小文件较多,提取速度会快很多
    3.优化出错文件提取:某些文件115服务器无法下载或者返回信息出错,新版本已经优化,提取无限卡住应该已经改善或者解决
    4.已经隐藏uiddiv:有老哥提出115截图可能会含有隐藏的uid信息,新版本已经隐藏,可再测试是否有效(感谢@ワーン シアーン老哥测试,以及@Yves Lelouch老哥的解决方案)
    5.提示ui的改进

    *v3.1 143.2021.1015.1
    1. 文件中含有”.”已经能正确改名(上一版本会变成”,”,注意不要用”.”作为分隔符)
    2. 缩略图模式下,对于文件夹和文件添加获取sha1链接按钮
    3. 添加任务界面,增加多处提示,方便”九年义务教育漏网之鱼”的使用
    4. 自动创建根目录,已经修改逻辑,只要勾上,就能自动创建成功

    *143.2021.0911.1
    09.11修复waitForKeyElements.js的依赖问题 (由于greasyfork上的WaitForKeyElements.js的库被删,导致无法实现正常功能)

    *143.2021.0907.1
    1.新增加设置界面,可设置脚本的显示任务与默认参数
    2.“sha1转存时,强制在保存处新建根目录” 的默认值,可在设置界面配置
    3.“sha1转存时,不创建任何子目录”的显示与否,可在设置界面配置
    4.对于目录,悬浮工具条增加“去除分隔符”功能,即:去除该目录下所有文件的分隔符
    5.默认设置【转存时给文件名添加分隔符,转存完成后去除分隔符重命名】一条龙功能
    6.在5中的,添加分隔符,去除分割符,分隔符方案都可以在设置中配置
    7.由于115接口的进一步抓紧,时间参数不可配置,并增加了更多提示信息
    8.转存过程中以及失败复制到剪贴板的文件名,修改为原来文件名,方便排查

    *143.2021.0822.3
    修复由于115上传接口更改导致不显示上传失败的原因

    *143.2021.0822.2
    修复转存时无响应:因为自身带有emoji的文件名,再强制分隔时出错

    * 143.2021.0822.1
    修复ui错位,增加提示等ui优化;
    增加:
    强制在保存处新建根目录;
    强制在文件名中加入分隔符;
    提取时可以取消,并且保存已提取内容;
    提取时已经设置超时处理;
    转存完成时,新增”打开目录”按钮

    * 1.4.3.20210422.0
    优化提示次数:每天1次;优化大小为0的文件提取
    * 1.4.3.20210415.0
    不能下载的文件提供暂时的转存链接,40个0结尾,注意:文件能下载时,该链接就会不匹配!
    修复多重目录转存时可能存在结构错位的问题
    * 1.4.3.20210307.1
    “转存”处增加“要不要创建目录”的选择项
    搜索处增加了单个文件已经单个目录的sha1提取(鼠标悬停时的tooltip上)
    搜索处增加对本页所有和选中的文件的提取(排除目录,因为这样可能会重复提取文件;并且只是当前页)
    * 1.4.3.20210305.0
    修复115pc版v24版(v24.0.2.2)提取的支持
    * 1.4.3.20210304.2
    修复转存时遇到&导致的问题,包括文件名截断以及目录创建失败
    修复未刷新网页的情况下可能在未选择文件的情况下,重复使用上次文件的情况
    * 1.4.3.20210304.1
    解决由于“异常文件,无法下载”导致提取卡住的bug
    优化转存出错时的提醒
    * 1.4.3.20210303.1
    屏蔽esc减导致进度条弹窗退出
    优化平衡速度
    * 1.4.3.20210302
    支持直接导入sha1链接文件(符合格式的.txt和.json)
    优化提取策略,大于1200数量,慢速
    * 1.4.3.20210301
    修复同一目录下存在相同文件导致提取死循环的bug
    * 1.4.3.20210227
    计数bug修改,修改代码适配115浏览器
    * 1.4.3.20210209
    优化代码,增加目录
    * ……

    如果不方便升级,临时解决办法:

    1、在每一次转存时候选择“sha1转存时,强制在保存处新建根目录”

     

    2、或者在设置中,缺省选中““sha1转存时,强制在保存处新建根目录”这项默认选中”

    注意:不管是第一种、第二种方案,115转存文件都保存到跟目录下临时创建德文件夹中,类似:[email protected] 下午1.38.31 (638)

    感觉是115接口问题,具体原因需要观察一下。