建议VCB-S发布资源时附带校验值
虽然BT客户端也可以校验，但是BT是按区块校验，所以校验部分文件时通常还会需要前后的区块，也就是说，必须下载种子内所有文件才能100%校验完成。直接在发布资源中附带校验文件或者文件名附加校验值的方法更灵活，也更有保证，不会出现Nyaa挂了没种子来校验的这种情况。事实上近来我在PT辅种时已经发现好几例转载资源搞坏文件校验错误的了，可见这种风险确实是存在的。再加上现在好多人喜欢用百度云，但是百度云本身很不靠谱，通过API多次获取同一文件的md5值会不一致这种事我也是遇到过的。 本帖最后由 TC 于 2017-6-10 13:30 编辑emmmmm 让我来逐点解析：
"所以校验部分文件时通常还会需要前后的区块" √
"必须下载种子内所有文件才能100%校验完成" ×
那么一个区块多大呢，16KiB~4096KiB，所以只有一个文件下未校验的大小范围是[0, block_size*2)，所以实际上未校验到的其实是占比很小的，况且一般都是下完了拿去校验的。
"不会出现Nyaa挂了没种子来校验的这种情况" 如果那么多个站点全部爆炸的话，也没必要继续做下去了吧，否则总有地方能下到种子的。
"已经发现好几例转载资源搞坏文件校验错误的了" 那转载的人没校验有什么办法，那是他的纰漏，加了校验码又有什么用。
怕百度云不靠谱就压缩加恢复记录啊，都直传了不是已经做好有概率翻车的可能了么。
TC 发表于 2017-6-10 13:28
emmmmm 让我来逐点解析：
"所以校验部分文件时通常还会需要前后的区块" √
有一种情况是不同软件不同操作系统制作的种子，其中包含文件排序和做校验的客户端不一样，以致难以预期校验所需的数据都包含在哪些文件里。
加校验值的意义主要体现在二次流通上，同时所需的工作量又极小。 cylx 发表于 2017-6-10 14:16
有一种情况是不同软件不同操作系统制作的种子，其中包含文件排序和做校验的客户端不一样，以致难以预期校 ...
"其中包含文件排序和做校验的客户端不一样" 也就两种顺序，按文件名和按文件大小。然后VCB-S现在采用的是按文件名排序。
到底是运气是多背导致一个差不多1GiB的视频刚刚好就在头|尾那么两个块上坏文件了而中间那么多却完全正常，这显然不是下载中的常态。
为了仅在某些特定情况下导致不想/无法用BT软件并且只想下载一两个文件的情况，去给文件做两次hash，闲得慌么。
本来分发途径就是BT，然后要为别的情况考虑这考虑那，那校验文件下不下来怎么办，校验文件损毁了怎么办，是不是要给校验文件再加个校验文件啊。
文件名加校验码是不可能考虑的，难看就不说了。本来文件名就这么长，还要加一串来冲击系统的路径最长长度限制。
或者直接放网站上，那这种校验信息谁都能生成，谁想生成就谁去生成咯，贴个链接去造福其他人嘛。
目前我们会主动发布的各站，包括 U2、ACGRIP、动漫花园外站、萌番、末日还有已死的 nyaa，使用的都是同一种子，且在制种时会保留文件顺序。从上述网站都可以下载到种子进行校验，因此不会找不到种子的。用种子校验也如 TC 所说，并不需要全部下载，选择你要检查的文件即可。我上午就刚刚修正了从度盘下坏的 2 集 saki 正片，只下载了 7.9MiB。
其实想一想，文件自附校验码并不能降低文件在脱离BT转载时的出错率，只为这个环境下的下载者提供了检查手段，却没有提供修正手段。一旦发现错误，你并不知道是转载者用了错的文件，还是打包时出错，或者上传下载时出错，甚至可能是你自己的硬盘坏了。最终，依然只能找来种子使用BT客户端校验和修正。 TC 发表于 2017-6-10 15:31
"其中包含文件排序和做校验的客户端不一样" 也就两种顺序，按文件名和按文件大小。然后VCB-S现在采用的是 ...
确实存在uTorrent校验顺序与文件列表按文件名或大小排序都不一致的情况，可能是两处的算法实现不同。
既然贵组认为这个步骤多余，那当我没说好了。 本帖最后由 cylx 于 2017-6-10 18:09 编辑
Airium 发表于 2017-6-10 16:11
目前我们会主动发布的各站，包括 U2、ACGRIP、动漫花园外站、萌番、末日还有已死的 nyaa，使用的都是同一种 ...
校验文件比BT客户端更适用的场景肯定是存在的，毕竟一个是以文件为单位，一个是以种子为单位，前者一定是更灵活的，何况后者还有很多限制和不便。问题在于值不值，如果认为不值，那就算了。 cylx 发表于 2017-6-10 17:54
确实存在uTorrent校验顺序与文件列表按文件名或大小排序都不一致的情况，可能是两处的算法实现不同。
既 ...
自然，torrent的标准里并没有限制怎样的顺序，真想乱序确实是可以做到的，但是在uTorrent所做出的种子里并没有出现的反直觉的生成结果。
而你在uTorrent下按体积排序并不是uTorrent校验时所认为的按大小排序，实际上是先按文件夹，再按大小的。
以前网速慢，下个1G文件2个多小时，我当时很想每个文件都附带crc32，尤其断种的挂UT是没结果，为了确定hash正确断种的下网盘全文件（因为有些发布者制种时不按文件名制种）性价比不高（时间上的）。
现在网速快了，我为了确定一个7M的图片hash值正确下网盘压缩包整50G都不在话下{:4_675:} 其实，我觉得楼主说的也不是会增加很多麻烦，用rapidcrc可以生成sfv校验文件，批量生成，批量校验，还是很方便的。
页:
[1]
2