猫史档案馆

压缩算法通常有两种：

第一种是有损压缩算法，常用于音频图片等

第二种是无损压缩算法，常用于文件压缩

这两种算法各有优劣，例如有损压缩可以让文件体积更小，但缺点就是解压之后的数据不是原数据，也就是说如果可执行文件使用这一种压缩算法将无法执行。而无损压缩可以让文件保持完整，但缺点却又是文件大小和压缩速度问题。

先让我们讲讲一些简单的压缩算法

第一种，字典算法：单个文件里通常有重复的地方，比如（文件内容使用十六进制表示，而一般基础的单位是一个字节）ab 8a bd 8a bd 89 ce 1f。不难发现里面有两个8a bd是一样的，这时我们可以使用00这个序号来表示8a bd。但是具体要怎么做呢，首先你得将这个索引存储起来，然后存储它所对应的值（这里的数据比较少，效果可能不明显，假定字典每个索引的长度相同效果可能好得多。），就像这样：00 8a bd，意思大概就是00这个索引代表8a bd。如果把数据替换成索引再加上字典，压缩后的文件看起来想是这样：00 8a bd|ab 00 00 89 ce 1f

第二种，（我也不知道）：简单的说说，就是根据文件中每个字节的位置，先存储字节本身再找它的位置，这样做的话可能需要额外的长度存储

现在就要说说我的困扰

像编程猫这种基于JavaScript类的语言我基本上就不太会用，我试着把值转换成16进制或更高的base来压缩，但我发现根本还不够，在我压缩文件的时候遇到了个问题，我发现编程猫的变量长度不足以容下一些数据，于是只能使用列表存储，但是如果是多人数据的话只靠前面压缩率极低的算法是不够的，并且这么干还会大大增加压缩的难度。之前的一个被我搁置的作品就令我对这个问题印象深刻，作品的名字叫做“网络画板”，允许用户每隔一段时间操作一个像素来达成艺术创作的目的。我先是很快意识到了一个问题，我不可能按照真彩色标准存储我的数据，我尝试使用索引颜色和上面提到的压缩算法，但是不够，因为我发现我无法创建过大的画布，而我不可能让它看起来很小。之后我又发现一个问题，以我的技术能力不足以制作出一个可以正常工作的，依赖列表的压缩算法。

这些就是我遇到有关压缩算法的问题了