这是一个创建于 1578 天前的主题，其中的信息可能已经有所发展或是发生改变。
我想预定义一些文字让压缩更为高效，有什么方法可以在浏览器里实现这个
我想让用户可以将分享数据带在链接中，我在浏览器这段收到后再重新展示出来 分享数据如：龙王+猴子+风女，我就预定义这些文字在压缩算法中，使得压缩后的字节尽可能小，最后就算带在链接里也不会太长，便于复制和分享
第 1 条附言 · 2020-08-05 15:53:59 +08:00
预定义字典应该就是我想要的，只是苦于不知道关键词于是前来提问，避免重复造轮子
炉石分享套牌的场景和我的场景类似，不过我是分享云顶之弈的阵容组成
炉石分享套牌的场景和我的场景类似，不过我是分享云顶之弈的阵容组成
 |
1
GeruzoniAnsasu 2020-08-05 14:54:08 +08:00
本来想说 gzip 压纯文本比替换关键字好多了
看了半天觉得不对劲 然后想说难到不是把关键字用枚举值表示就 ok 了吗 好像又不是这么回事 又想说短链接把内容放库里链接给个 hash 不就完了吗 好像也不是这么回事 一个 AB 问题让人猜 A 是什么真的很困难 到底要分享什么样的数据？结构化的吗？关键字组合？段落文本？纯前端无后端吗（不然为啥数据都要带在 url 里 |
 |
2
misdake 2020-08-05 15:01:08 +08:00  1
如果需要在浏览器里解压，那么解压算法就必须知道这几个词。需要下载的应该一个定制的压缩算法和一个预定义字典。
我觉得和正常的压缩算法相比，压缩比提高不了多少，不可能抵消掉压缩算法+预定义字典的下载体积和时间。 另外根据你提供的例子，可能可以用二进制内容直接做。 |
|
3
misdake 2020-08-05 15:04:59 +08:00 1
我猜类似炉石分享套牌的方法可能比较合适，可以搜一下。
|
 |
4
futou 2020-08-05 15:27:59 +08:00 1
你的问题太不明确了，使用场景不清晰。
更重要的是如何衡量“高效”。如果和用户间只传输少量特定关键字，提前约定几个枚举值就 ok 了，既简单又高效。然而这种方法的缺点非常明显：需要提前 or 同时传输你们的约定（我们一般叫码书）。你们的约定越多，码书规模就越大。 夸张点就是你提前送给用户一个词典，用户和你之间的对话翻译成每个字在字典中的页码和行数。如果你们用的字来来回回就几十个，那这个字典就很小，如果你们可能用到的字上万个，字典就会非常大，以至于每个字翻译成的页码和行数大大超过字本身的信息量。 在图像压缩里面有矢量量化、字典学习等方法可以实现对码书 /字典的设计与最优化。 不过事实证明，对于自然图像压缩（相当于你和用户可能用到的关键字无限多的情况），这些方法的压缩表现远不及用了几十年的预测变换量化熵编码。 |
 |
5
shynome OP |
 |
6
xqdoo00o 2020-08-05 16:56:44 +08:00 1
zstd 应该 符合 你的需求。
字典对小文件的压缩比有很大的影响，所以 Zstandard 可以使用用户提供的压缩字典。它还提供了一种训练模式，能够从一组样本生成一个字典。[12][13] 特别是，可以加载一个字典来处理文件之间具有冗余的大型文件集，但不一定在每个文件（例如日志文件）内。 -- 摘自 wikipedia |
 |
7
hyperbin 2020-08-05 18:53:49 +08:00 via Android
就一个问题：谁维护关键字？
|
 |
8
ysc3839 2020-08-06 02:29:56 +08:00
有点像 HTTP/2 的 HPACK 算法？这个就是预定义了一份常用的 HTTP 头。
https://tools.ietf.org/html/rfc7541#appendix-A |
Select Language