google 的 br 压缩算法是真的强。

Facebook 哪里惨了，混得更厉害好不好。zstd 都进 Linux 内核了，各种底层例如文件系统和包管理都已经使用了。

Chrome 不支持是因为未接受为 Web 标准而已。

br 默认是针对 web 优化的（例如 html 标签），zstd 数据量大才有效果，web 这类小文件肯定选 br 啊

我嵌入式 linux 跑 busybox httpd 服務器，把所有文件壓縮成 gzip 格式，然後刪掉原始 html 、js 、css 、圖片 等數據，瀏覽器會自動下載壓縮版本的文件（原理是瀏覽器請求服務器文件的時候，會告訴服務器可以返回哪些格式的壓縮算法，只有所有算法服務器都不支持，才返回未壓縮的原文件）

其它壓縮格式主流瀏覽器默認不會都支持吧？一般都是 gzip 兼容性最好吧

至於通用壓縮，我一般用 3 種：tar 、tar.bz2 、tar.xz

tar 其實沒有壓縮，只是打包

tar.bz2 兼顧壓縮率和壓縮解壓速度

tar.xz 是極致壓縮，壓縮解壓速度慢一些

你可以對比一下 tar.xz 的壓縮率和你說的 br ，看哪個更強

文本压缩的话，PPMd 还是最无敌的。

zstd 不适合 web zstd 主要的优势是快而不是压缩率
br 的速度肯定没办法和 zstd 比 但是压缩速度对 web 而言没那么重要 尤其是静态资源
br 就是专门为 web 优化的算法

@duke807 br 是压缩慢但是解压缩还是比较快的而且不太占资源
xz 如果是高压缩率的话 压缩和解压都太慢 而且太占资源了 不太适合浏览器

压缩速度和计算资源消耗是 web 压缩最重要的指标啊，远比压缩率重要
所以 xz bz2 都不适合 web 压缩
br 的优势在于两端有预置的字典，能在小文件（几十到几百 K ）条件下的流压缩做到很高的压缩率
br 的优势也仅限于 web ，和 zstd 不是一个方向

个人感觉这个数据反而说明 7z 更厉害啊

@duke807 "一般都是 gzip 兼容性最好吧", 我搜了一下，浏览器对于 br 兼容性意外的好，可能是 br 算法出的早，是 2013 年出的。再过两年，就十周年了。

还有如果你真的喜欢 gzip ，那还是推荐用 google 家的 zopfli 。

我就没见过比 zopfli 更强的 gzip 压缩算法，在压缩率上面，可谓举世无双。

@tcp 7z 超强压缩是出了名的慢，不提了，伤感。

@3dwelcome 這裡說 ios 瀏覽器不支持 br：
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding

服務器端，我提到的 busybox httpd 也只支持 gzip

還有，我想說的是，其實 web 壓縮有和無區別很大，用 br 取代 gzip 感覺額外帶來的好處也不多，譬如我一個項目，前段時間聽取了用戶建議，才知道把一個 3.5 MB 的 wasm 文件用 gzip 壓縮到 1.5M 左右，比一半還小，其它文件也全部壓縮了一下，改善很大，如果用 br 估計也不會小，就算壓縮到 1.4M ，改善也不大

@duke807 用 br 没准能压倒 1.0M 以下，这新算法比 zip 厉害太多了。

用 google zopfli 的 gzip 算法，也能减少 10%的大小，这是基本上是恒定的。

@3dwelcome 上面有人說 br 是專門針對 html 等文本優化的，wasm 是二進制程序，用 br 沒有優勢

不知道 zopfli 是啥，我用 gzip 是直接用 gzip 命令，一個命令所有文件都壓縮好了，linux 環境

@duke807 “上面有人說 br 是專門針對 html 等文本優化的”

昨晚实测，br 能把 gzip 后的二进制文件都再压缩一大截。

按理说 gzip 已经是压缩格式，不能二次压缩，可就和 winrar 能压缩 zip 原理一样，br 也能。

zopfli 是 google 的 gzip 定制版压缩算法。压缩的时候，内部可以设置递归参数(iterator)，能恒定减少生成 gzip 的体积。所谓恒定，就是对于任何 gzip 文件，用 zopfli 都能少个 10%。

这个测试图，怎么生成的

@linglin0924 https://chartcube.alipay.com

我觉得 zstd 用的范围更广。目前可以用在 Linux 内核镜像压缩、ZFS/BtrFS 透明压缩、PKZIP （ zip 文件规范）可选编码算法、deb/Arch 软件包压缩算法。brotli 目前主要就浏览器和 Android OTA 包在用。
7z 默认算法是 LZMA/LZMA2 ，也就是 xz 用的算法。LZMA 是典型用于极限追求压缩率的场景，例如冷存储和路由器 ROM 之类需要极限紧凑无所谓慢的场合。要速度都不会用这个。zstd 在此的对比优势是在高压缩级别能达到 LZMA 近似的压缩率（通常还是大一丢丢）但解压更快。
brotli 有一个硬编码的静态字典，zstd 没有，但可以训练生成一个定制字典。也就是说 brotli 的高效是建立在对输入内容有偏向性假设的前提上的。所以我不否认 Web 内容上 brotli 是个好的选择。至于 brotli 和 zopfli 选哪个看你网站的客户端统计吧，或者全都要。
另外我不知道你图里的 zstd 是不是用默认的 3 级压缩，你有没有试过 19 级？

@timpaik
RFC8478/RFC8878 已经标准化 zstd 对应的 HTTP Content-Encoding 和 MIME ，想用都是能用的。
Chromium 拒绝支持竞争技术也不是一天两天的事了，到现在都没支持 HEVC 。

@jim9606 大佬好专业，真是涨姿势。

zstd 有命令行，就无脑选了 19 级，压缩速度是真快。好像听说游戏资源压缩里，用的也比较多。