zlib-3.3.doc

来自「This is a resource based on j2me embedde」· DOC 代码 · 共 584 行 · 第 1/2 页

INTERNET-DRAFT                                          L. Peter Deutsch
ZLIB 3.3                                             Aladdin Enterprises
Expires: 30 July 1996                                   Jean-Loup Gailly
                                                                Info-Zip
                                                             30 Jan 1996

ZLIB Compressed Data Format Specification version 3.3

File draft-deutsch-zlib-3.3-00.txt

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet- Drafts
   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   Distribution of this memo is unlimited.

 Notices

   Copyright (C) 1995 L. Peter Deutsch and Jean-loup Gailly

   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 it is
   copied as a whole (including the copyright notice and this notice)
   and with no changes.

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



Deutsch and Gailly                                             [Page  1]

Internet Draft ZLIB Compressed Data Format Specification     30 Jan 1996


   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.

Table of contents

   1. Introduction ................................................... 2
      1.1 Purpose .................................................... 2
      1.2 Intended audience .......................................... 3
      1.3 Scope ...................................................... 3
      1.4 Compliance ................................................. 3
      1.5  Definitions of terms and conventions used ................. 3
      1.6 Changes from previous versions ............................. 3
   2. Detailed specification ......................................... 3
      2.1 Overall conventions ........................................ 3
      2.2 Data format ................................................ 4
      2.3 Compliance ................................................. 6
   3. References ..................................................... 7
   4. Source code .................................................... 7
   5. Security considerations ........................................ 7
   6. Acknowledgements ............................................... 7
   7. Authors' addresses ............................................. 7
   8. Appendix: Rationale ............................................ 8
   9. Appendix: Sample code .......................................... 9

1. Introduction

   1.1. Purpose

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

          o Is independent of CPU type, operating system, file system,
            and character set, and hence can be used for interchange;

          o 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, and hence can
            be used in data communications or similar structures such as
            Unix filters;

          o Can use a number of different compression methods;

          o Can be implemented readily in a manner not covered by
            patents, and hence can be practiced freely.

      The data format defined by this specification does not attempt to
      allow random access to compressed data.
   1.2. Intended audience

      This specification is intended for use by implementors of software


Deutsch and Gailly                                             [Page  2]

Internet Draft ZLIB Compressed Data Format Specification     30 Jan 1996


      to compress data into zlib format and/or decompress data from zlib
      format.

      The text of the specification assumes a basic background in
      programming at the level of bits and other primitive data
      representations.

   1.3. Scope

      The specification specifies a compressed data format that can be
      used for in-memory compression of a sequence of arbitrary bytes.

   1.4. Compliance

      Unless otherwise indicated below, a compliant decompressor must be
      able to accept and decompress any data set that conforms to all
      the specifications presented here; a compliant compressor must
      produce data sets that conform to all the specifications presented
      here.

   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 Section 2.1, below, for the numbering of bits within
      a byte.

   1.6. Changes from previous versions

      Version 3.1 was the first public release of this specification.
      In version 3.2, some terminology was changed and the Adler-32
      sample code was rewritten for clarity.  In version 3.3, the
      support for a preset dictionary was introduced, and the
      specification was converted to Internet Draft style.

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:

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



Deutsch and Gailly                                             [Page  3]

Internet Draft ZLIB Compressed Data Format Specification     30 Jan 1996


      represents a variable number of bytes.

      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|
         +--------+

      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

   2.2. Data format

      A zlib stream has the following structure:

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

      (if FLG.FDICT set)

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

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

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



Deutsch and Gailly                                             [Page  4]

Internet Draft ZLIB Compressed Data Format Specification     30 Jan 1996


      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

      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 [GZIP] and [PNG] 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.

      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.

      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.

      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.

      FLEVEL (Compression level)

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


Deutsch and Gailly                                             [Page  5]

Internet Draft ZLIB Compressed Data Format Specification     30 Jan 1996