是否需要使用清晰的代码启动gif帧数据流？

规范没有明确说明：

清除代码可出现在以下位置： 图像数据流中的任何点，因此需要LZW算法 处理后续代码，就像启动新数据流一样编码器应 输出清晰代码作为每个图像数据流的第一个代码。

“应该”听起来不像是一个要求。如果我上一个框架的代码表是最优的，并且我希望重用它，那么我为什么要费心重新创建同样的东西，并浪费最终的文件大小呢？事实证明，此帧与前一帧相同（只是不同的xy），并且仅在第二次迭代中就将缩小近25%。在重复使用代码表的过程中，我仍然不会达到12位的最大值，而且我可以粘贴此帧的副本，每个副本只需几个字节

但到目前为止，大多数观众并不同意。Chrome毫无怨言地加载它，但显示一个空白的白色选项卡。OSX预览抱怨它的格式不正确。Gimp将第二帧显示为一个层，但带有乱码的像素数据。。。我只使用了8种颜色，但是颜色选择器工具显示像素的索引值为143、18、44等等（此时代码表中似乎没有这些值……当索引143出现时，我最多只能看到98个代码）

如果这些实现没有正确遵循规范，那么我可以测试哪些其他实现？什么是最有可能遵循它的信件

“应该”听起来不像是要求

是的，规范使用了“应该”而不是“必须”。但无论第一个代码是否是“清晰”代码，编码器和解码器之间都应该有一个契约。由于GIF图像不随压缩流一起保存字符串表，“LZW”解码过程必须从初始化的字符串表开始重建原始表。此初始表来源于我们对当前帧可能像素值数量的了解，并将其转换为“最小代码长度”，放在“LZW”流的正前方，它是“LZW”译码器处理字符串表所需的唯一信息

事实是，即使在LZW解码开始时GIF编码器没有发出“清晰代码”，任何GIF（LZW）解码器“必须“在使用从输入读取的最小代码长度值开始解码LZW流之前，初始化它的字符串表。这在编码器和解码器之间形成契约，并保持编码器和解码器同步

如果如您所说，您希望保留上一个字符串表，甚至下一帧与上一帧完全相同，那么编码器和解码器将不会使用相同的字符串表。这就是为什么当你测试你的方法时，你会看到所有奇怪的行为

因此，除非GIF规范更改为保存字符串表，否则您的方法将无法工作