RFC 1950 - ZLIB Compressed Data Format Specification version 3.3

• 번역
  • 1. Introduction
    • 1.1. Purpose
    • 1.2. Intended audience
    • 1.3. Scope
    • 1.4. Compliance
    • 1.5. Definitions of terms and conventions used
    • 1.6. Changes from previous versions
  • 2. Detailed specification
    • 2.1. Overall conventions
    • 2.2. Data format
    • 2.3 Compliance
  • 3. References
  • 4. Source code
  • 5. Security Considerations
  • 6. Acknowledgements
  • 7. Author's Address
• 함께 읽기
• 주석

번역

Network Working Group
Request for Comments: 1950
Category: Informational

P. Deutsch
Aladdin Enterprises
J-L. Gailly
Info-ZIP
May 1996

Status of This Memo

This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

이 메모에 대하여

이 메모는 인터넷 커뮤니티를 위한 정보를 제공합니다. 이 메모는 어떤 인터넷 표준도 명시하지 않습니다. 이 메모의 배포는 무제한입니다.

IESG Note:

The IESG takes no position on the validity of any Intellectual Property Rights statements contained in this document.

IESG:¹

IESG는 본 문서에 포함된 지적재산권 진술의 유효성에 대해 어떠한 입장도 취하지 않습니다.

Notices

Copyright (c) 1996 L. Peter Deutsch

Permission is granted to copy and distribute this document for any purpose and without charge, including translations into other languages and incorporation into compilations, provided that the copyright notice and this notice are preserved, and that any substantive changes or deletions from the original are clearly marked.

A pointer to the latest version of this and related documentation in HTML format can be found at the URL < ftp://ftp.uu.net/graphics/png/documents/zlib/zdoc-index.html >.

공지사항

저작권 고지 및 본 고지를 보존하고 원본에서 실질적으로 변경된 내용이나 삭제된 사항을 명확하게 표시하는 경우, 다른 언어로 번역하거나 편집물에 포함시키는 것을 포함하여 어떠한 목적으로든 무료로 이 문서를 복사 및 배포할 수 있는 권한이 부여됩니다.

본 고지 및 관련 문서의 최신 버전에 대한 포인터는 URL ftp://ftp.uu.net/graphics/png/documents/zlib/zdoc-index.html에서 확인할 수 있습니다.

Abstract

This specification defines a lossless compressed data format. The data can be produced or consumed, even for an arbitrarily long sequentially presented input data stream, using only an a priori bounded amount of intermediate storage. The format presently uses the DEFLATE compression method but can be easily extended to use other compression methods. It can be implemented readily in a manner not covered by patents. This specification also defines the ADLER-32 checksum (an extension and improvement of the Fletcher checksum), used for detection of data corruption, and provides an algorithm for computing it.

초록

이 명세서는 무손실 압축 데이터 포맷을 정의합니다. 이 포맷을 사용하면 임의의 길이를 갖는 순차적으로 제시된 입력 데이트 스트림에 대해서도, 미리 정해진 제한된 규모의 중간 저장소만 사용해서 데이터를 생성하거나 소비할 수 있습니다. 현재 이 포맷은 DEFLATE 압축 방식을 사용하지만, 다른 압축 방식을 사용하도록 쉽게 확장할 수 있으며, 특허로 보호되지 않는 방식으로도 쉽게 구현할 수 있습니다. 또한 이 명세서에서는 데이터 손상을 감지하기 위해 사용하는 ADLER-32 체크섬(Fletcher 체크섬을 확장하고 개선한 것)을 정의하고, 이를 계산하는 알고리즘을 제공합니다.

1. Introduction

서론

1.1. Purpose

목적

The purpose of this specification is to define a lossless compressed data format that:

• Is independent of CPU type, operating system, file system, and character set, and hence can be used for interchange;
• Can compress or decompress a data stream (as opposed to a randomly accessible file) to produce another data stream, using only an a priori bounded amount of intermediate storage, and hence can be used in data communications or similar structures such as Unix filters;
• Compresses data with efficiency comparable to the best currently available general-purpose compression methods, and in particular considerably better than the "compress" program;
• Can be implemented readily in a manner not covered by patents, and hence can be practiced freely;
• Is compatible with the file format produced by the current widely used gzip utility, in that conforming decompressors will be able to read data produced by the existing gzip compressor.

The data format defined by this specification does not attempt to:

• Provide random access to compressed data;
• Compress specialized data (e.g., raster graphics) as well as the best currently available specialized algorithms.

이 명세서의 목적은 다음과 같은 특징을 갖는 무손실 압축 데이터 포맷을 정의하는 것입니다.

• CPU의 종류, 운영 체제, 파일 시스템 및 문자 세트에 의존하지 않으므로, 데이터 교환에 사용할 수 있습니다.
• 데이터 스트림(파일처럼 랜덤 엑세스가 가능하지 않음)을 미리 정해둔 제한된 양의 중간 저장소만 사용해서 압축하거나 해제하여, 다른 데이터 스트림을 생성할 수 있어서, 데이터 통신이나 유닉스 필터와 같은 구조에서 사용할 수 있습니다.
• 현재 사용 가능한 최고의 범용 압축 방법에 필적하는 효율로 데이터를 압축하며, 특히 "compress" 프로그램보다 훨씬 더 효율적입니다.
• 특허 적용을 받지 않는 방식으로 쉽게 구현할 수 있어서, 자유롭게 사용할 수 있습니다.
• 현재 널리 사용되는 gzip 유틸리티가 생성하는 파일 타입과 호환되므로, '이 명세서를 준수하는 압축 해제기'는 '기존 gzip 압축기가 생성한 데이터'를 읽을 수 있습니다.

이 명세서에서 정의하는 데이터 형식은 다음을 제공하지 않습니다.

• 압축된 데이터에 대한 랜덤 엑세스 제공.
• 현재 사용 가능한 최고로 전문화된 알고리즘만큼의 효율로 특수한 데이터(예: 래스터 그래픽)를 압축.

1.2. Intended audience

This specification is intended for use by implementors of software to compress data into gzip format and/or decompress data from gzip format. The text of the specification assumes a basic background in programming at the level of bits and other primitive data representations.

대상 독자

이 명세서는 데이터를 gzip 포맷으로 압축하거나 gzip 포맷의 데이터의 압축을 해제하는 소프트웨어를 구현하는 사람을 위한 것입니다. 이 명세서의 내용은 독자가 bit와 기타 원시 데이터 표현에 대한 기본적인 프로그래밍 지식을 알고 있다고 가정하고 있습니다.

1.3. Scope

The specification specifies a compression method and a file format (the latter assuming only that a file can store a sequence of arbitrary bytes). It does not specify any particular interface to a file system or anything about character sets or encodings (except for file names and comments, which are optional).

범위

이 명세서는 압축 방법과 파일 형식을 정의합니다(후자는 파일이 임의의 바이트 시퀀스를 저장할 수 있다고 가정합니다). 파일 시스템에 대한 특정 인터페이스나 문자 세트나 인코딩에 대한 내용은 지정하지 않습니다(파일 이름과 주석은 제외).

1.4. Compliance

Unless otherwise indicated below, a compliant decompressor must be able to accept and decompress any file that conforms to all the specifications presented here; a compliant compressor must produce files that conform to all the specifications presented here. The material in the appendices is not part of the specification per se and is not relevant to compliance.

준수사항

아래에서 다르게 명시되지 않는 한, 이 명세서를 준수하는 압축 해제기는 여기에 제시된 모든 명세에 부합하는 파일을 읽고 압축을 해제할 수 있어야 합니다.

명세를 준수하는 압축기는 여기에 제시된 모든 명세에 부합하는 파일을 생성해야 합니다.

1.5. Definitions of terms and conventions used

byte: 8 bits stored or transmitted as a unit (same as an octet). (For this specification, a byte is exactly 8 bits, even on machines which store a character on a number of bits different from 8.) See below for the numbering of bits within a byte.

용어 및 규칙 정의

byte(바이트): 8개의 bit를 하나의 단위로 취급해 저장하거나 전송합니다.(octet과 같음). (이 명세서에서 byte는 정확히 8 bit이며, 문자(character)를 8 bit가 아닌 다른 수의 bit들로 저장하는 머신에서도 byte는 8 비트입니다.)

byte에 포함된 bit들의 번호에 대해서는 아래에서 설명합니다.

1.6. Changes from previous versions

There have been no technical changes to the gzip format since version 4.1 of this specification. In version 4.2, some terminology was changed, and the sample CRC code was rewritten for clarity and to eliminate the requirement for the caller to do pre-and post-conditioning. Version 4.3 is a conversion of the specification to RFC style.

이전 버전과의 변경 사항

이 버전, 즉 4.1 이후의 gzip 포맷에 대한 기술적인 변경 사항은 없습니다.

버전 4.2에서는 일부 용어를 변경하고, 명확성을 높이기 위해 샘플 CRC 코드를 다시 작성했으며, 호출자가 사전 및 사후 조건을 처리할 필요가 없도록 변경했습니다.

버전 4.3은 명세서를 RFC 스타일로 변환한 것입니다.

2. Detailed specification

명세 세부사항

2.1. Overall conventions

전체적인 규칙

In the diagrams below, a box like this:

+---+
|   | <-- the vertical bars might be missing
+---+

represents one byte; a box like this:

+==============+
|              |
+==============+

represents a variable number of bytes.

아래의 다이어그램을 봅시다. 상자가 하나 있습니다.

+---+
|   | <-- 세로 막대가 없을 수 있음
+---+

이 상자는 1 byte를 나타냅니다. 그리고 아래와 같은 상자는,

+==============+
|              |
+==============+

여러 byte들을 나타냅니다.

Bytes stored within a computer do not have a "bit order", since they are always treated as a unit. However, a byte considered as an integer between 0 and 255 does have a most- and least- significant bit, and since we write numbers with the most- significant digit on the left, we also write bytes with the most- significant bit on the left. In the diagrams below, we number the bits of a byte so that bit 0 is the least-significant bit, i.e., the bits are numbered:

+--------+
|76543210|
+--------+

컴퓨터에 저장된 byte는 항상 하나의 묶음 단위로 취급되기 때문에, 포함된 "bit들의 순서"를 따지지 않습니다. 그러나 byte는 0과 255 사이의 정수를 표현하는 것이므로 최상위 bit와 최하위 bit를 갖고 있습니다. 그리고 우리가 숫자를 쓸 때 가장 큰 자릿수부터 왼쪽에 쓰기 때문에, byte을 작성할 때에도 가장 상위 bit를 왼쪽에 쓰는 방식을 사용합니다.

아래 다이어그램은 byte를 이루는 각 bit에 번호를 매긴 것으로, 0 이 최하위 bit라 할 수 있습니다.

+--------+
|76543210|
+--------+

Within a computer, a number may occupy multiple bytes. All multi-byte numbers in the format described here are stored with the MOST-significant byte first (at the lower memory address). For example, the decimal number 520 is stored as:

    0     1
+--------+--------+
|00000010|00001000|
+--------+--------+
 ^        ^
 |        |
 |        + less significant byte = 8
 + more significant byte = 2 x 256

컴퓨터에서 숫자는 여러 byte를 차지할 수 있습니다.

여기에서 설명하는 모든 multi-byte 숫자는 가장 상위 byte를 먼저(낮은 메모리 주소부터) 저장합니다.

예를 들어, 10진수 520은 다음과 같이 저장합니다.

    0     1
+--------+--------+
|00000010|00001000|
+--------+--------+
 ^        ^
 |        |
 |        + 낮은 자릿수 byte = 8
 + 높은 자릿수 byte = 2 x 256

2.2. Data format

데이터 포맷

A zlib stream has the following structure:

zlib 스트림은 다음과 같은 구조를 갖습니다.

  0   1
+---+---+
|CMF|FLG|   (more-->)
+---+---+

(if FLG.FDICT set)

(만약 FLG.FDICT 플래그 bit가 설정되어 있다면)

  0   1   2   3
+---+---+---+---+
|     DICTID    |   (more-->)
+---+---+---+---+

+=====================+---+---+---+---+
|...compressed data...|    ADLER32    |
+=====================+---+---+---+---+

Any data which may appear after ADLER32 are not part of the zlib stream.

ADLER32 이후에 나타날 수 있는 모든 데이터는 zlib 스트림에 포함되지 않습니다.

CMF (Compression Method and flags)

This byte is divided into a 4-bit compression method and a 4-bit information field depending on the compression method.

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

CMF (압축 방법 및 플래그)

이 byte는 '4bit 압축 방법'과 '4bit 정보 필드'로 나뉩니다.

• 0 ~ 3번 bits: CM - 압축 방법
• 4 ~ 7번 bits: CINFO - 압축 정보

CM (Compression method)

This identifies the compression method used in the file. CM = 8 denotes the "deflate" compression method with a window size up to 32K. This is the method used by gzip and PNG (see references [1] and [2] in Chapter 3, below, for the reference documents). CM = 15 is reserved. It might be used in a future version of this specification to indicate the presence of an extra field before the compressed data.

CM (압축 방법)

CM은 압축 파일에 사용된 압축 방법을 알려줍니다.

CM = 8은 윈도우 크기가 최대 32K인 "deflate" 압축 방법을 의미하며, gzip과 PNG에서 사용하는 방법입니다. (아래의 3장에서 레퍼런스 [1] , [2]를 참고하세요.)

CM = 15는 확장을 위해 예약되어 있습니다. 예약된 값은 이 명세서의 미래의 버전에서 압축된 데이터 앞에 추가 필드가 있음을 나타내는 데 사용될 수 있습니다.

CINFO (Compression info)

For CM = 8, CINFO is the base-2 logarithm of the LZ77 window size, minus eight (CINFO=7 indicates a 32K window size). Values of CINFO above 7 are not allowed in this version of the specification. CINFO is not defined in this specification for CM not equal to 8.

CINFO (압축 정보)

CM = 8인 경우, CINFO는 LZ77 윈도우 크기²의 2진 log 값에서 8을 뺀 값입니다.³ (CINFO=7은 32K 윈도우 크기를 나타냅니다.)

이 명세서 버전에서는 CINFO 값으로 7보다 큰 값은 허용하지 않습니다. 그리고 이 명세서에서는 CM이 8이 아닌 경우의 CINFO는 정의하지 않습니다.

FLG (FLaGs)

This flag byte is divided as follows:

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

The FCHECK value must be such that CMF and FLG, when viewed as a 16-bit unsigned integer stored in MSB order (CMF*256 + FLG), is a multiple of 31.

FLG (FlaGs)

이 플래그 byte는 다음과 같이 나뉩니다.

• 0 ~ 4번 bits: FCHECK (CMF와 FLG에 대한 체크 bits)
• 5번 bit: FDICT (preset dictionary)⁴
• 6 ~ 7번 bits: FLEVEL (압축 레벨)

FCHECK 값은, CMF와 FLG를 'MSB 순서로 저장한⁵ 16비트 부호 없는 정수(CMF*256 + FLG)'로 따졌을 때, 31의 배수여야 합니다.

FDICT (Preset dictionary)

If FDICT is set, a DICT dictionary identifier is present immediately after the FLG byte. The dictionary is a sequence of bytes which are initially fed to the compressor without producing any compressed output. DICT is the Adler-32 checksum of this sequence of bytes (see the definition of ADLER32 below). The decompressor can use this identifier to determine which dictionary has been used by the compressor.

FDICT (preset dictionary)

FDICT가 1로 설정된 경우라면, DICT dictionary 식별자가 FLG byte 바로 다음에 오게 됩니다.

dictionary는 '압축기가 아직 압축 결과를 생성하지 않았을 때' 압축기에 초기 입력으로 제공하는 byte sequence입니다. DICT는 이 dictionary byte sequence의 Adler-32 체크섬입니다. (아래의 ADLER32의 정의를 참고하세요.)

압축 해제 프로그램은 이 식별자를 사용해서 압축기가 사용한 dictionary를 알아낼 수 있습니다.

FLEVEL (Compression level)

These flags are available for use by specific compression methods. The "deflate" method (CM = 8) sets these flags as follows:

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

The information in FLEVEL is not needed for decompression; it is there to indicate if recompression might be worthwhile.

FLEVEL (압축 레벨)

이 플래그들은 압축 방법에 따라 다르게 사용될 수 있습니다. "deflate" 방법 (CM = 8)은 다음과 같이 이 플래그들을 설정합니다.

• 0 - 압축기가 가장 빠른 알고리즘을 사용.
• 1 - 압축기가 빠른 알고리즘을 사용.
• 2 - 압축기가 기본 알고리즘을 사용.
• 3 - 압축기가 최대로 압축하지만, 가장 느린 알고리즘을 사용.

FLEVEL에 있는 정보는 압축 해제에는 필요하지 않습니다. 이 정보는 재압축이 도움이 될지 안될지를 알려주기 위한 것입니다.

compressed data

For compression method 8, the compressed data is stored in the deflate compressed data format as described in the document "DEFLATE Compressed Data Format Specification" by L. Peter Deutsch. (See reference [3] in Chapter 3, below)

Other compressed data formats are not specified in this version of the zlib specification.

압축된 데이터

압축 방법 8을 사용한 경우라면⁶, 압축된 데이터는 L. Peter Deutsch의 "DEFLATE 압축 데이터 포맷 명세서"에 설명된 'deflate 압축 데이터 형식'으로 저장됩니다. (아래의 3장에서 레퍼런스 [3]을 참고하세요.)

다른 압축 데이터 포맷은 이 zlib 명세서 버전에서 정의하지 않습니다.

ADLER32 (Adler-32 checksum)

This contains a checksum value of the uncompressed data (excluding any dictionary data) computed according to Adler-32 algorithm. This algorithm is a 32-bit extension and improvement of the Fletcher algorithm, used in the ITU-T X.224 / ISO 8073 standard. See references [4] and [5] in Chapter 3, below)

Adler-32 is composed of two sums accumulated per byte: s1 is the sum of all bytes, s2 is the sum of all s1 values. Both sums are done modulo 65521. s1 is initialized to 1, s2 to zero. The Adler-32 checksum is stored as s2*65536 + s1 in most- significant-byte first (network) order.

ADLER32 (Adler-32 체크섬)

압축하기 전의 데이터를 Adler-32 알고리즘으로 계산한 체크섬 값입니다. (dictionary 데이터는 제외) 이 알고리즘은 ITU-T X.224 / ISO 8073 표준에서 사용되는 Fletcher 알고리즘을 32비트로 확장하고 개선한 버전입니다. (아래의 3장에서 레퍼런스 [4]와 [5]를 참고하세요.)

Adler-32는 두 개의 sum 값을 bytes별로 누적하여 구성됩니다.

• s1은 모든 bytes의 sum이고, s2는 모든 s1값의 sum입니다.
• 두 sum은 모두 65521로 모듈러 연산을 수행합니다
• s1의 초기값은 1, s2의 초기값은 0 입니다.

Adler-32 체크섬은 가장 높은 바이트 순서(network)⁷로 s2*65536 + s1 형태로 저장됩니다.⁸

2.3 Compliance

명세서 준수

A compliant compressor must produce streams with correct CMF, FLG and ADLER32, but need not support preset dictionaries. When the zlib data format is used as part of another standard data format, the compressor may use only preset dictionaries that are specified by this other data format. If this other format does not use the preset dictionary feature, the compressor must not set the FDICT flag.

이 명세서를 준수하는 압축기는 올바른 CMD, FLG, ADLER32를 가진 스트림을 생성해야 하지만, preset dictionary들은 지원하지 않아도 됩니다.

zlib 데이터 포맷이 다른 표준 데이터 포맷의 일부로 사용되는 경우, 압축기는 다른 데이터 포맷에서 지정한 preset dictionary들만 사용할 수 있습니다.

이 다른 포맷이 preset dictionary 기능을 사용하지 않는 경우, 압축기는 FDICT 플래그를 1로 설정해서는 안됩니다.

A compliant decompressor must check CMF, FLG, and ADLER32, and provide an error indication if any of these have incorrect values. A compliant decompressor must give an error indication if CM is not one of the values defined in this specification (only the value 8 is permitted in this version), since another value could indicate the presence of new features that would cause subsequent data to be interpreted incorrectly. A compliant decompressor must give an error indication if FDICT is set and DICTID is not the identifier of a known preset dictionary. A decompressor may ignore FLEVEL and still be compliant. When the zlib data format is being used as a part of another standard format, a compliant decompressor must support all the preset dictionaries specified by the other format. When the other format does not use the preset dictionary feature, a compliant decompressor must reject any stream in which the FDICT flag is set.

이 명세서를 준수하는 압축 해제 프로그램은 CMF, FLG, ADLER32를 확인하고, 이들 중 하나라도 올바르지 않은 값이 있는 경우 오류 표시를 제공해야 합니다.

이 명세서를 준수하는 압축 해제 프로그램은, CM이 이 명세서에서 정의된 값이 아닌 경우 오류 표시를 제공해야 합니다(이 버전에서는 CM 값으로 8만을 허용합니다). 다른 값을 쓰면 후속 데이터를 잘못 해석할 수 있는 새로운 기능의 존재를 나타낼 수 있기 때문입니다.

이 명세서를 준수하는 압축 해제 프로그램은 FDICT가 설정됐을 때, DICTID가 알려진 dictionary의 식별자가 아니라면 오류 표시를 제공해야 합니다.

압축 해제 프로그램은 FLEVEL을 무시해도 이 명세서를 준수한 것으로 볼 수 있습니다.

zlib 데이터 포맷이 다른 표준 포맷의 일부로 사용되는 경우, 이 명세서를 준수하는 압축 해제 프로그램은 다른 포맷에서 지정한 모든 사전 설정된 딕셔너리를 지원해야 합니다.

다른 포맷이 preset dictionary 설정 기능을 사용하지 않는 경우, 이 명세서를 준수하는 압축 해제 프로그램은 FDICT 플래그가 설정된 모든 스트림을 거부해야 합니다.

3. References

• [1] Deutsch, L.P.,"GZIP Compressed Data Format Specification", available in ftp://ftp.uu.net/pub/archiving/zip/doc/

• [2] Thomas Boutell, "PNG (Portable Network Graphics) specification", available in ftp://ftp.uu.net/graphics/png/documents/

• [3] Deutsch, L.P.,"DEFLATE Compressed Data Format Specification", available in ftp://ftp.uu.net/pub/archiving/zip/doc/

• [4] Fletcher, J. G., "An Arithmetic Checksum for Serial Transmissions," IEEE Transactions on Communications, Vol. COM-30, No. 1, January 1982, pp. 247-252.

• [5] ITU-T Recommendation X.224, Annex D, "Checksum Algorithms," November, 1993, pp. 144, 145. (Available from gopher://info.itu.ch). ITU-T X.244 is also the same as ISO 8073.

4. Source code

Source code for a C language implementation of a "zlib" compliant library is available at ftp://ftp.uu.net/pub/archiving/zip/zlib/.

"zlib"를 준수하는 라이브러리의 C 언어 구현 소스 코드는 ftp://ftp.uu.net/pub/archiving/zip/zlib/에서 얻을 수 있습니다.

5. Security Considerations

A decoder that fails to check the ADLER32 checksum value may be subject to undetected data corruption.

ADLER32 체크섬 값 확인에 실패한 디코더는 감지되지 않은 데이터 손상에 노출될 수 있습니다.

6. Acknowledgements

Trademarks cited in this document are the property of their respective owners.

Jean-Loup Gailly and Mark Adler designed the zlib format and wrote the related software described in this specification. Glenn Randers-Pehrson converted this document to RFC and HTML format.

감사의 말

이 문서에 인용된 상표는 각각의 소유자의 재산입니다.

Jean-Loup Gailly와 Mark Adler는 이 명세서에서 설명하는 zlib 포맷을 설계하고 관련 소프트웨어를 작성했습니다. Glenn Randers-Pehrson은 이 문서를 RFC와 HTML 포맷으로 변환했습니다.

7. Author's Address

생략

함께 읽기

• LZ77 and LZ78 (en.wikipedia.org)

주석