rfc1951.rar_RFC-1951_rfc1951中文_rfc195_rfc1951

共2个文件

pdf：1个

txt：1个

版权申诉

rfc1951

zlib

41 浏览量 2022-09-19 13:59:06 上传评论收藏 46KB RAR 举报

资源详情

资源评论

资源推荐

收起资源包目录

rfc1951.rar （2个子文件）

rfc1951.pdf 55KB

www.pudn.com.txt 218B

Network Working Group P. Deutsch

Request for Comments: 1951 Aladdin Enterprises

Category: Informational May 1996

DEFLATE Compressed Data Format Speciﬁcation version 1.3

Status of This Memo

This memo provides information for the Internet community. This memo does not specify an Internet stan-

dard 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



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, providedthat the copyrightnotice and

this notice are preserved, and that any substantivechanges 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 speciﬁcation deﬁnes a lossless compressed data format that compresses data using a combination of

the LZ77 algorithmand Huffman coding, with efﬁciency comparable to the best currently available general-

purpose compression methods. The data can be produced or consumed, even for an arbitrarily long sequen-

tiallypresentedinputdatastream, usingonlyan aprioriboundedamount of intermediatestorage. The format

can be implemented readily in a manner not covered by patents.

Deutsch Informational [Page 1]

RFC 1951 DEFLATE Compressed Data Format Speciﬁcation April 1996

Contents

1 Introduction . . .......................................... 2

1.1 Purpose ............................................ 2

1.2 Intendedaudience....................................... 2

1.3 Scope.............................................. 2

1.4 Compliance .......................................... 3

1.5 Deﬁnitions of terms and conventions used .......................... 3

1.6 Changesfrompreviousversions................................ 3

2 Compressedrepresentationoverview............................... 3

3 Detailedspeciﬁcation ....................................... 4

3.1 Overall conventions ...................................... 4

3.1.1 Packingintobytes ................................... 4

3.2 Compressedblockformat................................... 5

3.2.1 Synopsis of preﬁx and Huffman coding ........................ 5

3.2.2 UseofHuffmancodinginthe“deﬂate”format .................... 6

3.2.3 Detailsofblockformat................................. 7

3.2.4 Non-compressedblocks(BTYPE=00)......................... 9

3.2.5 Compressedblocks(lengthanddistancecodes).................... 9

3.2.6 CompressionwithﬁxedHuffmancodes(BTYPE=01) ................ 10

3.2.7 Compression with dynamic Huffman codes (BTYPE=10) .............. 10

3.3 Compliance .......................................... 12

4 Compressionalgorithmdetails .................................. 12

5 References............................................. 13

6 SecurityConsiderations...................................... 13

7 Sourcecode ............................................ 13

8 Acknowledgements ........................................ 14

9 Author’sAddress ......................................... 14

1 Introduction

1.1 Purpose

The purpose of this speciﬁcation is to deﬁne a lossless compressed data format that:



Is independent of CPU type, operating system, ﬁle system, and character set, and hence can be used

for interchange;



Can be produced or consumed, even for an arbitrarily long sequentially presented input data stream,

using only an aprioribounded amount of intermediate storage, and hence can be used in data com-

munications or similar structures such as Unix ﬁlters;

Deutsch Informational [Page 2]

RFC 1951 DEFLATE Compressed Data Format Speciﬁcation April 1996



Compresses data with efﬁciency comparable to the best currently available general-purpose compres-

sion 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 ﬁle 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 deﬁned by this speciﬁcation does not attempt to:



Allow random access to compressed data;



Compress specialized data (e.g., raster graphics) as well as the best currently available specialized al-

gorithms.

A simplecountingargumentshows thatno losslesscompressionalgorithmcancompress every possibleinput

data set. For the format deﬁned here, the worst case expansion is 5 bytes per 32K-byte block, i.e., a size

increase of 0.015% for large data sets. English text usually compresses by a factor of 2.5 to 3; executable

ﬁles usually compress somewhat less; graphical data such as raster images may compress much more.

1.2 Intended audience

This speciﬁcation is intended for use by implementors of software to compress data into “deﬂate” format

and/or decompress data from “deﬂate” format.

The text of the speciﬁcation assumes a basic background in programming at the level of bits and other prim-

itive data representations. Familiarity with the technique of Huffman coding is helpful but not required.

1.3 Scope

The speciﬁcation speciﬁes a method for representing a sequence of bytes as a (usually shorter) sequence of

bits, and a method for packing the latter bit sequence into 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 speciﬁcations presented here; a compliant compressor must produce data sets that

conform to all the speciﬁcations presented here.

1.5 Deﬁnitions of terms and conventions used

Byte: 8 bits stored or transmitted as a unit (same as an octet). For this speciﬁcation, a byte is exactly 8 bits,

even on machines which store a character on a number of bits different from eight. See below, for the num-

bering of bits within a byte.

Deutsch Informational [Page 3]

RFC 1951 DEFLATE Compressed Data Format Speciﬁcation April 1996

String: a sequence of arbitrary bytes.

1.6 Changes from previous versions

There have been no technical changes to the deﬂate format since version 1.1 of this speciﬁcation. In version

1.2, some terminology was changed. Version 1.3 is a conversion of the speciﬁcation to RFC style.

2 Compressed representation overview

A compressed data set consists of a series of blocks, corresponding to successive blocks of input data. The

block sizes are arbitrary, except that non-compressible blocks are limited to 65,535 bytes.

Each block is compressed using a combination of the LZ77 algorithm and Huffman coding. The Huffman

trees for each block are independent of those for previous or subsequent blocks; the LZ77 algorithm may use

a reference to a duplicated string occurring in a previous block, up to 32K input bytes before.

Each block consists of two parts: a pair of Huffman code trees that describe the representation of the com-

pressed data part, and a compressed data part. (The Huffman trees themselves are compressed using Huffman

encoding.) The compressed data consists of a series of elements of two types: literal bytes (of strings that

have not been detected as duplicatedwithin the previous 32K input bytes), and pointersto duplicatedstrings,

where a pointer is represented as a pair

length, backward distance

. The representation used in the “de-

ﬂate” format limits distances to 32K bytes and lengths to 258 bytes, but does not limit the size of a block,

except for uncompressible blocks, which are limited as noted above.

Each type of value (literals, distances, and lengths) in the compressed data is represented using a Huffman

code, using one code tree for literals and lengths and a separate code tree for distances. The code trees for

each block appear in a compact form just before the compressed data for that block.

3 Detailed speciﬁcation

3.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 Informational [Page 4]

RFC 1951 DEFLATE Compressed Data Format Speciﬁcation April 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-signiﬁcant bit, and since we

write numbers with the most-signiﬁcant digit on the left, we also write bytes with the most-signiﬁcant bit on

the left. In the diagrams below, we number the bits of a byte so that bit 0 is the least-signiﬁcant 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 least-signiﬁcant byte ﬁrst (at the lower memory address). For example, the decimal

number 520 is stored as:

+--------+--------+

|00001000|00000010|

+--------+--------+

ˆˆ

| + more significant byte = 2 x 256

+ less significant byte = 8

3.1.1 Packing into bytes

Thisdocumentdoesnotaddress the issueof theorder inwhichbitsof a bytearetransmittedon abit-sequential

medium, since the ﬁnal data format described here is byte- rather than bit-oriented. However, we describe

the compressed block format in below, as a sequence of data elements of various bit lengths, not a sequence

of bytes. We must therefore specify how to pack these data elements into bytes to form the ﬁnal compressed

byte sequence:



Dataelements are packed into bytesin orderof increasingbit number withinthe byte, i.e., startingwith

the least-signiﬁcant bit of the byte.



Data elements other than Huffman codes are packed starting with the least-signiﬁcant bit of the data

element.



Huffman codes are packed starting with the most-signiﬁcant bit of the code.

In other words, if one were to print out the compressed data as a sequence of bytes, starting with the ﬁrst

byte at the *right* margin and proceeding to the *left*, with the most-signiﬁcant bit of each byte on the left

as usual, one would be able to parse the result from right to left, with ﬁxed-width elements in the correct

MSB-to-LSB order and Huffman codes in bit-reversed order (i.e., with the ﬁrst bit of the code in the relative

LSB position).

Deutsch Informational [Page 5]

评论收藏

内容反馈

版权申诉

小波思基

粉丝: 70
资源: 1万+

rfc1951.rar_RFC-1951_rfc 1951 中文_rfc195_rfc1951_zlib

评论0

最新资源

rfc1951.rar_RFC-1951_rfc 1951 中文_rfc195_rfc1951_zlib

评论0

php.ini-development

FlashFXP_3.7.7.1317_Beta_SC

zlib-1.2.5

RFC1950(zlib compress)

zlib压缩算法规范文档

python模块详解

FlashFXP.rar绿色免安装中文版

艾伯特《Python标准库》中文版

ovbuilder：过度程序的生成器

miniz-master.zip

實現了 zlib 無損、高性能數據壓縮C開源庫 避開zlib使用抽象化的DEFLATE演算法的許可執照 替代zlib 壓縮算法

python3.6.5参考手册 chm

wireshark_websocket_deflate:提供用于Wireshark的LUA插件，如RFC7692中所述，该插件可扩展压缩的WebSocket有效负载

FlashFXP_3.6.0.1240注册版

【.Net 】Zip操作库

CRC-32 源代码 C，C++ 都能正常编译

Zstandard:Zstandard-快速实时压缩算法-开源

lsquic:LiteSpeed QUIC和HTTP3库

冰河的渗透实战笔记-冰河.pdf

大灰狼远控2021最新版，解压密码222

J-LINK V10 V11固件.rar

ISO21434.pdf

Web安全漏洞扫描工具-AWVS14

CTF 竞赛入门指南（ctf-all-in-one）.pdf

Web中间件常见漏洞总结.pdf

stm32f103 adc采样+dma传输+fft处理 频率计_fft处理_stm32_ADCFFT_频率计_ADC采样_

jts-1.14.zip

CobaltStrike4.4.zip

最新资源

實現了 zlib 無損、高性能數據壓縮C開源庫避開zlib使用抽象化的DEFLATE演算法的許可執照替代zlib 壓縮算法

stm32f103 adc采样+dma传输+fft处理频率计_fft处理_stm32_ADCFFT_频率计_ADC采样_