Algorithm LZW算法变长译码过程中的问题 设置

说我有：

• 位图LZW压缩产生的一系列数字：

  256 1 258 258 0 261 261 259 260 262 0 264 1 266 267 258 2 273 2 262 259 274 275 270 278 259 262 281 265 276 264 270 268 288 264 257
  

• 由TestStream（包括LZW代码大小标头和子块标记）编码的LZW压缩、可变长度，表示相同的数字序列：

  00001000 00101001 00000000 00000011 00001000 00010100 00001000 10100000 
  01100000 11000001 10000001 00000100 00001101 00000010 01000000 00011000 
  01000000 11100001 01000010 10000001 00000010 00100010 00001010 00110000 
  00111000 01010000 11100010 01000100 10000111 00010110 00000111 00011010 
  11001100 10011000 10010000 00100010 01000010 10000111 00001100 01000001 
  00100010 00001100 00001000 00000000
  

• 以及

  初始代码宽度
  为
  8
  

问题 我试图从ByTestStream中导出初始的数字序列（整数数组）

根据我所读到的，这里的过程是取

初始代码宽度

，从右向左扫描，一次读取

初始代码宽度+1位，从ByTestStream中提取整数例如：

iteration #1:   1001011011100/001/    yield return 4
iteration #2:   1001011011/100/001    yield return 1
iteration #3:   1001011/011/100001    yield return 6
iteration #4:   1001/011/011100001    yield return 6

此过程不适用于迭代#5，迭代将产生1：

iteration #5:   1/001/011011100001    yield return 1 (expected 9)

代码宽度应该增加1

问题
在读取由TestStream编码的可变长度时，我如何知道何时增加代码宽度？我是否拥有解压缩此ByTestStream所需的所有信息？我在概念上遗漏了什么吗

更新：
在与灰胡子进行了长时间的讨论之后，我发现我没有正确地读取二进制字符串：
00000000000011000
将被解释为
256，1
。ByTestStream不是作为big-endian读取的

粗略地说，如果你在解码一个ByTestStream，你每次读取2^N-1个代码时都会增加读取的位数，其中N是当前的代码宽度。
解压时，你应该以与压缩器大致相同的方式构建字典。您知道，一旦压缩器使用的代码比当前宽度过宽，就需要增加代码宽度

只要字典未满（未分配最大代码），则为输出的每个（常规）代码（不是清除代码或信息结束代码）分配一个新代码

在您链接的示例中，当第二个
6
被“传输”时，将分配
8
——您需要在读取下一个代码之前切换到四位

（这就是示例和您的
数字系列
的不同之处-链接显示
4,1,6,6,2,9
）
解压缩时，您应该以与压缩器大致相同的方式构建字典。您知道，一旦压缩器使用的代码比当前宽度过宽，就需要增加代码宽度

只要字典未满（未分配最大代码），则为输出的每个（常规）代码（不是清除代码或信息结束代码）分配一个新代码

在您链接的示例中，当第二个
6
被“传输”时，将分配
8
——您需要在读取下一个代码之前切换到四位

（这就是示例和您的
数字系列
的不同之处-链接显示
4,1,6,6,2,9
）
FYI-这不是我的家庭作业。如果字母表是十进制数字，
初始代码宽度为2
如何工作？还是{4,1,6,9}？（为什么要处理3位的组？@greybeard初始代码宽度为2，因为完全解压缩的结果是一个包含整数0到3的数组<代码>[4,1,6,6,9…]

表示将值打包到可变长度编码流之前的LZW编码序列。请在示例中包含“纯文本”。根据实现/约定的详细信息，第一个代码可能足够短，仅编码一个源符号。每次在字典未满时输出一个代码时，都会分配另一个代码：可能的输出代码数量会增加。如果这些由固定字母表中的整数个符号表示（例如，二进制为{0，1}），则该数字可能需要增加。解码器跟踪字典，包括可能的代码数：它将知道3位到

6

，以及

9

中的4位（查看“相关”列，尤其是…）仅供参考-这不是我的作业。如果字母表是十进制数字，那么

初始代码宽度为2

如何工作？还是{4,1,6,9}？（为什么要处理3位的组？@greybeard初始代码宽度为2，因为完全解压缩的结果是一个包含整数0到3的数组<代码>[4,1,6,6,9…]表示将值打包到可变长度编码流之前的LZW编码序列。请在示例中包含“纯文本”。根据实现/约定的详细信息，第一个代码可能足够短，仅编码一个源符号。每次在字典未满时输出一个代码时，都会分配另一个代码：可能的输出代码数量会增加。如果这些由固定字母表中的整数个符号表示（例如，二进制为{0，1}），则该数字可能需要增加。解码器跟踪字典，包括可能的代码数：它将知道3位到

6

，以及

9

中的4位（查看“相关”列，尤其是…），只是为了澄清，在什么时候切换到更大的宽度上没有选择的可能。这听起来与我的问题无关。我的LZW编码器和LZW解码器都工作正常，正如我前面多次提到的。非常清楚：我使用索引流

[1,1,1,2,2,0,0，…]

并使用LZW编码器将其转换为代码流

[4,1,6,6,9，…]

。我还可以使用LZW解码器将码流转换回索引流。我的问题是将代码流打包到一个新的字节数组中，并将字节数组解包到代码流中。撇开态度不谈：第二个

6

（最低/第一个附加代码）对于任何不以5个标识符开头的输入序列都是错误的