—— 来自 Sony J9110, Android 9上的 S1Next-鹅版 v2.2.0.1 需要bmp才有效果，其他压缩格式反而差异太大压不出 qw945 发表于 2019-11-29 13:58
黄油差分瑟图压缩率也很猛
—— 来自 Sony J9110, Android 9上的 S1Next-鹅版 v2.2.0.1 ...
需要bmp才有效果，其他压缩格式反而差异太大压不出 The file contains 16 zipped files, which again contains 16 zipped files, which again contains 16 zipped files, which again contains 16 zipped, which again contains 16 zipped files, which contain 1 file, with the size of 4.3GB.
So, if you extract all files, you will most likely run out of space :-)
16 x 4294967295 = 68.719.476.720 (68GB)
16 x 68719476720 = 1.099.511.627.520 (1TB)
16 x 1099511627520 = 17.592.186.040.320 (17TB)
16 x 17592186040320 = 281.474.976.645.120 (281TB)
16 x 281474976645120= 4.503.599.626.321.920 (4,5PB)
zip bomb 字体这玩意儿是矢量的，同一系列的字体差异很小，所以压缩率较高 GrassSand 发表于 2019-11-29 14:24
zip bomb
这解压出来是个啥玩意 tgzeror 发表于 2019-11-29 16:31
这解压出来是个啥玩意
4.5 PB 塞爆你的硬盘 GrassSand 发表于 2019-11-29 14:24
zip bomb
哈哈，我也想到这个来着 GrassSand 发表于 2019-11-29 10:24
zip bomb
这个会不会被安全软件给拦截掉 GrassSand 发表于 2019-11-29 14:24
zip bomb
md，win10千万不要解压出来
win10好像为了给压缩文件里的内容建索引，会解压里边的内容。。然后，刚就解压了一层文件放桌面，虽然第一层只有那么1MB不到，过一会系统就不正常了，先是浏览器等软件崩溃，之后桌面崩溃直接黑屏。。
重启后发现C盘爆了、索引程序cpu高占用才意识到问题
理解为什么他要设密码了，不然刚下载下来硬盘就爆了
信息率低的格式压缩率就高比如bmp 冗余度高这个也不奇怪 沧粟 发表于 2019-11-29 19:28
md，win10千万不要解压出来
win10好像为了给压缩文件里的内容建索引，会解压里边的内容。。然后，刚就解 ...
ntfs新版支持稀疏文件，如果基本空内容，可能实际已解压的大小远大于你外层看到的 楼主那个我实验过，用7z压缩字体效率很高，比常用的zip，rar强 果然万事还是要自己试一下才知道。
试过之后才知道自己是想当然了。
答案是，我也不知道为什么这个文件压缩率这么高。
过程，先按图索翼去下载了楼主的原文件，压缩率在2%
https://i.loli.net/2019/11/29/irPBNeRQnzvw4OW.png
我用WinRAR 5.71，开启最高压缩，大约花了9分钟得到一个rar包。压缩率45%
https://i.loli.net/2019/11/29/Xuri1j4KtgfCzAL.png
这么比较的话，7z的2%和WinRAR的45%确实让人吃惊。我又用7z 16.04开启最高压缩压了一遍。压缩率30%
https://i.loli.net/2019/11/29/R3Dm6cq5InGj1K9.png
压缩率比较 原文件：RAR：7Z=2%：45%：30%
实验比较粗糙，但是7z压缩率确实比WinRAR高不少。不过这个文件如何压到2%，是个谜。
如果有人知道正确的解答麻烦告诉我
对了，7z最高压缩花了 超久
https://i.loli.net/2019/11/29/mHPVSGKrJk6B3YO.png semerita 发表于 2019-11-29 21:58
果然万事还是要自己试一下才知道。
试过之后才知道自己是想当然了。
手动加鹅 semerita 发表于 2019-11-29 21:58
果然万事还是要自己试一下才知道。
试过之后才知道自己是想当然了。
function SevenZipCompress(dir, target, ...inputs) {
return cd(dir).run(
,
[`-t7z`, `-mmt=on`, `-m0=LZMA:a=0:d=256m:fb=256`],
[`../${target.name}.7z`, ...inputs]
);
}
压缩参数 https://github.com/be5invis/Sarasa-Gothic/blob/master/verdafile.js#L88 semerita 发表于 2019-11-29 21:58
果然万事还是要自己试一下才知道。
试过之后才知道自己是想当然了。
我觉得可能是根据字体文件特性选择了对应的算法/字典做的压缩，甚至并不是使用7z软件做出来的压缩包，而是符合7z文件格式的自己重写了压缩算法。 本帖最后由 semerita 于 2019-11-30 02:28 编辑
更新一下
经过24楼朋友的说明，我把GUI里面的三个参数拉到相同。压缩方式LZMA,字典256，词256。
没有想到这么一压，出来了一个8%的结果。
https://i.loli.net/2019/11/30/gWVBSUemZnQ3H4z.png
命令行不熟，就不测了。我觉得这个结果差不多有了解答了。
毕竟这个8%耗费了我3h20m，感觉耗不起。
7z的算法确实比流行的WinRAR要高一些，不过要跑这种极限压缩需要的计算力太惊人了，我用着普通PC感觉是不行。
第一次见是在压缩立绘上看到
----发送自 STAGE1 App for Android. 当年仙剑4破解那个才惊人。。 一直记得以前不少破解版游戏发布者喜欢用一个叫uharc的压缩格式，解压时就是个命令行界面的自解压程序，自己曾经下过一个200还是400M的游戏解压出来1.7G
—— 来自 Sony J9110, Android 9上的 S1Next-鹅版 v2.1.2 感觉tar.gz格式的代码压缩率也比我直接用gzip压的高，不知道是什么原因 7z 默认无法增量添加新文件到压缩包，相当于 WinRAR 的固实压缩。 快速压缩率高的有个zstd 更纱的中文部分主要改自思源，每个TTF都有使用大量共同的数据，好像是glyph set和sharing tables（？我不太了解这块
你看整合TTF的分字重TTC大小就只有479M了
如果像思源的Super OTC那样把各字重合并到一个文件中，就会更小，也就100+M 7za a -t7z -mmt=on -m=LZMA:a=0:d=256m:fb=256 ...
Add new data to archive: 300 files, 6720940804 bytes (6410 MiB)
Archive size: 656414653 bytes (627 MiB)
7za a -t7z -mmt=on -m0=LZMA:a=0:d=1536m:fb=256 ...
Add new data to archive: 300 files, 6720940804 bytes (6410 MiB)
Archive size: 244927501 bytes (234 MiB)
....怒了->
7za a -t7z -mmt=on -ms=512f8g -m0=LZMA:a=0:d=1536m:fb=256
Archive size: 136353165 bytes (131 MiB)
舒服了
lwa190212 发表于 2019-11-30 13:16
7za a -t7z -mmt=on -m=LZMA:a=0:d=256m:fb=256 ... Add new data to archive: 300 files, 6720940804 byte ...
想起以前套三四层的高压缩文件。 starash 发表于 2019-11-30 15:36
想起以前套三四层的高压缩文件。
我个人觉得套三四层不如一层高压，除非算法的实现上做了限制
我回头看了下原来的文件，发现它用的字典是256m的，都是lzma算法，我用1536m+全部固实才做到这个压缩率，无法想像原文件怎么做到的 lwa190212 发表于 2019-11-30 15:55
我个人觉得套三四层不如一层高压，除非算法的实现上做了限制
我回头看了下原来的文件，发现它用的字典是2 ...
的确我也看不明白这楼主的2%是怎么靠256M字典压出来的...
以前需要套三四层就是因为算法有适用范围的限制啊. 正常，这个字体真正的字形就只有100多M
页:
[1]
2