Mercurial > hg > sv-dependency-builds

annotate src/zlib-1.2.7/doc/rfc1952.txt @ 169:223a55898ab9 tip default

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Add null config files
author Chris Cannam <cannam@all-day-breakfast.com>
date Mon, 02 Mar 2020 14:03:47 +0000
parents 8a15ff55d9af
children
rev   line source
cannam@89 1
cannam@89 2
cannam@89 3
cannam@89 4
cannam@89 5
cannam@89 6
cannam@89 7 Network Working Group P. Deutsch
cannam@89 8 Request for Comments: 1952 Aladdin Enterprises
cannam@89 9 Category: Informational May 1996
cannam@89 10
cannam@89 11
cannam@89 12 GZIP file format specification version 4.3
cannam@89 13
cannam@89 14 Status of This Memo
cannam@89 15
cannam@89 16 This memo provides information for the Internet community. This memo
cannam@89 17 does not specify an Internet standard of any kind. Distribution of
cannam@89 18 this memo is unlimited.
cannam@89 19
cannam@89 20 IESG Note:
cannam@89 21
cannam@89 22 The IESG takes no position on the validity of any Intellectual
cannam@89 23 Property Rights statements contained in this document.
cannam@89 24
cannam@89 25 Notices
cannam@89 26
cannam@89 27 Copyright (c) 1996 L. Peter Deutsch
cannam@89 28
cannam@89 29 Permission is granted to copy and distribute this document for any
cannam@89 30 purpose and without charge, including translations into other
cannam@89 31 languages and incorporation into compilations, provided that the
cannam@89 32 copyright notice and this notice are preserved, and that any
cannam@89 33 substantive changes or deletions from the original are clearly
cannam@89 34 marked.
cannam@89 35
cannam@89 36 A pointer to the latest version of this and related documentation in
cannam@89 37 HTML format can be found at the URL
cannam@89 38 <ftp://ftp.uu.net/graphics/png/documents/zlib/zdoc-index.html>.
cannam@89 39
cannam@89 40 Abstract
cannam@89 41
cannam@89 42 This specification defines a lossless compressed data format that is
cannam@89 43 compatible with the widely used GZIP utility. The format includes a
cannam@89 44 cyclic redundancy check value for detecting data corruption. The
cannam@89 45 format presently uses the DEFLATE method of compression but can be
cannam@89 46 easily extended to use other compression methods. The format can be
cannam@89 47 implemented readily in a manner not covered by patents.
cannam@89 48
cannam@89 49
cannam@89 50
cannam@89 51
cannam@89 52
cannam@89 53
cannam@89 54
cannam@89 55
cannam@89 56
cannam@89 57
cannam@89 58 Deutsch Informational [Page 1]
cannam@89 59
cannam@89 60 RFC 1952 GZIP File Format Specification May 1996
cannam@89 61
cannam@89 62
cannam@89 63 Table of Contents
cannam@89 64
cannam@89 65 1. Introduction ................................................... 2
cannam@89 66 1.1. Purpose ................................................... 2
cannam@89 67 1.2. Intended audience ......................................... 3
cannam@89 68 1.3. Scope ..................................................... 3
cannam@89 69 1.4. Compliance ................................................ 3
cannam@89 70 1.5. Definitions of terms and conventions used ................. 3
cannam@89 71 1.6. Changes from previous versions ............................ 3
cannam@89 72 2. Detailed specification ......................................... 4
cannam@89 73 2.1. Overall conventions ....................................... 4
cannam@89 74 2.2. File format ............................................... 5
cannam@89 75 2.3. Member format ............................................. 5
cannam@89 76 2.3.1. Member header and trailer ........................... 6
cannam@89 77 2.3.1.1. Extra field ................................... 8
cannam@89 78 2.3.1.2. Compliance .................................... 9
cannam@89 79 3. References .................................................. 9
cannam@89 80 4. Security Considerations .................................... 10
cannam@89 81 5. Acknowledgements ........................................... 10
cannam@89 82 6. Author's Address ........................................... 10
cannam@89 83 7. Appendix: Jean-Loup Gailly's gzip utility .................. 11
cannam@89 84 8. Appendix: Sample CRC Code .................................. 11
cannam@89 85
cannam@89 86 1. Introduction
cannam@89 87
cannam@89 88 1.1. Purpose
cannam@89 89
cannam@89 90 The purpose of this specification is to define a lossless
cannam@89 91 compressed data format that:
cannam@89 92
cannam@89 93 * Is independent of CPU type, operating system, file system,
cannam@89 94 and character set, and hence can be used for interchange;
cannam@89 95 * Can compress or decompress a data stream (as opposed to a
cannam@89 96 randomly accessible file) to produce another data stream,
cannam@89 97 using only an a priori bounded amount of intermediate
cannam@89 98 storage, and hence can be used in data communications or
cannam@89 99 similar structures such as Unix filters;
cannam@89 100 * Compresses data with efficiency comparable to the best
cannam@89 101 currently available general-purpose compression methods,
cannam@89 102 and in particular considerably better than the "compress"
cannam@89 103 program;
cannam@89 104 * Can be implemented readily in a manner not covered by
cannam@89 105 patents, and hence can be practiced freely;
cannam@89 106 * Is compatible with the file format produced by the current
cannam@89 107 widely used gzip utility, in that conforming decompressors
cannam@89 108 will be able to read data produced by the existing gzip
cannam@89 109 compressor.
cannam@89 110
cannam@89 111
cannam@89 112
cannam@89 113
cannam@89 114 Deutsch Informational [Page 2]
cannam@89 115
cannam@89 116 RFC 1952 GZIP File Format Specification May 1996
cannam@89 117
cannam@89 118
cannam@89 119 The data format defined by this specification does not attempt to:
cannam@89 120
cannam@89 121 * Provide random access to compressed data;
cannam@89 122 * Compress specialized data (e.g., raster graphics) as well as
cannam@89 123 the best currently available specialized algorithms.
cannam@89 124
cannam@89 125 1.2. Intended audience
cannam@89 126
cannam@89 127 This specification is intended for use by implementors of software
cannam@89 128 to compress data into gzip format and/or decompress data from gzip
cannam@89 129 format.
cannam@89 130
cannam@89 131 The text of the specification assumes a basic background in
cannam@89 132 programming at the level of bits and other primitive data
cannam@89 133 representations.
cannam@89 134
cannam@89 135 1.3. Scope
cannam@89 136
cannam@89 137 The specification specifies a compression method and a file format
cannam@89 138 (the latter assuming only that a file can store a sequence of
cannam@89 139 arbitrary bytes). It does not specify any particular interface to
cannam@89 140 a file system or anything about character sets or encodings
cannam@89 141 (except for file names and comments, which are optional).
cannam@89 142
cannam@89 143 1.4. Compliance
cannam@89 144
cannam@89 145 Unless otherwise indicated below, a compliant decompressor must be
cannam@89 146 able to accept and decompress any file that conforms to all the
cannam@89 147 specifications presented here; a compliant compressor must produce
cannam@89 148 files that conform to all the specifications presented here. The
cannam@89 149 material in the appendices is not part of the specification per se
cannam@89 150 and is not relevant to compliance.
cannam@89 151
cannam@89 152 1.5. Definitions of terms and conventions used
cannam@89 153
cannam@89 154 byte: 8 bits stored or transmitted as a unit (same as an octet).
cannam@89 155 (For this specification, a byte is exactly 8 bits, even on
cannam@89 156 machines which store a character on a number of bits different
cannam@89 157 from 8.) See below for the numbering of bits within a byte.
cannam@89 158
cannam@89 159 1.6. Changes from previous versions
cannam@89 160
cannam@89 161 There have been no technical changes to the gzip format since
cannam@89 162 version 4.1 of this specification. In version 4.2, some
cannam@89 163 terminology was changed, and the sample CRC code was rewritten for
cannam@89 164 clarity and to eliminate the requirement for the caller to do pre-
cannam@89 165 and post-conditioning. Version 4.3 is a conversion of the
cannam@89 166 specification to RFC style.
cannam@89 167
cannam@89 168
cannam@89 169
cannam@89 170 Deutsch Informational [Page 3]
cannam@89 171
cannam@89 172 RFC 1952 GZIP File Format Specification May 1996
cannam@89 173
cannam@89 174
cannam@89 175 2. Detailed specification
cannam@89 176
cannam@89 177 2.1. Overall conventions
cannam@89 178
cannam@89 179 In the diagrams below, a box like this:
cannam@89 180
cannam@89 181 +---+
cannam@89 182 | | <-- the vertical bars might be missing
cannam@89 183 +---+
cannam@89 184
cannam@89 185 represents one byte; a box like this:
cannam@89 186
cannam@89 187 +==============+
cannam@89 188 | |
cannam@89 189 +==============+
cannam@89 190
cannam@89 191 represents a variable number of bytes.
cannam@89 192
cannam@89 193 Bytes stored within a computer do not have a "bit order", since
cannam@89 194 they are always treated as a unit. However, a byte considered as
cannam@89 195 an integer between 0 and 255 does have a most- and least-
cannam@89 196 significant bit, and since we write numbers with the most-
cannam@89 197 significant digit on the left, we also write bytes with the most-
cannam@89 198 significant bit on the left. In the diagrams below, we number the
cannam@89 199 bits of a byte so that bit 0 is the least-significant bit, i.e.,
cannam@89 200 the bits are numbered:
cannam@89 201
cannam@89 202 +--------+
cannam@89 203 |76543210|
cannam@89 204 +--------+
cannam@89 205
cannam@89 206 This document does not address the issue of the order in which
cannam@89 207 bits of a byte are transmitted on a bit-sequential medium, since
cannam@89 208 the data format described here is byte- rather than bit-oriented.
cannam@89 209
cannam@89 210 Within a computer, a number may occupy multiple bytes. All
cannam@89 211 multi-byte numbers in the format described here are stored with
cannam@89 212 the least-significant byte first (at the lower memory address).
cannam@89 213 For example, the decimal number 520 is stored as:
cannam@89 214
cannam@89 215 0 1
cannam@89 216 +--------+--------+
cannam@89 217 |00001000|00000010|
cannam@89 218 +--------+--------+
cannam@89 219 ^ ^
cannam@89 220 | |
cannam@89 221 | + more significant byte = 2 x 256
cannam@89 222 + less significant byte = 8
cannam@89 223
cannam@89 224
cannam@89 225
cannam@89 226 Deutsch Informational [Page 4]
cannam@89 227
cannam@89 228 RFC 1952 GZIP File Format Specification May 1996
cannam@89 229
cannam@89 230
cannam@89 231 2.2. File format
cannam@89 232
cannam@89 233 A gzip file consists of a series of "members" (compressed data
cannam@89 234 sets). The format of each member is specified in the following
cannam@89 235 section. The members simply appear one after another in the file,
cannam@89 236 with no additional information before, between, or after them.
cannam@89 237
cannam@89 238 2.3. Member format
cannam@89 239
cannam@89 240 Each member has the following structure:
cannam@89 241
cannam@89 242 +---+---+---+---+---+---+---+---+---+---+
cannam@89 243 |ID1|ID2|CM |FLG| MTIME |XFL|OS | (more-->)
cannam@89 244 +---+---+---+---+---+---+---+---+---+---+
cannam@89 245
cannam@89 246 (if FLG.FEXTRA set)
cannam@89 247
cannam@89 248 +---+---+=================================+
cannam@89 249 | XLEN |...XLEN bytes of "extra field"...| (more-->)
cannam@89 250 +---+---+=================================+
cannam@89 251
cannam@89 252 (if FLG.FNAME set)
cannam@89 253
cannam@89 254 +=========================================+
cannam@89 255 |...original file name, zero-terminated...| (more-->)
cannam@89 256 +=========================================+
cannam@89 257
cannam@89 258 (if FLG.FCOMMENT set)
cannam@89 259
cannam@89 260 +===================================+
cannam@89 261 |...file comment, zero-terminated...| (more-->)
cannam@89 262 +===================================+
cannam@89 263
cannam@89 264 (if FLG.FHCRC set)
cannam@89 265
cannam@89 266 +---+---+
cannam@89 267 | CRC16 |
cannam@89 268 +---+---+
cannam@89 269
cannam@89 270 +=======================+
cannam@89 271 |...compressed blocks...| (more-->)
cannam@89 272 +=======================+
cannam@89 273
cannam@89 274 0 1 2 3 4 5 6 7
cannam@89 275 +---+---+---+---+---+---+---+---+
cannam@89 276 | CRC32 | ISIZE |
cannam@89 277 +---+---+---+---+---+---+---+---+
cannam@89 278
cannam@89 279
cannam@89 280
cannam@89 281
cannam@89 282 Deutsch Informational [Page 5]
cannam@89 283
cannam@89 284 RFC 1952 GZIP File Format Specification May 1996
cannam@89 285
cannam@89 286
cannam@89 287 2.3.1. Member header and trailer
cannam@89 288
cannam@89 289 ID1 (IDentification 1)
cannam@89 290 ID2 (IDentification 2)
cannam@89 291 These have the fixed values ID1 = 31 (0x1f, \037), ID2 = 139
cannam@89 292 (0x8b, \213), to identify the file as being in gzip format.
cannam@89 293
cannam@89 294 CM (Compression Method)
cannam@89 295 This identifies the compression method used in the file. CM
cannam@89 296 = 0-7 are reserved. CM = 8 denotes the "deflate"
cannam@89 297 compression method, which is the one customarily used by
cannam@89 298 gzip and which is documented elsewhere.
cannam@89 299
cannam@89 300 FLG (FLaGs)
cannam@89 301 This flag byte is divided into individual bits as follows:
cannam@89 302
cannam@89 303 bit 0 FTEXT
cannam@89 304 bit 1 FHCRC
cannam@89 305 bit 2 FEXTRA
cannam@89 306 bit 3 FNAME
cannam@89 307 bit 4 FCOMMENT
cannam@89 308 bit 5 reserved
cannam@89 309 bit 6 reserved
cannam@89 310 bit 7 reserved
cannam@89 311
cannam@89 312 If FTEXT is set, the file is probably ASCII text. This is
cannam@89 313 an optional indication, which the compressor may set by
cannam@89 314 checking a small amount of the input data to see whether any
cannam@89 315 non-ASCII characters are present. In case of doubt, FTEXT
cannam@89 316 is cleared, indicating binary data. For systems which have
cannam@89 317 different file formats for ascii text and binary data, the
cannam@89 318 decompressor can use FTEXT to choose the appropriate format.
cannam@89 319 We deliberately do not specify the algorithm used to set
cannam@89 320 this bit, since a compressor always has the option of
cannam@89 321 leaving it cleared and a decompressor always has the option
cannam@89 322 of ignoring it and letting some other program handle issues
cannam@89 323 of data conversion.
cannam@89 324
cannam@89 325 If FHCRC is set, a CRC16 for the gzip header is present,
cannam@89 326 immediately before the compressed data. The CRC16 consists
cannam@89 327 of the two least significant bytes of the CRC32 for all
cannam@89 328 bytes of the gzip header up to and not including the CRC16.
cannam@89 329 [The FHCRC bit was never set by versions of gzip up to
cannam@89 330 1.2.4, even though it was documented with a different
cannam@89 331 meaning in gzip 1.2.4.]
cannam@89 332
cannam@89 333 If FEXTRA is set, optional extra fields are present, as
cannam@89 334 described in a following section.
cannam@89 335
cannam@89 336
cannam@89 337
cannam@89 338 Deutsch Informational [Page 6]
cannam@89 339
cannam@89 340 RFC 1952 GZIP File Format Specification May 1996
cannam@89 341
cannam@89 342
cannam@89 343 If FNAME is set, an original file name is present,
cannam@89 344 terminated by a zero byte. The name must consist of ISO
cannam@89 345 8859-1 (LATIN-1) characters; on operating systems using
cannam@89 346 EBCDIC or any other character set for file names, the name
cannam@89 347 must be translated to the ISO LATIN-1 character set. This
cannam@89 348 is the original name of the file being compressed, with any
cannam@89 349 directory components removed, and, if the file being
cannam@89 350 compressed is on a file system with case insensitive names,
cannam@89 351 forced to lower case. There is no original file name if the
cannam@89 352 data was compressed from a source other than a named file;
cannam@89 353 for example, if the source was stdin on a Unix system, there
cannam@89 354 is no file name.
cannam@89 355
cannam@89 356 If FCOMMENT is set, a zero-terminated file comment is
cannam@89 357 present. This comment is not interpreted; it is only
cannam@89 358 intended for human consumption. The comment must consist of
cannam@89 359 ISO 8859-1 (LATIN-1) characters. Line breaks should be
cannam@89 360 denoted by a single line feed character (10 decimal).
cannam@89 361
cannam@89 362 Reserved FLG bits must be zero.
cannam@89 363
cannam@89 364 MTIME (Modification TIME)
cannam@89 365 This gives the most recent modification time of the original
cannam@89 366 file being compressed. The time is in Unix format, i.e.,
cannam@89 367 seconds since 00:00:00 GMT, Jan. 1, 1970. (Note that this
cannam@89 368 may cause problems for MS-DOS and other systems that use
cannam@89 369 local rather than Universal time.) If the compressed data
cannam@89 370 did not come from a file, MTIME is set to the time at which
cannam@89 371 compression started. MTIME = 0 means no time stamp is
cannam@89 372 available.
cannam@89 373
cannam@89 374 XFL (eXtra FLags)
cannam@89 375 These flags are available for use by specific compression
cannam@89 376 methods. The "deflate" method (CM = 8) sets these flags as
cannam@89 377 follows:
cannam@89 378
cannam@89 379 XFL = 2 - compressor used maximum compression,
cannam@89 380 slowest algorithm
cannam@89 381 XFL = 4 - compressor used fastest algorithm
cannam@89 382
cannam@89 383 OS (Operating System)
cannam@89 384 This identifies the type of file system on which compression
cannam@89 385 took place. This may be useful in determining end-of-line
cannam@89 386 convention for text files. The currently defined values are
cannam@89 387 as follows:
cannam@89 388
cannam@89 389
cannam@89 390
cannam@89 391
cannam@89 392
cannam@89 393
cannam@89 394 Deutsch Informational [Page 7]
cannam@89 395
cannam@89 396 RFC 1952 GZIP File Format Specification May 1996
cannam@89 397
cannam@89 398
cannam@89 399 0 - FAT filesystem (MS-DOS, OS/2, NT/Win32)
cannam@89 400 1 - Amiga
cannam@89 401 2 - VMS (or OpenVMS)
cannam@89 402 3 - Unix
cannam@89 403 4 - VM/CMS
cannam@89 404 5 - Atari TOS
cannam@89 405 6 - HPFS filesystem (OS/2, NT)
cannam@89 406 7 - Macintosh
cannam@89 407 8 - Z-System
cannam@89 408 9 - CP/M
cannam@89 409 10 - TOPS-20
cannam@89 410 11 - NTFS filesystem (NT)
cannam@89 411 12 - QDOS
cannam@89 412 13 - Acorn RISCOS
cannam@89 413 255 - unknown
cannam@89 414
cannam@89 415 XLEN (eXtra LENgth)
cannam@89 416 If FLG.FEXTRA is set, this gives the length of the optional
cannam@89 417 extra field. See below for details.
cannam@89 418
cannam@89 419 CRC32 (CRC-32)
cannam@89 420 This contains a Cyclic Redundancy Check value of the
cannam@89 421 uncompressed data computed according to CRC-32 algorithm
cannam@89 422 used in the ISO 3309 standard and in section 8.1.1.6.2 of
cannam@89 423 ITU-T recommendation V.42. (See http://www.iso.ch for
cannam@89 424 ordering ISO documents. See gopher://info.itu.ch for an
cannam@89 425 online version of ITU-T V.42.)
cannam@89 426
cannam@89 427 ISIZE (Input SIZE)
cannam@89 428 This contains the size of the original (uncompressed) input
cannam@89 429 data modulo 2^32.
cannam@89 430
cannam@89 431 2.3.1.1. Extra field
cannam@89 432
cannam@89 433 If the FLG.FEXTRA bit is set, an "extra field" is present in
cannam@89 434 the header, with total length XLEN bytes. It consists of a
cannam@89 435 series of subfields, each of the form:
cannam@89 436
cannam@89 437 +---+---+---+---+==================================+
cannam@89 438 |SI1|SI2| LEN |... LEN bytes of subfield data ...|
cannam@89 439 +---+---+---+---+==================================+
cannam@89 440
cannam@89 441 SI1 and SI2 provide a subfield ID, typically two ASCII letters
cannam@89 442 with some mnemonic value. Jean-Loup Gailly
cannam@89 443 <gzip@prep.ai.mit.edu> is maintaining a registry of subfield
cannam@89 444 IDs; please send him any subfield ID you wish to use. Subfield
cannam@89 445 IDs with SI2 = 0 are reserved for future use. The following
cannam@89 446 IDs are currently defined:
cannam@89 447
cannam@89 448
cannam@89 449
cannam@89 450 Deutsch Informational [Page 8]
cannam@89 451
cannam@89 452 RFC 1952 GZIP File Format Specification May 1996
cannam@89 453
cannam@89 454
cannam@89 455 SI1 SI2 Data
cannam@89 456 ---------- ---------- ----
cannam@89 457 0x41 ('A') 0x70 ('P') Apollo file type information
cannam@89 458
cannam@89 459 LEN gives the length of the subfield data, excluding the 4
cannam@89 460 initial bytes.
cannam@89 461
cannam@89 462 2.3.1.2. Compliance
cannam@89 463
cannam@89 464 A compliant compressor must produce files with correct ID1,
cannam@89 465 ID2, CM, CRC32, and ISIZE, but may set all the other fields in
cannam@89 466 the fixed-length part of the header to default values (255 for
cannam@89 467 OS, 0 for all others). The compressor must set all reserved
cannam@89 468 bits to zero.
cannam@89 469
cannam@89 470 A compliant decompressor must check ID1, ID2, and CM, and
cannam@89 471 provide an error indication if any of these have incorrect
cannam@89 472 values. It must examine FEXTRA/XLEN, FNAME, FCOMMENT and FHCRC
cannam@89 473 at least so it can skip over the optional fields if they are
cannam@89 474 present. It need not examine any other part of the header or
cannam@89 475 trailer; in particular, a decompressor may ignore FTEXT and OS
cannam@89 476 and always produce binary output, and still be compliant. A
cannam@89 477 compliant decompressor must give an error indication if any
cannam@89 478 reserved bit is non-zero, since such a bit could indicate the
cannam@89 479 presence of a new field that would cause subsequent data to be
cannam@89 480 interpreted incorrectly.
cannam@89 481
cannam@89 482 3. References
cannam@89 483
cannam@89 484 [1] "Information Processing - 8-bit single-byte coded graphic
cannam@89 485 character sets - Part 1: Latin alphabet No.1" (ISO 8859-1:1987).
cannam@89 486 The ISO 8859-1 (Latin-1) character set is a superset of 7-bit
cannam@89 487 ASCII. Files defining this character set are available as
cannam@89 488 iso_8859-1.* in ftp://ftp.uu.net/graphics/png/documents/
cannam@89 489
cannam@89 490 [2] ISO 3309
cannam@89 491
cannam@89 492 [3] ITU-T recommendation V.42
cannam@89 493
cannam@89 494 [4] Deutsch, L.P.,"DEFLATE Compressed Data Format Specification",
cannam@89 495 available in ftp://ftp.uu.net/pub/archiving/zip/doc/
cannam@89 496
cannam@89 497 [5] Gailly, J.-L., GZIP documentation, available as gzip-*.tar in
cannam@89 498 ftp://prep.ai.mit.edu/pub/gnu/
cannam@89 499
cannam@89 500 [6] Sarwate, D.V., "Computation of Cyclic Redundancy Checks via Table
cannam@89 501 Look-Up", Communications of the ACM, 31(8), pp.1008-1013.
cannam@89 502
cannam@89 503
cannam@89 504
cannam@89 505
cannam@89 506 Deutsch Informational [Page 9]
cannam@89 507
cannam@89 508 RFC 1952 GZIP File Format Specification May 1996
cannam@89 509
cannam@89 510
cannam@89 511 [7] Schwaderer, W.D., "CRC Calculation", April 85 PC Tech Journal,
cannam@89 512 pp.118-133.
cannam@89 513
cannam@89 514 [8] ftp://ftp.adelaide.edu.au/pub/rocksoft/papers/crc_v3.txt,
cannam@89 515 describing the CRC concept.
cannam@89 516
cannam@89 517 4. Security Considerations
cannam@89 518
cannam@89 519 Any data compression method involves the reduction of redundancy in
cannam@89 520 the data. Consequently, any corruption of the data is likely to have
cannam@89 521 severe effects and be difficult to correct. Uncompressed text, on
cannam@89 522 the other hand, will probably still be readable despite the presence
cannam@89 523 of some corrupted bytes.
cannam@89 524
cannam@89 525 It is recommended that systems using this data format provide some
cannam@89 526 means of validating the integrity of the compressed data, such as by
cannam@89 527 setting and checking the CRC-32 check value.
cannam@89 528
cannam@89 529 5. Acknowledgements
cannam@89 530
cannam@89 531 Trademarks cited in this document are the property of their
cannam@89 532 respective owners.
cannam@89 533
cannam@89 534 Jean-Loup Gailly designed the gzip format and wrote, with Mark Adler,
cannam@89 535 the related software described in this specification. Glenn
cannam@89 536 Randers-Pehrson converted this document to RFC and HTML format.
cannam@89 537
cannam@89 538 6. Author's Address
cannam@89 539
cannam@89 540 L. Peter Deutsch
cannam@89 541 Aladdin Enterprises
cannam@89 542 203 Santa Margarita Ave.
cannam@89 543 Menlo Park, CA 94025
cannam@89 544
cannam@89 545 Phone: (415) 322-0103 (AM only)
cannam@89 546 FAX: (415) 322-1734
cannam@89 547 EMail: <ghost@aladdin.com>
cannam@89 548
cannam@89 549 Questions about the technical content of this specification can be
cannam@89 550 sent by email to:
cannam@89 551
cannam@89 552 Jean-Loup Gailly <gzip@prep.ai.mit.edu> and
cannam@89 553 Mark Adler <madler@alumni.caltech.edu>
cannam@89 554
cannam@89 555 Editorial comments on this specification can be sent by email to:
cannam@89 556
cannam@89 557 L. Peter Deutsch <ghost@aladdin.com> and
cannam@89 558 Glenn Randers-Pehrson <randeg@alumni.rpi.edu>
cannam@89 559
cannam@89 560
cannam@89 561
cannam@89 562 Deutsch Informational [Page 10]
cannam@89 563
cannam@89 564 RFC 1952 GZIP File Format Specification May 1996
cannam@89 565
cannam@89 566
cannam@89 567 7. Appendix: Jean-Loup Gailly's gzip utility
cannam@89 568
cannam@89 569 The most widely used implementation of gzip compression, and the
cannam@89 570 original documentation on which this specification is based, were
cannam@89 571 created by Jean-Loup Gailly <gzip@prep.ai.mit.edu>. Since this
cannam@89 572 implementation is a de facto standard, we mention some more of its
cannam@89 573 features here. Again, the material in this section is not part of
cannam@89 574 the specification per se, and implementations need not follow it to
cannam@89 575 be compliant.
cannam@89 576
cannam@89 577 When compressing or decompressing a file, gzip preserves the
cannam@89 578 protection, ownership, and modification time attributes on the local
cannam@89 579 file system, since there is no provision for representing protection
cannam@89 580 attributes in the gzip file format itself. Since the file format
cannam@89 581 includes a modification time, the gzip decompressor provides a
cannam@89 582 command line switch that assigns the modification time from the file,
cannam@89 583 rather than the local modification time of the compressed input, to
cannam@89 584 the decompressed output.
cannam@89 585
cannam@89 586 8. Appendix: Sample CRC Code
cannam@89 587
cannam@89 588 The following sample code represents a practical implementation of
cannam@89 589 the CRC (Cyclic Redundancy Check). (See also ISO 3309 and ITU-T V.42
cannam@89 590 for a formal specification.)
cannam@89 591
cannam@89 592 The sample code is in the ANSI C programming language. Non C users
cannam@89 593 may find it easier to read with these hints:
cannam@89 594
cannam@89 595 & Bitwise AND operator.
cannam@89 596 ^ Bitwise exclusive-OR operator.
cannam@89 597 >> Bitwise right shift operator. When applied to an
cannam@89 598 unsigned quantity, as here, right shift inserts zero
cannam@89 599 bit(s) at the left.
cannam@89 600 ! Logical NOT operator.
cannam@89 601 ++ "n++" increments the variable n.
cannam@89 602 0xNNN 0x introduces a hexadecimal (base 16) constant.
cannam@89 603 Suffix L indicates a long value (at least 32 bits).
cannam@89 604
cannam@89 605 /* Table of CRCs of all 8-bit messages. */
cannam@89 606 unsigned long crc_table[256];
cannam@89 607
cannam@89 608 /* Flag: has the table been computed? Initially false. */
cannam@89 609 int crc_table_computed = 0;
cannam@89 610
cannam@89 611 /* Make the table for a fast CRC. */
cannam@89 612 void make_crc_table(void)
cannam@89 613 {
cannam@89 614 unsigned long c;
cannam@89 615
cannam@89 616
cannam@89 617
cannam@89 618 Deutsch Informational [Page 11]
cannam@89 619
cannam@89 620 RFC 1952 GZIP File Format Specification May 1996
cannam@89 621
cannam@89 622
cannam@89 623 int n, k;
cannam@89 624 for (n = 0; n < 256; n++) {
cannam@89 625 c = (unsigned long) n;
cannam@89 626 for (k = 0; k < 8; k++) {
cannam@89 627 if (c & 1) {
cannam@89 628 c = 0xedb88320L ^ (c >> 1);
cannam@89 629 } else {
cannam@89 630 c = c >> 1;
cannam@89 631 }
cannam@89 632 }
cannam@89 633 crc_table[n] = c;
cannam@89 634 }
cannam@89 635 crc_table_computed = 1;
cannam@89 636 }
cannam@89 637
cannam@89 638 /*
cannam@89 639 Update a running crc with the bytes buf[0..len-1] and return
cannam@89 640 the updated crc. The crc should be initialized to zero. Pre- and
cannam@89 641 post-conditioning (one's complement) is performed within this
cannam@89 642 function so it shouldn't be done by the caller. Usage example:
cannam@89 643
cannam@89 644 unsigned long crc = 0L;
cannam@89 645
cannam@89 646 while (read_buffer(buffer, length) != EOF) {
cannam@89 647 crc = update_crc(crc, buffer, length);
cannam@89 648 }
cannam@89 649 if (crc != original_crc) error();
cannam@89 650 */
cannam@89 651 unsigned long update_crc(unsigned long crc,
cannam@89 652 unsigned char *buf, int len)
cannam@89 653 {
cannam@89 654 unsigned long c = crc ^ 0xffffffffL;
cannam@89 655 int n;
cannam@89 656
cannam@89 657 if (!crc_table_computed)
cannam@89 658 make_crc_table();
cannam@89 659 for (n = 0; n < len; n++) {
cannam@89 660 c = crc_table[(c ^ buf[n]) & 0xff] ^ (c >> 8);
cannam@89 661 }
cannam@89 662 return c ^ 0xffffffffL;
cannam@89 663 }
cannam@89 664
cannam@89 665 /* Return the CRC of the bytes buf[0..len-1]. */
cannam@89 666 unsigned long crc(unsigned char *buf, int len)
cannam@89 667 {
cannam@89 668 return update_crc(0L, buf, len);
cannam@89 669 }
cannam@89 670
cannam@89 671
cannam@89 672
cannam@89 673
cannam@89 674 Deutsch Informational [Page 12]
cannam@89 675