我正在开发一个消息系统，并且想法将消息独立存储在每个收件箱中。在研究这个想法时，我问自己为什么不压缩消息。所以我正在寻找一种用不同语言学习词典的好方法。
由于这些消息与日常交谈密切相关（社交活动），我需要一个良好的来源和方式。
我需要一些文本，就像数百万封电子邮件，书籍等。我想用它创建一个霍夫曼树，能够内嵌并将每条消息表示为这个霍夫曼树中的字符串。因此解码速度足够快。
我想要使用的语言就在那里。由于报纸等可能还不够，我还需要其他方法。
[更新]
当我计算我的研究时，我注意到我实际上是从维基百科中创建了两个词典。首先是包含具有一定可预测性的典型字符的字典。另外我注意到我用于每种语言接缝的特殊字符甚至可以在基于语言的语言中分配（实际上，latain只是语言家族中的一个成员）甚至俄语人员往往在完全不同的字母表旁边具有相同的分布。
另外我注意到大约15％到18％的特殊角色（比如''，'，'，';'）跟随另一个特殊角色。并且通过比前8个最频繁的单词产生10％，其中接下来的16个单词产生9％并继续进行，并且大约128个（160个单词），你达到所有单词的80％的产率。因此，存储接下来的256个单词，在分析方面变得毫无意义。这让我落后于每个语言大约2到5KB的三个词典（字符，单词，特殊字符）（我使用特殊格式来使用前缀压缩），这使我在字符缩减方面节省了30％到60％，并且当你还记得在Java中，每个字符存储16位，通过压缩（霍夫曼树）必须插入的字符，导致整体减少甚至更多，使其为1：5到1:10。
使用这样的系统并将数字压缩为可变长度整数，可以生成一个可用于字符串匹配的字节数组，加载速度更快，检查要包含的单词比逐字符比较更快，因为可以检查完成通过不需要首先标记或识别单词来更快地使用单词。
它解决了支持字符串键的问题，因为我只能转换每种语言的字符串，它会产生一组可用于查找的键。