level 6
7z
2017年11月06日 02点11分
level 13
![[勉强]](/static/emoticons/u52c9u5f3a.png)
7Z哦
level 13
除了特定bmp,wav格式的文件外, 7z几乎一定高于rar.
rar对特定bmp,wav格式有特殊预处理, 所以压缩效率很可能高于7z.
2017年11月07日 09点11分
5
rar对特定bmp,wav格式有特殊预处理, 所以压缩效率很可能高于7z.
![[咦]](/static/emoticons/u54a6.png)
WAV我现在都先直接转压成tak，再打包的，不过这个还真没注意到→ →![[哈哈]](/static/emoticons/u54c8u54c8.png)
level 13
@VNCsdl
@神之幻想乡
单独写一楼解释一下我对楼上讨论的理解:
关于XP,Win7镜像的压缩, 因为这些系统安装文件都是已经经过压缩的, 7z,rar等无损压缩格式都不能很好地再次压缩, 在这种情况下比较压缩率就五十步笑百步了, 没有什么意义, 压缩率在90%以上还不如不压缩.
另外, 7z的
lz
ma算法确实对已经压缩过的数据处理的不好, 这种情况经常连zip都不如, 如果只是对已经压缩的很多文件做打包用途, 推荐直接用zip了. 当然,7z作者也意识到这个问题, 随后在lzma2算法改进了已压缩数据的处理, 想必用此算法跟rar想必就没什么差距了, WinRAR等常用压缩软件比较新的版本都支持lzma2算法.
关于恢复记录, 现在各种传输设备和软硬件都比较完善的情况下, 极少出现少量数据出错的情况, 以前经常是因为下载客户端或服务器软件bug,文件系统不稳定导致一些数据损坏, 现在这种情况极少出现了, 更多的是整个硬盘损坏会大面积损坏, 这种情况下恢复记录杯水车薪, 所以现在防止数据丢失主要是靠不同硬件介质的定期备份.
另外像BT或其它一些下载机制, 是有分块校验的, 如果有数据损失, 可以只重新下载损坏的数据块而不用重新完整下载.
2017年11月12日 04点11分
6
@神之幻想乡
单独写一楼解释一下我对楼上讨论的理解:
关于XP,Win7镜像的压缩, 因为这些系统安装文件都是已经经过压缩的, 7z,rar等无损压缩格式都不能很好地再次压缩, 在这种情况下比较压缩率就五十步笑百步了, 没有什么意义, 压缩率在90%以上还不如不压缩.
另外, 7z的
lz
ma算法确实对已经压缩过的数据处理的不好, 这种情况经常连zip都不如, 如果只是对已经压缩的很多文件做打包用途, 推荐直接用zip了. 当然,7z作者也意识到这个问题, 随后在lzma2算法改进了已压缩数据的处理, 想必用此算法跟rar想必就没什么差距了, WinRAR等常用压缩软件比较新的版本都支持lzma2算法.
关于恢复记录, 现在各种传输设备和软硬件都比较完善的情况下, 极少出现少量数据出错的情况, 以前经常是因为下载客户端或服务器软件bug,文件系统不稳定导致一些数据损坏, 现在这种情况极少出现了, 更多的是整个硬盘损坏会大面积损坏, 这种情况下恢复记录杯水车薪, 所以现在防止数据丢失主要是靠不同硬件介质的定期备份.
另外像BT或其它一些下载机制, 是有分块校验的, 如果有数据损失, 可以只重新下载损坏的数据块而不用重新完整下载.
level 8
从我自己的使用经验来说，我已经无数次从百度网盘下载到损坏的文件，其中上传者打包rar时加了恢复记录的，比如tsdm，忧郁的弟弟等，全都在修复后正常解压。而那些7z就只能重下了。
而偏偏现在百度网盘广泛应用，所以我觉得rar的恢复记录还是非常重要的。
2017年11月12日 04点11分
7
而偏偏现在百度网盘广泛应用，所以我觉得rar的恢复记录还是非常重要的。
![[滑稽]](/static/emoticons/u6ed1u7a3d.png)
level 13
楼上这基本可以确定是百度服务器或客户端(当然也很可能是非法客户端)的bug了, 恢复记录只能纵容这种问题的无视.
正确的
做法应该是积极反馈,修复bug,让所有人都不用再下多余的数据, 整体降低流量共同受益, 实在不行也可以像BT那样在下载客户端提供分块校验部分重下机制.
恢复记录可以说是一种保险机制,但价值并不大. 比如加1%的恢复记录, 如果现实中有大于1%下错的概率而且还能正常恢复的比例, 才有价值. 否则让其它99%以上的人多下了1%,去弥补不到1个人下错,是不值得的.
当然, rar或者任何文件, 都可以实现把恢复记录单独保存成另一个文件, 正常下载无误的不用再下载恢复记录, 只有出错的才需要尝试下载对应的恢复文件尝试恢复, 只是这个做法比较麻烦. 如果出错的几率可观, 网盘服务器和客户端应该直接提供自动生成恢复记录并自动下载恢复的机制.
2017年11月13日 02点11分
8
正确的
做法应该是积极反馈,修复bug,让所有人都不用再下多余的数据, 整体降低流量共同受益, 实在不行也可以像BT那样在下载客户端提供分块校验部分重下机制.
恢复记录可以说是一种保险机制,但价值并不大. 比如加1%的恢复记录, 如果现实中有大于1%下错的概率而且还能正常恢复的比例, 才有价值. 否则让其它99%以上的人多下了1%,去弥补不到1个人下错,是不值得的.
当然, rar或者任何文件, 都可以实现把恢复记录单独保存成另一个文件, 正常下载无误的不用再下载恢复记录, 只有出错的才需要尝试下载对应的恢复文件尝试恢复, 只是这个做法比较麻烦. 如果出错的几率可观, 网盘服务器和客户端应该直接提供自动生成恢复记录并自动下载恢复的机制.
![[不高兴]](/static/emoticons/u4e0du9ad8u5174.png)
level 8
基本都是在用 7z 偶尔用用 nanoZip ..
RAR 我基本上没见过几次压缩比高于 7z 的的情况..
RAR 的优势从来都不是压缩比.. 其根本上就更注重综合能力..
恢复记录我更倾向于专门的恢复软件.. 如 MultiPar 等.. 可调教性更佳..
我比较喜欢 RAR 的地方是分卷压缩.. 感觉比 7z 分得有技术含量一些.. = =
2017年11月14日 14点11分
9
RAR 我基本上没见过几次压缩比高于 7z 的的情况..
RAR 的优势从来都不是压缩比.. 其根本上就更注重综合能力..
恢复记录我更倾向于专门的恢复软件.. 如 MultiPar 等.. 可调教性更佳..
我比较喜欢 RAR 的地方是分卷压缩.. 感觉比 7z 分得有技术含量一些.. = =
level 14
7z主要是分卷不能单独解压。
rar经常是网盘下载某几个分卷解压出来某个文件就行了这种操作。
但是zip和7z完全做不到。
还有网盘不是百度一家的问题，包括mega和谷歌的网盘，这种有大量CDN节点的网盘太容易坏档案了(1GB以上的单个大文件)。
7z坑就坑在没把恢复记录工具能做的东西直接集成，比如说par2/3直接可以打包的时候顺便添加(支持外挂或者内置)。
2017年11月17日 15点11分
10
rar经常是网盘下载某几个分卷解压出来某个文件就行了这种操作。
但是zip和7z完全做不到。
还有网盘不是百度一家的问题，包括mega和谷歌的网盘，这种有大量CDN节点的网盘太容易坏档案了(1GB以上的单个大文件)。
7z坑就坑在没把恢复记录工具能做的东西直接集成，比如说par2/3直接可以打包的时候顺便添加(支持外挂或者内置)。
level 14
现在分享资源很多人干脆只是打个包并加上3-5的恢复记录（并不在意那点压缩率），说实话各种云的出错率并不算小了，这也是为什么很多地方都是鼓励打包并添加恢复记录上传。如果是需要本地长期储存收藏并不经常打开的话，推荐使用7z lzma2，文件数量多的话使用固实压缩文件模式。其实有个邪门点的办法，7z先压缩好，然后在用rar包一层并加上恢复记录，不过对于解压者来说可能并不那么友善罢了
2017年11月20日 23点11分
12
我以前也这样做过。然后有些小白下载者问——解压这么慢，是不是有病毒啊，这里面怎么还有压缩包啊，这该怎么解压啊，是不是…… → →
2017年11月21日 17点11分
很久以前遇上过大量分卷rar解出来一个7z的情况.. 文件非常大所以很崩溃 = =
2017年11月22日 22点11分
level 11
现在的7zip不一定能比RAR了，我32G内存，7zip最多只能384词典，RAR可以1024词典，结果就是RAR胜
2018年11月05日 08点11分
14
level 4
前几天在度盘里下了个RAR压缩包，解压错误，显然下载的数据有问题，尝试恢复记录失败。客户端显示该压缩包已校验，为了准确性再下了一遍，前后压缩包的校验码都是一致的，那么可以说明要么度盘的服务器有问题，要么发布者上传时数据异常，要么他压缩时根本已经坏掉。
其实之前也有遇到过下载失败的情况，不过尝试恢复都是成功的。总的来说恢复记录的技术，有好过没有。在国内使用网盘分享资源如此盛行，松鼠党保存资源后并没有第一时间下载到本地，到后来才发现解压失败，回去找发布者早已不在了，在没有查找到出问题的环节下是不可能要求人家重新上传的，特别是数10GB级别的文件。如果发布者给压缩包加入恢复记录，那么下载者可以得到解压的一定程度保障，就算没法恢复也能立马确认发布者上传有问题然后反馈，节省双方的成本，从分享资源的解决方案上看加入冗余会更受益。
2019年06月16日 06点06分
15
其实之前也有遇到过下载失败的情况，不过尝试恢复都是成功的。总的来说恢复记录的技术，有好过没有。在国内使用网盘分享资源如此盛行，松鼠党保存资源后并没有第一时间下载到本地，到后来才发现解压失败，回去找发布者早已不在了，在没有查找到出问题的环节下是不可能要求人家重新上传的，特别是数10GB级别的文件。如果发布者给压缩包加入恢复记录，那么下载者可以得到解压的一定程度保障，就算没法恢复也能立马确认发布者上传有问题然后反馈，节省双方的成本，从分享资源的解决方案上看加入冗余会更受益。
你说的特别好吖！
2019年09月03日 05点09分
