压缩字符串

你不能以保证的方式做到这一点。20字节的序列可能比10字节的序列多得多——所以你不可能把每个20字节的序列可逆地压缩成10字节。

一般来说，对于非常小的输入长度，压缩通常不能很好地工作。

如果你知道你所有的输入实际上是(比如说)A-Z加空格(即27个字符)，那么那就是5位…所以总共只需要100比特。这仍然比您可用的80位多一点，所以您仍然不能保证表示所有句子。不过，你可以让"普通"字符比"不寻常"字符短，这样很多句子就可以用这种方式工作了。

在不知道真正需要实现什么的情况下，很难更具体，因为原始需求是不可能实现的。

大多数情况下，您想要的应该是可能的，但我可以保证问题。如果您使用GZipStream类编写一个方法，它可以获取您拥有的170字节字符串并减少它。就像大多数人说的，压缩比实际上取决于内容本身。

作为测试:我取了一个重复17次的字符串"0123456789"(170个字符)，压缩它，它减少到21个字符。
如果我取一个170个0的字符串并压缩它，它会被压缩到12个字符。我取了170字节的随机代码，它被减少到79个字符。

所以在这些情况下，它会压缩它以适应你的空间要求;但没有办法预测何时以及多久不会发生这种情况。压缩比最终可能是1:1，并且在创建块结构时存在固有的开销，因此它实际上可能导致压缩长度略大于原始长度。然后，您可能必须对整个内容进行base64编码以使其正确地存储在DB中，因此这会进一步增加您的开销。

不能，压缩比取决于字符串本身的内容。即使可以压缩序列，也必须在服务器上实现解压缩。但是，如果您可以访问服务器，您可以简单地将序列分成许多部分。

你的问题很严重。20个字节是160位是2^160个可能的消息。十个字节等于80位，也就是2^80个可能的消息。除非您有办法将源消息空间减少到仅包含2^80条可能的消息，否则您不能这样做。

如果消息是静态的，则将索引传递到包含可能发送的不同消息的数组中，而不是传递消息。如果它们是动态的，那么这是不可能的，除非您可以将自己限制在ASCII的有限子集中并在一个字节中存储多个字符，或者字符串非常重复，在这种情况下，您可以考虑运行长度编码。