我有一个程序，在那里我生成大约80到150位的比特流，我想压缩这些比特流，因为我要把它们转换成某种ASCII字符串，这样人们就可以传送它们了。

有人知道一个好的，自由位意识的压缩机，可能工作在这样的流？我对"标准选项"的主要问题是，这个流实际上应该被视为位，而不是字节，否则结构会丢失，它们的开销会淹没任何收益。

添加：

我想要压缩这些流的原因是因为用户将剪切和粘贴这些流，可能使用类似base64编码的方法，所以保存一些数据是有帮助的。

下面是一个例子，对于那些想看的人来说。我将添加格式以便于阅读：

现在我们列出一些零件

我之所以说这应该被视为"位"，是因为当被视为位流(特别是在"网格"中通常有许多0)时，存在明显的压缩选项，当您将其视为字节流时，压缩选项会消失。

您希望通过压缩150位来完成什么？除非你把这19B条信息加起来，否则我不知道你希望得到什么。这是一个用户界面问题——您希望用户在其中发送/接收"代码"？

Base 64编码怎么样？这将获取二进制数据并将其转换为编码字符，以便于传输或输入。

克里斯，谢谢你寄这些样品。我认为运行长度编码是你想要的方式。这应该是非常简单的实现。

http://en.wikipedia.org/wiki/run-length_编码

将与所有连续的0一起工作良好。

所以压缩这些字符串的主要原因是为了使它们更容易被剪切和粘贴？有道理，听起来是个有趣的项目。

如果你只是想让琴弦更人性化，听起来你已经准备好了。如果您试图压缩它们以便它们通过线更快地传输，我认为压缩小字符串的好处可能会被其他TCP问题(如MTU大小等)所击败。(我在那里没有经验，所以最后一点加上许多盐粒)

祝你好运！

我想没有一个通用的算法可以为这种数据提供很好的压缩。

您最好的选择是分析数据的结构，并尝试找到一个自定义压缩算法，或者可能自定义一个现有的压缩算法(可能使用一个预先填充的字典或者类似的东西)。

我的第一个建议是研究范围编码。而不是

1：将位数据压缩成二进制数据，然后

2：将二进制数据编码成base64 ASCII数据，

您可以将您的位直接打包到0-N范围内(其中N是您使用的可打印字符数减去1)，然后执行一个非常简单的映射。

我的第二个建议是研究PNG使用的过滤方法，并考虑是否可以使用类似的方法来使数据更具可压缩性。很难从两个示例布局网格中分辨出来，但从第一个网格中很可能会发现一些方法，例如"根据其上和左上的相邻点预测每个像素，然后如果满足其预测，则将每个像素转换为0；如果不符合其预测，则将每个像素转换为1"，这样可以为您提供更统一的数据集，从而使GREAter压缩。

我建议您考虑使用zlib。它是可下载的，并且许可证允许您将它用于几乎任何项目。重要的一点是它被广泛使用，因此调试良好。如果您的数据很重要，您不希望将来在随机日期调试hombrew算法中的奇数边缘情况。

我对它做了一些处理，它确实允许面向流的压缩。不过，我不确定一次只提供少量数据有多好。减少损失的压缩通常通过查找和消除模式来工作，如果一次为它提供12个字节之类的小数据，就不会有很多模式需要查找。

我没有说出胡安的答案，因为他还建议使用有损压缩的GIF。您没有提供太多信息，但我猜您不需要任何压缩格式来真正释放数据。最流行的图形、音频和视频压缩算法都是有损的；它们依赖于人类感官的能力，以适当地接收图像或声音，并删除或修改一些原始信息。

因为小溪很小，你能在这里贴一些吗？

另外，您确定这些流中有足够的冗余来允许压缩吗？是否有重复的数据块？

这是一个漫长的过程，但是在没有任何具体答案的情况下，你可能会想看看ROM场景，看看文本串是如何在基于盒带的RPG游戏中被压缩的，比如"Chrono Trigger"或"Final Fantasy III"。我知道文本串是在那些游戏中被压缩的(字节在那些日子里是如此珍贵)，并且被分解的。这个计划对黑客来说是一个有趣的挑战。当你提到许多被压缩的短字符串时，这是我唯一想到的事情。

不过，您的根本问题可能仍然存在。我可以想象，这些ROM中的压缩方案利用了多个字符串之间的冗余(例如，如果"Timbuktu"出现在58个不同的字符串中)，而不是在单个流中。

JBig可能会给你所需要的。

网址：http://en.wikipedia.org/wiki/jbig

网址：http://www.jpeg.org/jbig/index.html

http://www.cl.cam.ac.uk/~mgk25/jbigkit/

jbig用于压缩1-bpp传真图像。

CCITT的第3组和第4组无损编码方案用于压缩G3和G4 TIFF，设计时考虑了二进制数据。G4 TIFF是黑白图像，通常用于OCR和传真。另一个简单的方案是RLE。

只是为了补充已经说过的话，"压缩少量数据"本质上不是有点毫无意义吗？如果您能详细说明数据、平台或可能有帮助的用途。

至于bits和ascii，我不完全确定你在做什么，但是正如michael所提到的，base64提供了一种使任意二进制更加友好的方法。

注意，任何从二进制转换成ASCII的过程都与压缩相反。

我和蒂姆有同样的想法——这么少量的数据似乎几乎不值得压缩。事实上，我建议您真正想研究的是某种ASCII编码方法，比如Uuencode或mime encode(又称"base64")。

您需要的是无损二进制压缩。我相信，如果没有大量的其他资源的话，一定有论文或网络文章。谷歌这些条款，我怀疑你会得到你需要的。

你在说多少数据？你的管道是小的还是流量大到你不得不压缩？

回想起来，您的数据非常小，除非您分析流量并进行自己的"压缩"，否则可能无法获得有价值的收益，这基本上只是已知位模式的映射/散列。

正如别人所说，发布一些样本数据，之后可能会有更好的建议。

zlib压缩(可能与gzip的算法相同)是免费的。它有一些设置，但我不确定您可以节省多少，除非您的位有一些周期性的模式。

由于PNG和GIF图形文件本质上是位模式的表示，也许您可以找到它们使用的压缩算法。