专门针对 HTML 内容优化的压缩算法？答案

【问题标题】：Compression algorithms specifically optimized for HTML content?专门针对 HTML 内容优化的压缩算法？
【发布时间】：2010-03-10 17:22:53
【问题描述】：

是否有任何压缩算法（有损或无损）专门适用于处理现实世界（混乱和无效）的 HTML 内容？

如果不是，我们可以利用 HTML 的哪些特性来创建这样的算法？潜在的性能提升是什么？

另外，我不是问提供此类内容的问题（通过 Apache 或任何其他服务器），虽然这当然很有趣，但要存储和分析它。

更新：我不是指 GZIP——这很明显——而是一种专门旨在利用 HTML 内容特征的算法。例如，可预测的标签和树结构。

【问题讨论】：

有损？
不，在某种意义上是有损的：
whatever wordwhateverwhatever 可能变成：

whatever wordwhatever
...就像 tidy 维护结构并清理页面代码一样。
据我了解，大多数压缩算法都是基于内容的统计重复。开始和结束标签落在这些边界内，任何体面的现成压缩算法就足够了，因为毕竟 HTML 都是 ASCII。我不确定您要对存储的数据运行哪种类型的分析，但一个重要的方面是在您可以对其进行分析之前，此类压缩内容所涉及的解压缩成本。

标签： html algorithm compression

【解决方案1】：

我不知道“现成的”压缩库明确为 HTML 内容优化。

然而，HTML 文本应该使用通用算法很好地压缩（请阅读此答案的底部以获得更好的算法）。由于特定语言习语的高度重复性，Lempel–Ziv 的所有变体通常在类 HTML 语言上表现良好； GZip，经常被引用使用这种基于 LZ 的算法（我认为是 LZ77）。

改进这些通用算法的一个想法是使用最常见的 html 标记和模式来初始化 LZ 类型的循环缓冲区。以这种方式，我们将通过使用这种模式的第一个实例中的引用来减小压缩大小。这种增益对于较小的 html 文档尤其敏感。

一个互补的、类似的想法是让压缩和解压缩方法暗示（即不发送）LZ-x 算法的其他压缩算法的信息（比如 LZH 等情况下的霍夫曼树），使用特定于典型 HTML 的统计数据，小心地从字符中排除按引用编码的字符的 [统计加权] 实例。这种过滤后的字符分布可能会比完整的 HTML 文本更接近纯英语（或目标网站的国家语言）。

与上述[受过教育，我希望]猜测无关，我开始在网上搜索有关此主题的信息。

' 由弗罗茨瓦夫大学的 Przemysław Skibiński 发现 2008 scholarly paper (pdf format)。该论文的摘要表明比 GZIP 提高了 15%，压缩速度相当。

否则我可能会找错地方。对此似乎没有太大的兴趣。可能只是相对于普通或适度调整的通用算法的额外收益被认为不足以引起人们的兴趣，即使在支持 Web 的手机的早期（当带宽非常昂贵时）。 .).

【讨论】：

【解决方案2】：

Brotli 是一种专门的 HTML/英文压缩算法。

来源：https://en.wikipedia.org/wiki/Brotli

与大多数通用压缩算法不同，Brotli 使用预定义的 120 KB 字典。字典包含超过 13000 个常用词、短语和其他子字符串源自一个大型文本和 HTML 文档的语料库。[6][7]预定义的字典可以为短数据文件提供压缩密度提升。

【讨论】：

【解决方案3】：

关于我愿意在 HTML 内容中处理的唯一“有损”，无论是否混乱，是空白展平。这是大容量网站对其内容执行的典型发布后步骤，也称为扁平化。

您还可以使用 YUI 压缩器扁平化大型 Javascript 库，它将所有 Javascript 变量重命名为短名称、删除空格等。这对于使用 ExtJS、Dojo 等工具包的大型应用程序非常重要。

【讨论】：

【解决方案4】：

gzip 压缩不足以满足您的需求吗？它为您提供大约 10:1 的压缩比，不仅适用于 HTML 内容，也适用于 JavaScript、CSS 等 文件，并且在大多数服务器或反向代理（例如Apache's mod_deflate、Nginx's NginxHttpGzipModule 等）和所有现代浏览器上都可用（您可以指示 Apache 和 Nginx 跳过基于 User-Agent 的特定浏览器的压缩。）

您会惊讶于gzip 压缩达到最佳状态的程度。 有人建议minifying你的文件；但是，除非您的文件包含大量 cmets（压缩程序可以完全丢弃它们，即您可能称之为“有损”的内容）——但您可能不想对 HTML 做任何事情，除非您确定你的<script> 或<style> 标签都没有在HTML cmets  中以适应旧时代的浏览器），请记住，缩小从类似于DEFLATE 的技术中获得了大部分收益（但比DEFLATE 更有限——所以期待比gzipped 原始文件更大或远大于的缩小文件（对于 HTML 尤其如此，在其中您会被 W3C 的标签和属性所困扰，只有 gzip 可以帮助您），并且 gzipping 一个缩小的文件将给你带来比gziping 原始文件最小的收益（同样，除非原始文件包含许多可以被缩小器安全丢弃的 cmets。 )

【讨论】：

gzip 就足够了，但我是一名计算机科学家——我想要最优。 :)
我认为问题更像是“我知道我可以通过删除多余的空格来压缩 HTML，我可以执行哪些其他压缩技术并且仍然具有有效的 HTML？”
不是在最初发布问题（和 gzip 答案）的时候。此外，我清楚地表明非 gzip 技术在大多数情况下是徒劳的。您可能没有仔细阅读该帖子，但也解决了“...还有哪些其他技术...”，即删除 HTML cmets。

【解决方案5】：

改用 S 表达式，为每个标签节省大量字符 :)

【讨论】：

【解决方案6】：

如果我正确理解您的问题，您需要的是 gz 压缩，Apache 很容易使用它。

【讨论】：

+1：Gzip 针对文本内容进行了优化，而 HTML 通常只是简单的 ASCII。有一些 Apache 模块可以即时 gzip。

【解决方案7】：

通过一些 HTML minificator/obfuscator 运行您的代码，尽可能多地删除标记，然后让您的网络服务器使用 gzip 对其进行压缩。

【讨论】：

【解决方案8】：

不，没有任何特定于 HTML 的压缩算法，因为事实证明通用的压缩算法就足够了。

潜在的收益来自于提前了解 HTML 页面的可能元素 - 您可以从预定义的字典开始，该字典不必是压缩流的一部分。但这不会带来明显的收益，因为压缩算法非常擅长动态挑选常见的子表达式。

【讨论】：

【解决方案9】：

您通常会使用一种通用算法，例如 gzip，大多数浏览器都通过 HTTP 协议支持该算法。 Apache documentation 展示了如何在不破坏您网站的浏览器支持的情况下启用 mod_deflate。

此外，您还可以minimize static HTML files（或动态执行此操作）。

【讨论】：

【解决方案10】：

您可以将每个唯一分组（即标签和属性）视为一个符号，确定最小符号数并使用香农熵重新编码；这将生成一个具有最大压缩率的大字节字节。我会说这可能并不比gzip好多少。

【讨论】：