PNG 文件格式的 IDAT 块

我目前正在开发一种基于 png 文件格式的专有文件格式。到目前为止我已经完成了，只是它不起作用:-p 我实现的 deflate 解压缩器工作起来就像一个魅力，但 png 解码器不想很好地执行，所以我看了一下原始的 png 文件。

该标准规定，在 IDAT 标头之后，紧随其后的是压缩数据。因此，由于数据是压缩流，IDAT 之后的第一个字符是 0x78 == 01111000，这意味着，模式一块（未压缩），并且它不是最终的块。

但奇怪的是 - 我很难想象 PNG 编码器不使用动态哈夫曼编码来压缩过滤后的原始图像数据。 deflate 标准规定，在模式一中将跳过当前字节的其余部分。

因此接下来的四个字节表示未压缩块的大小及其补码。 但0x59FD不是0xECDA的补码。即使我搞砸了字节顺序：0xFD59 也不是 0xDAEC 的补码。

好吧，淘汰字节就在后面。 0x97 被认为是未压缩但仍经过过滤的原始 png 图像数据的第一个字节，因此必须是过滤器类型。但 0x97 == 10010111 不是有效的过滤器类型。如果我搞砸了位打包顺序 11101001 == 0xe9 的事件仍然不是有效的过滤器类型。

我不再关注 RFC 1951，因为到目前为止我可以使用 deflate 解压缩器的实现来膨胀所有类型的文件，所以我怀疑我对 PNG 标准存在一些误解。

我一遍又一遍地阅读 RFC 2083，但是我在这里看到的数据与 RFC 不匹配，这对我来说没有意义，一定是缺少了一块！

当我查看以下字节时，实际上我在附近看不到有效的过滤器类型字节，这让我认为过滤后的 png 数据流毕竟是经过压缩的。

如果 0x78（IDAT 之后的第一个字节）从 MSB 读取到 LSB，则有意义，但 RFC 1951 另有规定。另一个想法（对我来说更有可能）是 IDAT 字符串和压缩 deflate 流的开头之间存在一些数据，但 RFC 2083 另有规定。布局清晰

4字节大小 4字节块名称（IDAT） [大小] 字节（压缩后的 deflate 流） 4字节CRC校验和

因此，IDAT 之后的第一个字节必须是压缩 deflate 流的第一个字节 - 这表示模式 1 未压缩数据块。这意味着 0x97 必须是未压缩但已过滤的 png 图像数据的第一个字节 - 这意味着 0x97 是第一行的过滤器类型 - 这是无效的......

我就是不明白，是我傻还是怎么？？

概括： 可能性一： IDAT 和压缩 deflate 流的有效开始之间还有一些其他数据，如果渲染为真，则 RFC2083 或我读过的任何有关图像压缩的书中都没有提到这些数据。

可能性2： 数字 0x78 被解释为 MSB -> LSB，这将指示模式 3 块（动态哈夫曼编码），但这与 RF1951 相矛盾，RF1951 对于位打包非常清楚：（LSB -> MSB）

我已经知道，缺失的部分一定是非常愚蠢的东西，如果 Stack Overflow 中只有一个删除按钮，我会感到迫切需要出卖我的灵魂:-p

两个更正可能会帮助您上路：

1. 的数量zlib标志中的字节是 2，而不是 1 -- 请参阅RFC 1950 https://www.rfc-editor.org/rfc/rfc1950。第一个是CMF， 下一个FLG.

在您的数据中：

78 DA

---CMF---  ---FLG---
0111.1000  1101.0101
CINF -CM-  +-||
           | |+- FCHECK
           | +-- FDICT
           +---- FLEVEL

CINF为7，表示标准32Kb压缩窗口。
CM是8，表明压缩算法确实是DEFLATE。
FCHECK只是一个校验和；我没有检查它是否正确（但我敢打赌它是正确的）。
FDICT很清楚，意味着没有存储预设词典。
FLEVEL为3，表示最大压缩。

也可以看看尝试理解 PNG 文件中的 zlib/deflate https://stackoverflow.com/questions/26018811/trying-to-understand-zlib-deflate-in-png-files，特别是。博士。阿德勒的回答。

2. LEN and NLEN仅针对未压缩块设置；这就是你没有找到它们的原因。 （另外，部分原因是您查看了错误的字节。）

下一个byte在流中是EC;按位计算，这是1110 1100 but记住从低位到高位读取位。所以下一位读取的是0， 意义notFINAL，接下来读取的 2 位是10（按这个顺序！），表示常规动态霍夫曼编码数据块。