域名压缩

我对如何紧凑压缩任意IDN主机名（由RFC5890定义）的域感到好奇，并怀疑这可能会成为一个有趣的挑战。Unicode主机或域名（U标签）由一串Unicode字符组成，通常取决于顶级域名（例如，下的希腊字母.gr），被限制为一种语言，该Unicode字符被编码为以xn--（一个标签）。

人们不仅可以根据以下正式要求来建立数据模型：

• 每个非Unicode标签都是一个字符串匹配^[a-z\d]([a-z\d\-]{0,61}[a-z\d])?$；

• 每个A标签都是一个字符串匹配^xn--[a-z\d]([a-z\d\-]{0,57}[a-z\d])?$；和

• 整个域的总长度（A标记和非IDN标记以“。”分隔符连接）不超过255个字符

而且还来自各种启发式方法，包括：

• 低阶U标签在某些自然语言中通常在词法，句法和语义上都是有效的短语，包括专有名词和数字（连字符除外，不加标点，去除空白并按Nameprep折叠），偏爱较短的短语；和

• 高阶标签是从SLD和TLD的字典中​​提取的，并为预测低阶标签中使用哪种自然语言提供了上下文。

我担心，如果不考虑数据的这些特定特征，很难对这样的短字符串进行良好的压缩，此外，现有的库将产生不必要的开销，以适应其更一般的用例。

阅读Matt Mahoney的在线书《Data Compression Explained》，很显然，可以利用许多现有技术来利用上述（和/或其他）建模假设，与不那么具体的工具相比，它们应该带来更好的压缩效果。

就上下文而言，此问题是SO上一个问题的分支。

最初的想法

令我惊讶的是，这个问题是脱机培训的绝佳选择，我设想了以下几行的压缩数据格式：

• 霍夫曼编码的“ 公共后缀 ”，其概率来自域名注册或流量的某些公开来源；

• 其余的U标签使用霍夫曼编码（自然语言）模型，并从给定的域后缀上下文中某些已发布的域注册或业务量来源中提取概率；

• 应用来自指定自然语言模型的一些基于字典的转换；和

• U标签中每个字符的算术编码，其概率来自脱机训练（甚至可能是在线，但我怀疑数据可能太短而无法提供任何有意义的见解？）的上下文自适应自然语言模型。

霍夫曼编码最适合字母，当然可以适应序列。例如，如果序列“ ab”产生的位数少于“ a”和“ b”的位数，则只需将其添加到树上，依此类推。

...您可能还可以使用一些简单的库，以几乎最佳的性能为您完成所有这些工作，因此使用定制的超豪华压缩算法不会带来太大收益。