zlib 헤더는 어떻게 생겼습니까?

zlib 헤더는 어떻게 생겼습니까?

---

내 프로젝트에서 zlib헤더가 어떻게 생겼는지 알아야합니다 . 다소 간단하다고 들었지만 zlib 헤더에 대한 설명을 찾을 수 없습니다.

예를 들어 매직 넘버가 포함되어 있습니까?

---

RFC에 연결

0   1
+---+---+
|CMF|FLG|
+---+---+

CMF (압축 방식 및 플래그)이 바이트는 압축 방식에 따라 4 비트 압축 방식과 4 비트 정보 필드로 구분됩니다.

bits 0 to 3  CM     Compression method
bits 4 to 7  CINFO  Compression info

CM (압축 방법) 파일에서 사용되는 압축 방법을 식별합니다. CM = 8창 크기가 최대 32K 인 "수축"압축 방법을 나타냅니다. 이것은 gzip과 PNG 및 거의 모든 것에서 사용되는 방법 입니다. CM = 15는 예약되어 있습니다.

CINFO (압축 정보) CM = 8의 경우 CINFO는 LZ77 창 크기에서 8을 뺀 로그 (CINFO = 7은 32K 창 크기를 나타냄)의 밑이 2 인 로그입니다. 7 이상의 CINFO 값은이 버전의 사양에서 허용되지 않습니다. CINFO는 8이 아닌 CM에 대해이 사양에 정의되어 있지 않습니다.

실제로 이것은 첫 번째 바이트가 거의 항상 78(16 진수) 임을 의미합니다.

FLG (FLaGs)이 플래그 바이트는 다음과 같이 나뉩니다.

bits 0 to 4  FCHECK  (check bits for CMF and FLG)
bit  5       FDICT   (preset dictionary)
bits 6 to 7  FLEVEL  (compression level)

FCHECK 값은 MSB 순서 (CMF * 256 + FLG)로 저장된 16 비트 부호없는 정수로 볼 때 CMF 및 FLG가 31의 배수가되도록해야합니다.

FLEVEL (압축 수준)이 플래그는 특정 압축 방법에서 사용할 수 있습니다. "deflate"메소드 ( CM = 8)는 이러한 플래그를 다음과 같이 설정합니다.

        0 - compressor used fastest algorithm
        1 - compressor used fast algorithm
        2 - compressor used default algorithm
        3 - compressor used maximum compression, slowest algorithm

---

zlib 매직 헤더

78 01 - No Compression/low
78 9C - Default Compression
78 DA - Best Compression 

---

ZLIB / GZIP 헤더

Level | ZLIB  | GZIP 
  1   | 78 01 | 1F 8B 
  2   | 78 5E | 1F 8B 
  3   | 78 5E | 1F 8B 
  4   | 78 5E | 1F 8B 
  5   | 78 5E | 1F 8B 
  6   | 78 9C | 1F 8B 
  7   | 78 DA | 1F 8B 
  8   | 78 DA | 1F 8B 
  9   | 78 DA | 1F 8B 

Deflate에는 공통 헤더가 없습니다.

---

다음은 Zlib 압축 데이터 형식입니다.

 +---+---+
 |CMF|FLG| (2 bytes - Defines the compression mode - More details below)
 +---+---+
 +---+---+---+---+
 |     DICTID    | (4 bytes. Present only when FLG.FDICT is set.) - Mostly not set
 +---+---+---+---+
 +=====================+
 |...compressed data...| (variable size of data)
 +=====================+
 +---+---+---+---+
 |     ADLER32   |  (4 bytes of checksum)
 +---+---+---+---+

대부분 FLG.FDICT(사전 플래그)는 설정되어 있지 않습니다. 그러한 경우에는 DICTID단순히 존재하지 않습니다. 따라서 총 청취는 2 바이트에 불과합니다.

사전이없는 헤더 값 ( CMF및 FLG)은 다음과 같이 정의됩니다.

 CMF |  FLG
0x78 | 0x01 - No Compression/low
0x78 | 0x9C - Default Compression
0x78 | 0xDA - Best Compression 

ZLIB RFC 에서 더보기

---

ZLIB 헤더 ( RFC1950에 정의 됨 )는 16 비트 빅 엔디안 값입니다. 여기에는 최상위에서 최하위까지 다음 필드가 포함됩니다.

• CINFO(비트 12-15)
  창 크기를 0(256 바이트)에서 7(32768 바이트) 까지 2의 제곱으로 표시합니다 . 일반적으로 7. 더 높은 값은 허용되지 않습니다.

• CM(비트 8-11)
  압축 방법. 수축 ( 8) 만 허용됩니다.

• FLEVEL (bits 6-7)
  Roughly indicates the compression level, from 0 (fast/low) to 3 (slow/high)

• FDICT (bit 5)
  Indicates whether a preset dictionary is used. This is usually 0. 1 is technically allowed, but I don't know of any Deflate formats that define preset dictionaries.

• FCHECK (bits 0-4)
  A checksum (5 bits, 0..31), whose value is calculated such that the entire value divides 31 with no remainder.

Typically, only the CINFO and FLEVEL fields can be freely changed, and FCHECK must be calculated based on the final value.* Assuming no preset dictionary, there is no choice in what the other fields contain, so a total of 32 possible headers are valid. Here they are:

      FLEVEL: 0       1       2       3
CINFO:
     0      08 1D   08 5B   08 99   08 D7
     1      18 19   18 57   18 95   18 D3
     2      28 15   28 53   28 91   28 CF
     3      38 11   38 4F   38 8D   38 CB
     4      48 0D   48 4B   48 89   48 C7
     5      58 09   58 47   58 85   58 C3
     6      68 05   68 43   68 81   68 DE
     7      78 01   78 5E   78 9C   78 DA

The CINFO field is rarely, if ever, set by compressors to be anything other than 7 (indicating the maximum 32KB window), so the only values you are likely to see in the wild are the four in the bottom row (beginning with 78).

_{* (You might wonder if there's a small amount of leeway on the value of FCHECK - could it be set to either of 0 or 31 if both pass the checksum? In practice though, there aren't any valid headers where this situation occurs, so we don't have to worry about it.)}

---

All answers here are most probably correct, however - if you want to manipulate ZLib compression stream directly, and it was produced by using gz_open, gzwrite, gzclose functions - then there is extra 10 leading bytes header before zlib compression steam comes - and those are produced by function gz_open - header looks like this:

    fprintf(s->file, "%c%c%c%c%c%c%c%c%c%c", gz_magic[0], gz_magic[1],
         Z_DEFLATED, 0 /*flags*/, 0,0,0,0 /*time*/, 0 /*xflags*/, OS_CODE);

And results in following hex dump: 1F 8B 08 00 00 00 00 00 00 0B followed by zlib compression stream.

But there is also trailing 8 bytes - they are uLong - crc over whole file, uLong - uncompressed file size - look for following bytes at end of stream:

    putLong (s->file, s->crc);
    putLong (s->file, (uLong)(s->in & 0xffffffff));

참고URL : https://stackoverflow.com/questions/9050260/what-does-a-zlib-header-look-like