zlib格式首两字节0x68de的CINFO值合规性疑问求助

Great question—let’s clear this up by breaking down the zlib header structure and where the mix-up happened.

First, let’s correct a critical detail about the zlib CMF (Compression Method and Flags) byte (the first byte of your input, 0x68):

From RFC 1950, the CMF byte is structured as:

• High 4 bits (bits 4-7): CINFO (Compression Info, the value limited to ≤7 per the spec)
• Low 4 bits (bits 0-3): CM (Compression Method, which must be 8 for deflate—the only widely supported method besides 0 for uncompressed storage)

Your 0x68 byte in binary is 0110 1000:

• The high 4 bits (0110) equal 6 (not 8)—this is your actual CINFO value, which is well within the ≤7 limit specified in RFC 1950.
• The low 4 bits (1000) equal 8—this is the CM value, which is valid (it signals the deflate compression method that zlib’s inflate() expects).

Now let’s verify the second byte, 0xde (FLG, Flags):
RFC 1950 requires that (CMF * 256 + FLG) is a multiple of 31 (this is the FCHECK checksum to validate the header). Calculating:
0x68 * 256 + 0xde = 26846, and 26846 ÷ 31 = 866—it divides perfectly, so the header passes the spec’s validation check.

Why did you think CINFO was 8? #

You swapped the high/low bit order of the CMF byte. It’s an easy mistake to make if you’re reading the byte left-to-right as individual bits without remembering the RFC’s specified structure.

To recap: Your 0x68de header is fully compliant with RFC 1950—CINFO is 6 (valid), CM is 8 (valid deflate method), and the FLG checksum passes. That’s exactly why inflate() processed it without errors.

内容的提问来源于stack exchange，提问作者Gangadhar