|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Network Working Group P. Deutsch
|
|
|
Request for Comments: 1952 Aladdin Enterprises
|
|
|
Category: Informational May 1996
|
|
|
|
|
|
|
|
|
GZIP file format specification version 4.3
|
|
|
|
|
|
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.
|
|
|
|
|
|
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>.
|
|
|
|
|
|
Abstract
|
|
|
|
|
|
This specification defines a lossless compressed data format that is
|
|
|
compatible with the widely used GZIP utility. The format includes a
|
|
|
cyclic redundancy check value for detecting data corruption. The
|
|
|
format presently uses the DEFLATE method of compression but can be
|
|
|
easily extended to use other compression methods. The format can be
|
|
|
implemented readily in a manner not covered by patents.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Deutsch Informational [Page 1]
|
|
|
|
|
|
RFC 1952 GZIP File Format Specification May 1996
|
|
|
|
|
|
|
|
|
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 ......................................... 4
|
|
|
2.1. Overall conventions ....................................... 4
|
|
|
2.2. File format ............................................... 5
|
|
|
2.3. Member format ............................................. 5
|
|
|
2.3.1. Member header and trailer ........................... 6
|
|
|
2.3.1.1. Extra field ................................... 8
|
|
|
2.3.1.2. Compliance .................................... 9
|
|
|
3. References .................................................. 9
|
|
|
4. Security Considerations .................................... 10
|
|
|
5. Acknowledgements ........................................... 10
|
|
|
6. Author's Address ........................................... 10
|
|
|
7. Appendix: Jean-Loup Gailly's gzip utility .................. 11
|
|
|
8. Appendix: Sample CRC Code .................................. 11
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Deutsch Informational [Page 2]
|
|
|
|
|
|
RFC 1952 GZIP File Format Specification May 1996
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
Deutsch Informational [Page 3]
|
|
|
|
|
|
RFC 1952 GZIP File Format Specification May 1996
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
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|
|
|
|
+--------+
|
|
|
|
|
|
This document does not address the issue of the order in which
|
|
|
bits of a byte are transmitted on a bit-sequential medium, since
|
|
|
the data format described here is byte- rather than bit-oriented.
|
|
|
|
|
|
Within a computer, a number may occupy multiple bytes. All
|
|
|
multi-byte numbers in the format described here are stored with
|
|
|
the least-significant byte first (at the lower memory address).
|
|
|
For example, the decimal number 520 is stored as:
|
|
|
|
|
|
0 1
|
|
|
+--------+--------+
|
|
|
|00001000|00000010|
|
|
|
+--------+--------+
|
|
|
^ ^
|
|
|
| |
|
|
|
| + more significant byte = 2 x 256
|
|
|
+ less significant byte = 8
|
|
|
|
|
|
|
|
|
|
|
|
Deutsch Informational [Page 4]
|
|
|
|
|
|
RFC 1952 GZIP File Format Specification May 1996
|
|
|
|
|
|
|
|
|
2.2. File format
|
|
|
|
|
|
A gzip file consists of a series of "members" (compressed data
|
|
|
sets). The format of each member is specified in the following
|
|
|
section. The members simply appear one after another in the file,
|
|
|
with no additional information before, between, or after them.
|
|
|
|
|
|
2.3. Member format
|
|
|
|
|
|
Each member has the following structure:
|
|
|
|
|
|
+---+---+---+---+---+---+---+---+---+---+
|
|
|
|ID1|ID2|CM |FLG| MTIME |XFL|OS | (more-->)
|
|
|
+---+---+---+---+---+---+---+---+---+---+
|
|
|
|
|
|
(if FLG.FEXTRA set)
|
|
|
|
|
|
+---+---+=================================+
|
|
|
| XLEN |...XLEN bytes of "extra field"...| (more-->)
|
|
|
+---+---+=================================+
|
|
|
|
|
|
(if FLG.FNAME set)
|
|
|
|
|
|
+=========================================+
|
|
|
|...original file name, zero-terminated...| (more-->)
|
|
|
+=========================================+
|
|
|
|
|
|
(if FLG.FCOMMENT set)
|
|
|
|
|
|
+===================================+
|
|
|
|...file comment, zero-terminated...| (more-->)
|
|
|
+===================================+
|
|
|
|
|
|
(if FLG.FHCRC set)
|
|
|
|
|
|
+---+---+
|
|
|
| CRC16 |
|
|
|
+---+---+
|
|
|
|
|
|
+=======================+
|
|
|
|...compressed blocks...| (more-->)
|
|
|
+=======================+
|
|
|
|
|
|
0 1 2 3 4 5 6 7
|
|
|
+---+---+---+---+---+---+---+---+
|
|
|
| CRC32 | ISIZE |
|
|
|
+---+---+---+---+---+---+---+---+
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Deutsch Informational [Page 5]
|
|
|
|
|
|
RFC 1952 GZIP File Format Specification May 1996
|
|
|
|
|
|
|
|
|
2.3.1. Member header and trailer
|
|
|
|
|
|
ID1 (IDentification 1)
|
|
|
ID2 (IDentification 2)
|
|
|
These have the fixed values ID1 = 31 (0x1f, \037), ID2 = 139
|
|
|
(0x8b, \213), to identify the file as being in gzip format.
|
|
|
|
|
|
CM (Compression Method)
|
|
|
This identifies the compression method used in the file. CM
|
|
|
= 0-7 are reserved. CM = 8 denotes the "deflate"
|
|
|
compression method, which is the one customarily used by
|
|
|
gzip and which is documented elsewhere.
|
|
|
|
|
|
FLG (FLaGs)
|
|
|
This flag byte is divided into individual bits as follows:
|
|
|
|
|
|
bit 0 FTEXT
|
|
|
bit 1 FHCRC
|
|
|
bit 2 FEXTRA
|
|
|
bit 3 FNAME
|
|
|
bit 4 FCOMMENT
|
|
|
bit 5 reserved
|
|
|
bit 6 reserved
|
|
|
bit 7 reserved
|
|
|
|
|
|
If FTEXT is set, the file is probably ASCII text. This is
|
|
|
an optional indication, which the compressor may set by
|
|
|
checking a small amount of the input data to see whether any
|
|
|
non-ASCII characters are present. In case of doubt, FTEXT
|
|
|
is cleared, indicating binary data. For systems which have
|
|
|
different file formats for ascii text and binary data, the
|
|
|
decompressor can use FTEXT to choose the appropriate format.
|
|
|
We deliberately do not specify the algorithm used to set
|
|
|
this bit, since a compressor always has the option of
|
|
|
leaving it cleared and a decompressor always has the option
|
|
|
of ignoring it and letting some other program handle issues
|
|
|
of data conversion.
|
|
|
|
|
|
If FHCRC is set, a CRC16 for the gzip header is present,
|
|
|
immediately before the compressed data. The CRC16 consists
|
|
|
of the two least significant bytes of the CRC32 for all
|
|
|
bytes of the gzip header up to and not including the CRC16.
|
|
|
[The FHCRC bit was never set by versions of gzip up to
|
|
|
1.2.4, even though it was documented with a different
|
|
|
meaning in gzip 1.2.4.]
|
|
|
|
|
|
If FEXTRA is set, optional extra fields are present, as
|
|
|
described in a following section.
|
|
|
|
|
|
|
|
|
|
|
|
Deutsch Informational [Page 6]
|
|
|
|
|
|
RFC 1952 GZIP File Format Specification May 1996
|
|
|
|
|
|
|
|
|
If FNAME is set, an original file name is present,
|
|
|
terminated by a zero byte. The name must consist of ISO
|
|
|
8859-1 (LATIN-1) characters; on operating systems using
|
|
|
EBCDIC or any other character set for file names, the name
|
|
|
must be translated to the ISO LATIN-1 character set. This
|
|
|
is the original name of the file being compressed, with any
|
|
|
directory components removed, and, if the file being
|
|
|
compressed is on a file system with case insensitive names,
|
|
|
forced to lower case. There is no original file name if the
|
|
|
data was compressed from a source other than a named file;
|
|
|
for example, if the source was stdin on a Unix system, there
|
|
|
is no file name.
|
|
|
|
|
|
If FCOMMENT is set, a zero-terminated file comment is
|
|
|
present. This comment is not interpreted; it is only
|
|
|
intended for human consumption. The comment must consist of
|
|
|
ISO 8859-1 (LATIN-1) characters. Line breaks should be
|
|
|
denoted by a single line feed character (10 decimal).
|
|
|
|
|
|
Reserved FLG bits must be zero.
|
|
|
|
|
|
MTIME (Modification TIME)
|
|
|
This gives the most recent modification time of the original
|
|
|
file being compressed. The time is in Unix format, i.e.,
|
|
|
seconds since 00:00:00 GMT, Jan. 1, 1970. (Note that this
|
|
|
may cause problems for MS-DOS and other systems that use
|
|
|
local rather than Universal time.) If the compressed data
|
|
|
did not come from a file, MTIME is set to the time at which
|
|
|
compression started. MTIME = 0 means no time stamp is
|
|
|
available.
|
|
|
|
|
|
XFL (eXtra FLags)
|
|
|
These flags are available for use by specific compression
|
|
|
methods. The "deflate" method (CM = 8) sets these flags as
|
|
|
follows:
|
|
|
|
|
|
XFL = 2 - compressor used maximum compression,
|
|
|
slowest algorithm
|
|
|
XFL = 4 - compressor used fastest algorithm
|
|
|
|
|
|
OS (Operating System)
|
|
|
This identifies the type of file system on which compression
|
|
|
took place. This may be useful in determining end-of-line
|
|
|
convention for text files. The currently defined values are
|
|
|
as follows:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Deutsch Informational [Page 7]
|
|
|
|
|
|
RFC 1952 GZIP File Format Specification May 1996
|
|
|
|
|
|
|
|
|
0 - FAT filesystem (MS-DOS, OS/2, NT/Win32)
|
|
|
1 - Amiga
|
|
|
2 - VMS (or OpenVMS)
|
|
|
3 - Unix
|
|
|
4 - VM/CMS
|
|
|
5 - Atari TOS
|
|
|
6 - HPFS filesystem (OS/2, NT)
|
|
|
7 - Macintosh
|
|
|
8 - Z-System
|
|
|
9 - CP/M
|
|
|
10 - TOPS-20
|
|
|
11 - NTFS filesystem (NT)
|
|
|
12 - QDOS
|
|
|
13 - Acorn RISCOS
|
|
|
255 - unknown
|
|
|
|
|
|
XLEN (eXtra LENgth)
|
|
|
If FLG.FEXTRA is set, this gives the length of the optional
|
|
|
extra field. See below for details.
|
|
|
|
|
|
CRC32 (CRC-32)
|
|
|
This contains a Cyclic Redundancy Check value of the
|
|
|
uncompressed data computed according to CRC-32 algorithm
|
|
|
used in the ISO 3309 standard and in section 8.1.1.6.2 of
|
|
|
ITU-T recommendation V.42. (See http://www.iso.ch for
|
|
|
ordering ISO documents. See gopher://info.itu.ch for an
|
|
|
online version of ITU-T V.42.)
|
|
|
|
|
|
ISIZE (Input SIZE)
|
|
|
This contains the size of the original (uncompressed) input
|
|
|
data modulo 2^32.
|
|
|
|
|
|
2.3.1.1. Extra field
|
|
|
|
|
|
If the FLG.FEXTRA bit is set, an "extra field" is present in
|
|
|
the header, with total length XLEN bytes. It consists of a
|
|
|
series of subfields, each of the form:
|
|
|
|
|
|
+---+---+---+---+==================================+
|
|
|
|SI1|SI2| LEN |... LEN bytes of subfield data ...|
|
|
|
+---+---+---+---+==================================+
|
|
|
|
|
|
SI1 and SI2 provide a subfield ID, typically two ASCII letters
|
|
|
with some mnemonic value. Jean-Loup Gailly
|
|
|
<gzip@prep.ai.mit.edu> is maintaining a registry of subfield
|
|
|
IDs; please send him any subfield ID you wish to use. Subfield
|
|
|
IDs with SI2 = 0 are reserved for future use. The following
|
|
|
IDs are currently defined:
|
|
|
|
|
|
|
|
|
|
|
|
Deutsch Informational [Page 8]
|
|
|
|
|
|
RFC 1952 GZIP File Format Specification May 1996
|
|
|
|
|
|
|
|
|
SI1 SI2 Data
|
|
|
---------- ---------- ----
|
|
|
0x41 ('A') 0x70 ('P') Apollo file type information
|
|
|
|
|
|
LEN gives the length of the subfield data, excluding the 4
|
|
|
initial bytes.
|
|
|
|
|
|
2.3.1.2. Compliance
|
|
|
|
|
|
A compliant compressor must produce files with correct ID1,
|
|
|
ID2, CM, CRC32, and ISIZE, but may set all the other fields in
|
|
|
the fixed-length part of the header to default values (255 for
|
|
|
OS, 0 for all others). The compressor must set all reserved
|
|
|
bits to zero.
|
|
|
|
|
|
A compliant decompressor must check ID1, ID2, and CM, and
|
|
|
provide an error indication if any of these have incorrect
|
|
|
values. It must examine FEXTRA/XLEN, FNAME, FCOMMENT and FHCRC
|
|
|
at least so it can skip over the optional fields if they are
|
|
|
present. It need not examine any other part of the header or
|
|
|
trailer; in particular, a decompressor may ignore FTEXT and OS
|
|
|
and always produce binary output, and still be compliant. A
|
|
|
compliant decompressor must give an error indication if any
|
|
|
reserved bit is non-zero, since such a bit could indicate the
|
|
|
presence of a new field that would cause subsequent data to be
|
|
|
interpreted incorrectly.
|
|
|
|
|
|
3. References
|
|
|
|
|
|
[1] "Information Processing - 8-bit single-byte coded graphic
|
|
|
character sets - Part 1: Latin alphabet No.1" (ISO 8859-1:1987).
|
|
|
The ISO 8859-1 (Latin-1) character set is a superset of 7-bit
|
|
|
ASCII. Files defining this character set are available as
|
|
|
iso_8859-1.* in ftp://ftp.uu.net/graphics/png/documents/
|
|
|
|
|
|
[2] ISO 3309
|
|
|
|
|
|
[3] ITU-T recommendation V.42
|
|
|
|
|
|
[4] Deutsch, L.P.,"DEFLATE Compressed Data Format Specification",
|
|
|
available in ftp://ftp.uu.net/pub/archiving/zip/doc/
|
|
|
|
|
|
[5] Gailly, J.-L., GZIP documentation, available as gzip-*.tar in
|
|
|
ftp://prep.ai.mit.edu/pub/gnu/
|
|
|
|
|
|
[6] Sarwate, D.V., "Computation of Cyclic Redundancy Checks via Table
|
|
|
Look-Up", Communications of the ACM, 31(8), pp.1008-1013.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Deutsch Informational [Page 9]
|
|
|
|
|
|
RFC 1952 GZIP File Format Specification May 1996
|
|
|
|
|
|
|
|
|
[7] Schwaderer, W.D., "CRC Calculation", April 85 PC Tech Journal,
|
|
|
pp.118-133.
|
|
|
|
|
|
[8] ftp://ftp.adelaide.edu.au/pub/rocksoft/papers/crc_v3.txt,
|
|
|
describing the CRC concept.
|
|
|
|
|
|
4. Security Considerations
|
|
|
|
|
|
Any data compression method involves the reduction of redundancy in
|
|
|
the data. Consequently, any corruption of the data is likely to have
|
|
|
severe effects and be difficult to correct. Uncompressed text, on
|
|
|
the other hand, will probably still be readable despite the presence
|
|
|
of some corrupted bytes.
|
|
|
|
|
|
It is recommended that systems using this data format provide some
|
|
|
means of validating the integrity of the compressed data, such as by
|
|
|
setting and checking the CRC-32 check value.
|
|
|
|
|
|
5. Acknowledgements
|
|
|
|
|
|
Trademarks cited in this document are the property of their
|
|
|
respective owners.
|
|
|
|
|
|
Jean-Loup Gailly designed the gzip format and wrote, with Mark Adler,
|
|
|
the related software described in this specification. Glenn
|
|
|
Randers-Pehrson converted this document to RFC and HTML format.
|
|
|
|
|
|
6. Author's Address
|
|
|
|
|
|
L. Peter Deutsch
|
|
|
Aladdin Enterprises
|
|
|
203 Santa Margarita Ave.
|
|
|
Menlo Park, CA 94025
|
|
|
|
|
|
Phone: (415) 322-0103 (AM only)
|
|
|
FAX: (415) 322-1734
|
|
|
EMail: <ghost@aladdin.com>
|
|
|
|
|
|
Questions about the technical content of this specification can be
|
|
|
sent by email to:
|
|
|
|
|
|
Jean-Loup Gailly <gzip@prep.ai.mit.edu> and
|
|
|
Mark Adler <madler@alumni.caltech.edu>
|
|
|
|
|
|
Editorial comments on this specification can be sent by email to:
|
|
|
|
|
|
L. Peter Deutsch <ghost@aladdin.com> and
|
|
|
Glenn Randers-Pehrson <randeg@alumni.rpi.edu>
|
|
|
|
|
|
|
|
|
|
|
|
Deutsch Informational [Page 10]
|
|
|
|
|
|
RFC 1952 GZIP File Format Specification May 1996
|
|
|
|
|
|
|
|
|
7. Appendix: Jean-Loup Gailly's gzip utility
|
|
|
|
|
|
The most widely used implementation of gzip compression, and the
|
|
|
original documentation on which this specification is based, were
|
|
|
created by Jean-Loup Gailly <gzip@prep.ai.mit.edu>. Since this
|
|
|
implementation is a de facto standard, we mention some more of its
|
|
|
features here. Again, the material in this section is not part of
|
|
|
the specification per se, and implementations need not follow it to
|
|
|
be compliant.
|
|
|
|
|
|
When compressing or decompressing a file, gzip preserves the
|
|
|
protection, ownership, and modification time attributes on the local
|
|
|
file system, since there is no provision for representing protection
|
|
|
attributes in the gzip file format itself. Since the file format
|
|
|
includes a modification time, the gzip decompressor provides a
|
|
|
command line switch that assigns the modification time from the file,
|
|
|
rather than the local modification time of the compressed input, to
|
|
|
the decompressed output.
|
|
|
|
|
|
8. Appendix: Sample CRC Code
|
|
|
|
|
|
The following sample code represents a practical implementation of
|
|
|
the CRC (Cyclic Redundancy Check). (See also ISO 3309 and ITU-T V.42
|
|
|
for a formal specification.)
|
|
|
|
|
|
The sample code is in the ANSI C programming language. Non C users
|
|
|
may find it easier to read with these hints:
|
|
|
|
|
|
& Bitwise AND operator.
|
|
|
^ Bitwise exclusive-OR operator.
|
|
|
>> Bitwise right shift operator. When applied to an
|
|
|
unsigned quantity, as here, right shift inserts zero
|
|
|
bit(s) at the left.
|
|
|
! Logical NOT operator.
|
|
|
++ "n++" increments the variable n.
|
|
|
0xNNN 0x introduces a hexadecimal (base 16) constant.
|
|
|
Suffix L indicates a long value (at least 32 bits).
|
|
|
|
|
|
/* Table of CRCs of all 8-bit messages. */
|
|
|
unsigned long crc_table[256];
|
|
|
|
|
|
/* Flag: has the table been computed? Initially false. */
|
|
|
int crc_table_computed = 0;
|
|
|
|
|
|
/* Make the table for a fast CRC. */
|
|
|
void make_crc_table(void)
|
|
|
{
|
|
|
unsigned long c;
|
|
|
|
|
|
|
|
|
|
|
|
Deutsch Informational [Page 11]
|
|
|
|
|
|
RFC 1952 GZIP File Format Specification May 1996
|
|
|
|
|
|
|
|
|
int n, k;
|
|
|
for (n = 0; n < 256; n++) {
|
|
|
c = (unsigned long) n;
|
|
|
for (k = 0; k < 8; k++) {
|
|
|
if (c & 1) {
|
|
|
c = 0xedb88320L ^ (c >> 1);
|
|
|
} else {
|
|
|
c = c >> 1;
|
|
|
}
|
|
|
}
|
|
|
crc_table[n] = c;
|
|
|
}
|
|
|
crc_table_computed = 1;
|
|
|
}
|
|
|
|
|
|
/*
|
|
|
Update a running crc with the bytes buf[0..len-1] and return
|
|
|
the updated crc. The crc should be initialized to zero. Pre- and
|
|
|
post-conditioning (one's complement) is performed within this
|
|
|
function so it shouldn't be done by the caller. Usage example:
|
|
|
|
|
|
unsigned long crc = 0L;
|
|
|
|
|
|
while (read_buffer(buffer, length) != EOF) {
|
|
|
crc = update_crc(crc, buffer, length);
|
|
|
}
|
|
|
if (crc != original_crc) error();
|
|
|
*/
|
|
|
unsigned long update_crc(unsigned long crc,
|
|
|
unsigned char *buf, int len)
|
|
|
{
|
|
|
unsigned long c = crc ^ 0xffffffffL;
|
|
|
int n;
|
|
|
|
|
|
if (!crc_table_computed)
|
|
|
make_crc_table();
|
|
|
for (n = 0; n < len; n++) {
|
|
|
c = crc_table[(c ^ buf[n]) & 0xff] ^ (c >> 8);
|
|
|
}
|
|
|
return c ^ 0xffffffffL;
|
|
|
}
|
|
|
|
|
|
/* Return the CRC of the bytes buf[0..len-1]. */
|
|
|
unsigned long crc(unsigned char *buf, int len)
|
|
|
{
|
|
|
return update_crc(0L, buf, len);
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Deutsch Informational [Page 12]
|
|
|
|
|
|
|
