我正在寻找一种压缩算法，它可以处理小于一个字节的符号。我对压缩算法做了一个快速的研究，很难找出所用符号的大小。总之，有一些符号小于8位的流。是否有用于deflate定义其符号大小的参数？

小于字节的纯文本符号好的。

LZ77和LZ78的原始描述用十进制数字序列(大约是字节大小的一半的符号)来描述它们。好的。

如果你用谷歌搜索"DNA压缩算法"，你可以得到一堆专门用于压缩文件的算法的信息，这些压缩文件几乎完全由4个字母A G C T组成，一个由4个符号组成的字典，每个符号的大小约为1/4。也许这些算法中的一个对您的影响相对较小。好的。

LZMA中使用的LZ77样式的压缩对于它压缩的前几个符号来说，似乎每个符号使用两个字节。但在压缩了几百个纯文本符号之后(自然语言文本的字母，或十进制数字的序列，或代表DNA碱基的4个字母的序列等)，LZMA输出的双字节压缩"块"通常代表十几个或更多的纯文本符号。(我怀疑所有类似的算法都是一样的，例如deflate中使用的LZ77算法)。好的。

如果您的文件只使用比所有256个可能字节值小得多的受限字母表，原则上，程序员可以修改deflate的变体(或其他一些算法)，它可以利用字母表的信息生成比标准deflate压缩的相同文件小几位的压缩文件。然而，许多面向字节的文本压缩算法——lz77、lzw、lzma、deflate等——构建了一个常见的长字符串字典，并可能在该自定义适应变量的百分之几内提供压缩性能(具有足够大的源文件)——通常使用标准压缩文件格式的优点值得牺牲一个潜在空间节省的百分之几。好的。

小于字节的压缩符号好的。

许多压缩算法，包括对基准文件进行最著名的压缩的一些算法，逐位输出压缩信息(例如大多数PAQ系列的压缩器和一些算法编码器)，而其他算法则输出不考虑字节边界的可变长度压缩信息(例如Huffman Compressio)。n)。好的。

一些描述算术编码的方法涉及到一些信息片段，例如单个的位或像素，它们被压缩成"少于一位的信息"。好的。

编辑："计数参数"解释了为什么不可能将所有可能的字节(更不用说所有可能的字节和几个常见的字节序列)压缩成长度都小于8位的代码字。尽管如此，一些压缩算法可以并且通常确实表示一些字节或(更罕见)一些字节序列，每个字节的代码字长度小于8位，通过"牺牲"或"转义"以其他代码字(包括escape")的长度超过8位。好的。

这些算法包括：好的。

• 使用4位编码的PIKE文本压缩
• 面向字节的哈夫曼
• 执行LZ77的几种组合算法，如将文件解析为"符号"，其中每个符号表示一个字节序列，然后Huffman压缩这些符号，如deflate、LZX、LZH、LZAM等。

PIKE算法使用4位"0101"表示"e"(或在某些上下文中使用"e")，8位"0000 0001"表示单词"the"(4个字节，包括前面的空格)(或在某些上下文中使用"the"或"the")等。它有一本大约200个最常见的英语单词的小词典，包括16个非常常见的英语单词的子字典。好的。

当使用面向字节的哈夫曼编码压缩英文文本时，序列"e"(e空间)被压缩为两个码字，总共通常为6位。好的。

唉，当涉及到哈夫曼编码时，我不能告诉你这些"小"码字的确切大小，甚至不能确切地告诉你一个小码字代表什么字节或字节序列，因为每个文件都不同。通常，同一个代码字表示同一文件中不同位置的不同字节(或不同的字节序列)。解码器根据压缩程序在头中留下的线索以及到目前为止解压缩的数据来决定代码字表示的字节或字节序列。对于范围编码或算术编码，"码字"甚至可能不是整数位数。好的。好啊。

你可能想研究一个golomb代码。golomb代码使用分而治之的算法来压缩inout。这不是字典压缩，但值得一提。