压缩少量数据

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

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

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

http://en.wikipedia.org/wiki/Run-length_encoding

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

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

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

祝你好运!

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

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

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

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

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

既然溪流这么小,你能在这里贴一些吗?

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

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

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

我的第一个建议是你调查 range encoding . 而不是

1:将位数据压缩成二进制数据,然后

2:将二进制数据编码成base64 ASCII数据,

你可以直接把你的位压缩到0范围内。- N (何处) n 是您正在使用的可打印字符数减1),然后执行完全简单的映射。

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

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

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传真图像。

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

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

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

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

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

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

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

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

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

注意 任何 从二进制转换为ASCII与压缩相反。