RFC1952 日本語訳
1952 GZIP file format specification version 4.3. P. Deutsch. May 1996. (Format: TXT=25036, PS=43337, PDF=43211 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group P. Deutsch Request for Comments: 1952 Aladdin Enterprises Category: Informational May 1996
コメントを求めるワーキンググループP.ドイツ語要求をネットワークでつないでください: 1952年のアラジンエンタープライズカテゴリ: 情報の1996年5月
GZIP file format specification version 4.3
GZIPファイル形式仕様バージョン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:
IESGは以下に注意します。
The IESG takes no position on the validity of any Intellectual Property Rights statements contained in this document.
IESGは本書では含まれたどんなIntellectual Property Rights声明の正当性の立場も全く取りません。
Notices
通知
Copyright (c) 1996 L. Peter Deutsch
Copyright(c)1996L.ピーター、ドイツ語
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/グラフィックス/png/ドキュメント/zlib/zdoc-index.html>でこの最新版への指針と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.
この仕様は広く使用されたGZIPユーティリティと互換性がある圧縮されたlosslessデータの形式を定義します。 形式はデータの汚染を検出するための周期冗長検査値を含んでいます。 形式を現在、圧縮のDEFLATEメソッドを使用しますが、他の圧縮方法を使用するために容易に広げることができます。 特許でカバーされなかった方法で容易に形式を実装することができます。
Deutsch Informational [Page 1] RFC 1952 GZIP File Format Specification May 1996
ドイツ語情報[1ページ]のRFC1952GZIPは書式仕様1996年5月にファイルします。
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. 序論… 2 1.1. 目的… 2 1.2. 聴衆は意図しました… 3 1.3. 範囲… 3 1.4. 承諾… 3 1.5. 用語と使用されるコンベンションの定義… 3 1.6. 旧バージョンからの変化… 3 2. 詳細な仕様… 4 2.1. 総合的なコンベンション… 4 2.2. 形式をファイルしてください… 5 2.3. メンバー形式… 5 2.3.1. メンバーヘッダーとトレーラ… 6 2.3.1.1. 付加的な分野… 8 2.3.1.2. 承諾… 9 3. 参照… 9 4. セキュリティ問題… 10 5. 承認… 10 6. 作者のアドレス… 10 7. 付録: ジーン-ループ川ゲイルのgzipユーティリティ… 11 8. 付録: CRCコードを抽出してください… 11
1. Introduction
1. 序論
1.1. Purpose
1.1. 目的
The purpose of this specification is to define a lossless
compressed data format that:
この仕様の目的がlosslessを定義するのがデータの形式を圧縮したということである、それ:
* 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.
* CPUタイプ、オペレーティングシステム、ファイルシステム、および文字集合から独立していて、したがって、置き換えに使用できます。 * 先験的な境界がある量の中間的ストレージだけを使用して、別のデータ・ストリームを起こすためにデータ・ストリームを圧縮するか、または減圧できて(手当たりしだいにアクセス可能なファイルと対照的に)、したがって、Unixフィルタなどのデータ通信か類似構造物で使用できます。 * 最も良い現在利用可能な汎用圧縮方法、特定で匹敵する効率が「湿布」よりかなり良いデータがプログラムする湿布。 * 特許でカバーされなかった方法で容易に実装することができて、したがって、自由に練習できます。 * 広く使用された現在のgzipユーティリティによって作り出されるファイル形式と互換性があって、そんなに従っている減圧装置で既存のgzipコンプレッサーによって作り出されたデータは読むことができるでしょう。
Deutsch Informational [Page 2] RFC 1952 GZIP File Format Specification May 1996
ドイツ語情報[2ページ]のRFC1952GZIPは書式仕様1996年5月にファイルします。
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
1.2. 対象とする訪問者
This specification is intended for use by implementors of software
to compress data into gzip format and/or decompress data from gzip
format.
この仕様はソフトウェアの作成者による使用がgzip形式にデータを圧縮する、そして/または、gzip形式からデータを減圧することを意図します。
The text of the specification assumes a basic background in
programming at the level of bits and other primitive data
representations.
仕様のテキストはビットと他の原始のデータ表現のレベルでプログラムを作る際に基本的なバックグラウンドを仮定します。
1.3. Scope
1.3. 範囲
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).
仕様は圧縮方法とファイル形式(ファイルが任意のバイトの系列を保存できるだけであると仮定する後者)を指定します。 それは文字集合かencodings(任意のファイル名とコメントを除いた)の周りでファイルシステムか何かにどんな特定のインタフェースも指定しません。
1.4. Compliance
1.4. 承諾
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
1.5. 用語と使用されるコンベンションの定義
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.
バイト: 8ビットは、ユニットとして(八重奏と同じ)で保存したか、または伝わりました。 (この仕様に関して、1バイトはちょうど8ビットです、8と異なった多くのビットの上にキャラクタを保存するマシンの上でさえ。) ビットの付番に関して1バイト以内で以下を見てください。
1.6. Changes from previous versions
1.6. 旧バージョンからの変化
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スタイルへの仕様の変換です。
Deutsch Informational [Page 3] RFC 1952 GZIP File Format Specification May 1996
ドイツ語情報[3ページ]のRFC1952GZIPは書式仕様1996年5月にファイルします。
2. Detailed specification
2. 仕様詳細
2.1. Overall conventions
2.1. 総合的なコンベンション
In the diagrams below, a box like this:
以下のダイヤグラム、このような箱の中に:
+---+
| | <-- the vertical bars might be missing
+---+
+---+ | | <-- 縦棒は+を逃しているかもしれません。---+
represents one byte; a box like this:
1バイトを表します。 このような箱:
+==============+
| |
+==============+
+==============+ | | +==============+
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:
それらが一体にしていつも扱われるので、コンピュータの中に保存されたバイトは「噛み付いているオーダー」を持っていません。 しかしながら、0〜255の整数であるとみなされた1バイトはだいたいと最少重要なビットを持っています、そして、左における最も多くの有効数字に従った数を書くので、また、私たちは大部分が重要な状態で左で噛み付かれたバイトを書きます。 以下のダイヤグラムで、私たちが1バイトのビットに付番するのでビット0が最下位ビットである、すなわち、ビットは番号付です:
+--------+
|76543210|
+--------+
+--------+ |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.
このドキュメントは1バイトのビットが少し連続した媒体の上で伝えられるオーダーの問題を扱いません、ここで説明されたデータの形式がビット指向であるよりむしろバイトであるので。
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:
コンピュータの中では、数は複数のバイトを占領するかもしれません。 ここで説明された形式のすべてのマルチバイト番号が最初に(下側のメモリアドレスで)、最も最少に重要なバイトで保存されます。 例えば、10進数520は以下として保存されます。
0 1
+--------+--------+
|00001000|00000010|
+--------+--------+
^ ^
| |
| + more significant byte = 2 x 256
+ less significant byte = 8
0 1 +--------+--------+ |00001000|00000010| +--------+--------+ ^ ^ | | | + それほどより重要なバイト=2x256+重要でないバイト=8
Deutsch Informational [Page 4] RFC 1952 GZIP File Format Specification May 1996
ドイツ語情報[4ページ]のRFC1952GZIPは書式仕様1996年5月にファイルします。
2.2. File format
2.2. ファイル形式
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.
gzipファイルは一連の「メンバー」(圧縮されたデータセット)から成ります。 それぞれのメンバーの形式は以下のセクションで指定されます。 メンバーはファイルで追加情報なしでそれらの間それらの前、または彼らの後に単に相次いで見えます。
2.3. Member format
2.3. メンバー形式
Each member has the following structure:
各メンバーには、以下の構造があります:
+---+---+---+---+---+---+---+---+---+---+
|ID1|ID2|CM |FLG| MTIME |XFL|OS | (more-->)
+---+---+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+ |ID1|ID2|CM|FLG| MTIME|XFL|OS| (以上-->) +---+---+---+---+---+---+---+---+---+---+
(if FLG.FEXTRA set)
(FLG.FEXTRAがセットしたなら)
+---+---+=================================+
| XLEN |...XLEN bytes of "extra field"...| (more-->)
+---+---+=================================+
+---+---+=================================+ | XLEN|...XLENバイトの「付加的な分野」…| (以上-->) +---+---+=================================+
(if FLG.FNAME set)
(FLG.FNAMEがセットしたなら)
+=========================================+
|...original file name, zero-terminated...| (more-->)
+=========================================+
+=========================================+ |...元のファイル名であって、無終えられる…| (以上-->) +=========================================+
(if FLG.FCOMMENT set)
(FLG.FCOMMENTがセットしたなら)
+===================================+
|...file comment, zero-terminated...| (more-->)
+===================================+
+===================================+ |...無終えられた状態でコメントをファイルしてください…| (以上-->) +===================================+
(if FLG.FHCRC set)
(FLG.FHCRCがセットしたなら)
+---+---+
| CRC16 |
+---+---+
+---+---+ | CRC16| +---+---+
+=======================+
|...compressed blocks...| (more-->)
+=======================+
+=======================+ |...ブロックを圧縮します…| (以上-->) +=======================+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| CRC32 | ISIZE |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | CRC32| ISIZE| +---+---+---+---+---+---+---+---+
Deutsch Informational [Page 5] RFC 1952 GZIP File Format Specification May 1996
ドイツ語情報[5ページ]のRFC1952GZIPは書式仕様1996年5月にファイルします。
2.3.1. Member header and trailer
2.3.1. メンバーヘッダーとトレーラ
ID1 (IDentification 1)
ID2 (IDentification 2)
These have the fixed values ID1 = 31 (0x1f, %%BODY%%37), ID2 = 139
(0x8b, \213), to identify the file as being in gzip format.
ID1(IDentification1)ID2、(IDentification2) これらには、ファイルがgzip形式にあることであると認識するために、一定の価値ID1=31(0x1f、037円)、ID2=139(0x8b、213円)があります。
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.
CM、(圧縮Method) これはファイルで使用される圧縮方法を特定します。 CM=0-7は予約されています。 CM=8は「空気を抜いてください」という圧縮方法を指示します。(それは、gzipによって通例に使用されたものであり、ほかの場所に記録されます)。
FLG (FLaGs)
This flag byte is divided into individual bits as follows:
FLG、(FLaGs) このフラグバイトは以下の個々のビットに分割されます:
bit 0 FTEXT
bit 1 FHCRC
bit 2 FEXTRA
bit 3 FNAME
bit 4 FCOMMENT
bit 5 reserved
bit 6 reserved
bit 7 reserved
ビット0FTEXTビット1FHCRCビット2FEXTRAビット3FNAMEビット4FCOMMENTは予約された6ビット7が予約した予約された5ビットに噛み付きました。
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.
FTEXTが用意ができているなら、ファイルはたぶんASCIIテキストです。 これは任意の指示です。(コンプレッサーは、何か非ASCII文字に出席しているかどうかを見るように少量の入力データをチェックすることによって、その指示を設定するかもしれません)。 バイナリ・データを示して、疑わしい場合は、FTEXTはきれいにされます。 ASCIIテキストとバイナリ・データのための異なったファイル形式を持っているシステムのために、減圧装置は適切な形式を選ぶFTEXTを使用できます。 私たちは故意にこのビットを設定するのに使用されるアルゴリズムを指定しません、コンプレッサーにはそれを晴れるままにするオプションがいつもあって、それを無視して、ある他のプログラムをさせるオプションがいつも減圧装置でデータ変換の問題を扱うので。
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.]
FHCRCが用意ができているなら、gzipヘッダーのためのCRC16は圧縮されたデータの直前存在しています。 CRC16はgzipヘッダーのすべてのバイトCRC32の最も重要でないバイトが上昇する2から成りますが、CRC16を含んでいるのが成りません。 [FHCRCビットはgzip最大1.2.4のバージョンによって決して設定されませんでした、異なった意味がgzipにある状態でそれが記録されましたが1.2、.4、]。
If FEXTRA is set, optional extra fields are present, as
described in a following section.
FEXTRAが用意ができているなら、任意の付加的な分野は以下の章で説明されるように存在しています。
Deutsch Informational [Page 6] RFC 1952 GZIP File Format Specification May 1996
ドイツ語情報[6ページ]のRFC1952GZIPは書式仕様1996年5月にファイルします。
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.
FNAMEが用意ができているなら、元のファイル名は、存在していて、バイトをゼロで終えました。 名前はISO8859-1(ラテン語-1)キャラクタから成らなければなりません。 ファイル名にEBCDICかいかなる他の文字集合も使用するオペレーティングシステムでは、ISO LATIN-1文字集合に名前を翻訳しなければなりません。 これは圧縮されるのでそして、ファイルシステムの上に圧縮されるファイルが大文字と小文字を区別しない名前と共にあるなら取り除かれたどんなディレクトリの部品でもやむを得ずケースを下ろしたファイルのオリジナルの名前です。 データが指定されたファイル以外のソースから圧縮されたなら、元のファイル名が全くありません。 例えば、ソースがUnixシステムの上のstdinであったなら、ファイル名が全くありません。
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).
FCOMMENTが用意ができているなら、無終えられたファイルコメントは存在しています。 このコメントは解釈されません。 それは人間の消費で意図するだけです。 コメントはISO8859-1(ラテン語-1)キャラクタから成らなければなりません。 ただ一つの改行文字(10小数)によってラインブレイクは指示されるべきです。
Reserved FLG bits must be zero.
予約されたFLGビットはゼロであるに違いありません。
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.
圧縮されていて、これがオリジナルの最新の変更時間を与えるMTIME(変更タイム誌)はファイルします。 1970年1月1日に、すなわち、Unix形式、グリニッジ標準時0時0分0秒以来の秒に、時間があります。 (これがUniversal時間よりむしろMS-DOSのための問題と他のシステムに地方でその使用を引き起こすかもしれないことに注意してください。) 圧縮されたデータがファイルから来なかったなら、MTIMEは圧縮時に用意ができています。 MTIME=0は、どんなタイムスタンプも利用可能でないことを意味します。
XFL (eXtra FLags)
These flags are available for use by specific compression
methods. The "deflate" method (CM = 8) sets these flags as
follows:
これらの旗が利用可能であるXFL(eXtra FLags)は特定の圧縮でメソッドを使用します。 「空気を抜いてください」というメソッド(CM=8)は以下のこれらの旗を設定します:
XFL = 2 - compressor used maximum compression,
slowest algorithm
XFL = 4 - compressor used fastest algorithm
XFL=2--コンプレッサーは最大の圧縮、最も遅いアルゴリズムXFL=4を使用しました--コンプレッサーは最も速いアルゴリズムを使用しました。
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:
これがタイプを特定するOS(操作System)は圧縮が行われたシステムをファイルします。 これはテキストファイルのために行末規約を決定する際に役に立つかもしれません。 現在定義された値は以下の通りです:
Deutsch Informational [Page 7] RFC 1952 GZIP File Format Specification May 1996
ドイツ語情報[7ページ]のRFC1952GZIPは書式仕様1996年5月にファイルします。
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
0--FATファイルシステム(MS-DOS、OS/2、NT/Win32)1--アミーガ2--VMS(または、OpenVMS)3--unix4--VM/CMS5--アタリTOS6--HPFSファイルシステム(OS/2、NT)7--マッキントッシュ8--Z-システム9--CP/M10--TOPS-20 11--NTFSファイルシステム(NT)12--未知のQDOS13(ドングリRISCOS255)
XLEN (eXtra LENgth)
If FLG.FEXTRA is set, this gives the length of the optional
extra field. See below for details.
FLG.FEXTRAがあるなら、XLEN(eXtra LENgth)はセットして、これは任意の付加的な分野の長さを与えます。 詳細に関して以下を見てください。
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.)
CRC32、(CRC-32) これは3309年のISO規格とセクション8.1.1.6.2ITU-T推薦V.42に使用されるCRC-32アルゴリズムによると、計算された解凍されたデータのCyclic Redundancy Check値を含んでいます。 (ISOにドキュメントを注文するために http://www.iso.ch を見てください。 ITU-T V.42のオンラインバージョンに関してリス://info.itu.chを見てください。)
ISIZE (Input SIZE)
This contains the size of the original (uncompressed) input
data modulo 2^32.
ISIZE、(入力SIZE)これはオリジナル(解凍される)の入力データ法2^32のサイズを含んでいます。
2.3.1.1. Extra field
2.3.1.1. 付加的な分野
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:
FLG.FEXTRAビットが設定されるなら、「付加的な分野」はヘッダーに全長XLENバイトについて存在しています。 それは一連の部分体、それぞれのフォームから成ります:
+---+---+---+---+==================================+
|SI1|SI2| LEN |... LEN bytes of subfield data ...|
+---+---+---+---+==================================+
+---+---+---+---+==================================+ |SI1|SI2| レン|... LENバイトの部分体データ…| +---+---+---+---+==================================+
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:
SI1とSI2は部分体ID、通常2個のASCII手紙を何らかの簡略記憶値に提供します。 ジーン-ループ川 Gailly <gzip@prep.ai.mit.edu 、gt;、部分体IDの登録を維持しています。 あなたが使用したいあらゆる部分体IDを彼に送ってください。 SI2=0がある部分体IDは今後の使用のために予約されます。 以下のIDは現在、定義されます:
Deutsch Informational [Page 8] RFC 1952 GZIP File Format Specification May 1996
ドイツ語情報[8ページ]のRFC1952GZIPは書式仕様1996年5月にファイルします。
SI1 SI2 Data
---------- ---------- ----
0x41 ('A') 0x70 ('P') Apollo file type information
SI1 SI2データ---------- ---------- ---- 0×41 ('A')0x70('P')アポロファイルの種類情報
LEN gives the length of the subfield data, excluding the 4
initial bytes.
初期の4バイトを除いて、LENは部分体データの長さを与えます。
2.3.1.2. Compliance
2.3.1.2. 承諾
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.
言いなりになっているコンプレッサーは、正しいID1、ID2、CM、CRC32、およびISIZEと共にファイルを作り出さなければなりませんが、デフォルト値(OSのための255、すべての他のもののための0)へのヘッダーの固定長一部に他のすべての分野をはめ込むかもしれません。 コンプレッサーはすべての予約されたビットをゼロに設定しなければなりません。
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.
これらのどれかに不正確な値があるなら、対応する減圧装置は、ID1、ID2、およびCMをチェックして、誤り表示を提供しなければなりません。 それは、それらが存在しているなら任意の野原を飛ばすことができるようにFEXTRA/XLEN、FNAME、FCOMMENT、および少なくともFHCRCを調べなければなりません。 それはヘッダーかトレーラのいかなる他の部分も調べる必要はありません。 減圧装置は、特に、FTEXTとOSを無視して、いつも2進の出力を起こして、まだ対応するかもしれません。 対応する減圧装置は何か予約されたビットが非ゼロであるなら誤り表示を与えなければなりません、そのようなものが不当に順次データを解釈する新しい分野の存在を少し示すかもしれないので。
3. References
3. 参照
[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/
[1]、「情報Processing--8ビットの単一のバイトコード化された図形文字セット--第1部:、」 ローマ字No.1インチ(ISO8859-1: 1987)。 ISO8859-1(ラテン-1)文字集合は7ビットのASCIIのスーパーセットです。 この文字集合を定義するファイルはiso_8859-1 ftp://ftp.uu.net/graphics/png/documents/ の*として利用可能です。
[2] ISO 3309
[2] ISO3309
[3] ITU-T recommendation V.42
[3] ITU-T推薦V.42
[4] Deutsch, L.P.,"DEFLATE Compressed Data Format Specification",
available in ftp://ftp.uu.net/pub/archiving/zip/doc/
[4] ドイツ語、L.P.、 ftp://ftp.uu.net/pub/archiving/zip/doc/ で利用可能な"DEFLATE Compressed Data Format Specification"
[5] Gailly, J.-L., GZIP documentation, available as gzip-*.tar in
ftp://prep.ai.mit.edu/pub/gnu/
[5]ゲイル、J.-L.、 ftp://prep.ai.mit.edu/pub/gnu/ のgzip-*.tarとして利用可能なGZIPドキュメンテーション
[6] Sarwate, D.V., "Computation of Cyclic Redundancy Checks via Table
Look-Up", Communications of the ACM, 31(8), pp.1008-1013.
[6]Sarwate、D.V.、「Tableを通したCyclic Redundancy Checksの計算、ほら、-上昇してください、」、ACM、31(8)、pp.1008-1013のCommunications。
Deutsch Informational [Page 9] RFC 1952 GZIP File Format Specification May 1996
ドイツ語情報[9ページ]のRFC1952GZIPは書式仕様1996年5月にファイルします。
[7] Schwaderer, W.D., "CRC Calculation", April 85 PC Tech Journal,
pp.118-133.
[7]Schwaderer、W.D.、「CRC計算」、4月85日のPC Tech Journal、pp.118-133。
[8] ftp://ftp.adelaide.edu.au/pub/rocksoft/papers/crc_v3.txt,
describing the CRC concept.
[8] CRC概念について説明する ftp://ftp.adelaide.edu.au/pub/rocksoft/papers/crc_v3.txt 。
4. Security Considerations
4. セキュリティ問題
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.
このデータの形式を使用するシステムが圧縮されたデータの保全を有効にするいくつかの手段を提供するのは、お勧めです、CRC-32チェック価値を設定して、チェックするのなどように。
5. Acknowledgements
5. 承認
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.
ジーン-ループ川ゲイルは、gzip形式を設計して、マーク・アドラーと共にこの仕様で説明された関連するソフトウェアを書きました。 グレン・ラナース-パーソンはRFCとHTML形式にこのドキュメントを変換しました。
6. Author's Address
6. 作者のアドレス
L. Peter Deutsch Aladdin Enterprises 203 Santa Margarita Ave. Menlo Park, CA 94025
L.ピータードイツ語アラジンエンタープライズ203サンタマルガリータAve。 メンローパーク、カリフォルニア 94025
Phone: (415) 322-0103 (AM only) FAX: (415) 322-1734 EMail: <ghost@aladdin.com>
以下に電話をしてください。 (415) 322-0103(AM専用)FAX: (415) 322-1734 メールしてください: <幽霊@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>
ジーン-ループ川 Gailly <gzip@prep.ai.mit.edu 、gt;、 Adler <madler@alumni.caltech.edu をマークしてください、gt。
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>
L.ピーター Deutsch <ghost@aladdin.com 、gt;、グレン Randers-Pehrson <randeg@alumni.rpi.edu 、gt。
Deutsch Informational [Page 10] RFC 1952 GZIP File Format Specification May 1996
ドイツ語情報[10ページ]のRFC1952GZIPは書式仕様1996年5月にファイルします。
7. Appendix: Jean-Loup Gailly's gzip utility
7. 付録: ジーン-ループ川ゲイルのgzipユーティリティ
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.
gzip圧縮の最も広く使用された実装、およびこの仕様が基づいているオリジナルのドキュメンテーションがジーン-ループ川 Gailly <gzip@prep.ai.mit.edu によって作成された、gt。 この実装がデファクトスタンダードであるので、私たちは特徴のそれ以上についてここに言及します。 一方、このセクションの材料はそういうものの仕様の一部ではありません、そして、実装は言いなりになるためにそれに続く必要はありません。
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.
ファイルを圧縮するか、または減圧するとき、gzipは保護、所有権、およびローカルファイルシステムの上の変更時間属性を保持します、保護属性を表すことへのどんな支給もgzipファイル形式自体でないので。 ファイル形式が変更時間を含んでいるので、gzip減圧装置は圧縮された入力の地方の変更時間よりむしろファイルから変更時間を割り当てるコマンドラインスイッチを提供します、減圧された出力に。
8. Appendix: Sample CRC Code
8. 付録: サンプルCRCコード
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.)
以下のサンプルコードはCRC(周期的なRedundancy Check)の実用的な実装を表します。 (また、形式仕様に関してISO3309とITU-T V.42を見てください。)
The sample code is in the ANSI C programming language. Non C users may find it easier to read with these hints:
ANSI Cプログラミング言語にはサンプルコードがあります。 非Cユーザは、これらのヒントで読書するのが、より簡単であることがわかるかもしれません:
& 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).
ANDオペレータをBitwiseします。 ^は排他的論理和オペレータをBitwiseします。 >>は正しいシフトオペレータをBitwiseします。 正しいシフト差し込みがここで左におけるビットのゼロに合っていて未署名の量に適用されると。 ! 論理的なNOTオペレータ。 + +、「n++」は可変nを増加します。 0xNNN 0xは16進(ベース16)定数を導入します。 接尾語Lは長い値(少なくとも32ビット)を示します。
/* Table of CRCs of all 8-bit messages. */
unsigned long crc_table[256];
すべての8ビットのメッセージのCRCsの/*テーブル。 */未署名の長いcrc_テーブル[256]。
/* Flag: has the table been computed? Initially false. */
int crc_table_computed = 0;
/*旗: テーブルを計算してありますか? 初めは、誤っています。 */int crc_テーブル_は=0を計算しました。
/* Make the table for a fast CRC. */
void make_crc_table(void)
{
unsigned long c;
/*は速いCRCのためにテーブルを作ります。 */空間造_crc_テーブル(空間)、未署名の長いc。
Deutsch Informational [Page 11] RFC 1952 GZIP File Format Specification May 1996
ドイツ語情報[11ページ]のRFC1952GZIPは書式仕様1996年5月にファイルします。
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;
}
int n、k。 (n=0;n<256;n++)、(k=0; k<8; k++)のためのc=(未署名の長さ)n、(cと1)である、0xedb88320L c=^(c>>1);、ほか、c>c=>1;、crc_テーブル[n]はcと等しいです;、crc_テーブル_は=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:
/*は、バイトbuf[0..len-1]で実行しているcrcをアップデートして、アップデートされたcrcを返します。 crcはゼロに初期化されるべきです。 そして、プレ、ポストを条件とさせる(1の補数)がこの機能の中で実行されるので、訪問者はそれをするべきではありません。 使用例:
unsigned long crc = 0L;
未署名の長い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;
(_バッファ(バッファ、長さ)!=EOFを読みます) crc=アップデート_crc(crc、バッファ、長さ); (crc!はオリジナル_crcと等しいです)誤り()であるなら。 */未署名の長いアップデート_crc(未署名の長いcrc、未署名の炭の*をbufされます、int len)、未署名の長い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;
}
_(計算されたcrc_テーブル_)が_crcを作るなら、()をテーブルの上に置いてください。 (n=0; n<len; n++) crc_テーブル(c^buf[n])と0xff]c=^(c>>8); 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);
}
/*はバイトbuf[0..len-1]のCRCを返します。 */無記名の長いcrc(無記名の炭*buf、int len)リターンアップデート_crc(0L、buf、len)。
Deutsch Informational [Page 12]
ドイツ語Informationalです。[12ページ]
一覧
スポンサーリンク
