Internet Engineering Task Force (IETF) J. Alakuijala
Request for Comments: 9841 T. Duong
Updates: 7932 E. Kliuchnikov
Category: Informational Z. Szabadka
ISSN: 2070-1721 L. Vandevenne, Ed.
Google, Inc.
September 2025
This specification defines a data format for shared brotli compression, which adds support for shared dictionaries, large window, and a container format to brotli (RFC 7932). Shared dictionaries and large window support allow significant compression gains compared to regular brotli. This document specifies an extension to the method defined in RFC 7932.
この仕様では、共有Brotli圧縮のデータ形式を定義します。これにより、共有辞書、大きなウィンドウ、およびBrotliにコンテナ形式のサポートが追加されます（RFC 7932）。共有辞書と大きなウィンドウサポートにより、通常のBrotliと比較して大幅な圧縮ゲインが可能になります。このドキュメントは、RFC 7932で定義されているメソッドの拡張機能を指定します。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9841.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9841で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Purpose
1.2. Intended Audience
1.3. Scope
1.4. Compliance
1.5. Definitions of Terms and Conventions Used
1.5.1. Packing into Bytes
2. Shared Brotli Overview
3. Shared Dictionaries
3.1. Custom Static Dictionaries
3.1.1. Transform Operations
3.2. LZ77 Dictionaries
4. Varint Encoding
5. Shared Dictionary Stream
6. Large Window Brotli Compressed Data Stream
7. Shared Brotli Compressed Data Stream
8. Shared Brotli Framing Format Stream
8.1. Main Format
8.2. Chunk Format
8.3. Metadata Format
8.4. Chunk Specifications
8.4.1. Padding Chunk (Type 0)
8.4.2. Metadata Chunk (Type 1)
8.4.3. Data Chunk (Type 2)
8.4.4. First Partial Data Chunk (Type 3)
8.4.5. Middle Partial Data Chunk (Type 4)
8.4.6. Last Partial Data Chunk (Type 5)
8.4.7. Footer Metadata Chunk (Type 6)
8.4.8. Global Metadata Chunk (Type 7)
8.4.9. Repeat Metadata Chunk (Type 8)
8.4.10. Central Directory Chunk (Type 9)
8.4.11. Final Footer Chunk (Type 10)
8.4.12. Chunk Ordering
9. Security Considerations
10. IANA Considerations
11. References
11.1. Normative References
11.2. Informative References
Acknowledgments
Authors' Addresses
The purpose of this specification is to extend the brotli compressed data format [RFC7932] with new abilities that allow further compression gains.
この仕様の目的は、Brotli圧縮データ形式[RFC7932]を、さらなる圧縮ゲインを可能にする新しい能力で拡張することです。
* Shared dictionaries allow a static shared context between encoder and decoder for significant compression gains.
* 共有辞書により、エンコーダーとデコーダー間の静的共有コンテキストを使用すると、大幅な圧縮ゲインが得られます。
* Large window brotli allows much larger back reference distances to give compression gains for files over 16 MiB.
* 大きなウィンドウBrotliにより、16 MIBを超えるファイルの圧縮ゲインがはるかに大きくなります。
* The framing format is a container format that allows storage of multiple resources and references dictionaries.
* フレーミング形式は、複数のリソースと参照辞書の保存を許可するコンテナ形式です。
This document is the authoritative specification of shared brotli data formats and the backwards compatible changes to brotli. This document also defines the following:
このドキュメントは、共有Brotliデータ形式の権威ある仕様とBrotliへの逆方向の互換性のある変更です。このドキュメントは、次のことも定義しています。
* The data format of serialized shared dictionaries
* シリアル化された共有辞書のデータ形式
* The data format of the framing format
* フレーミング形式のデータ形式
* The encoding of window bits and distances for large window brotli in the brotli data format
* Brotliデータ形式の大きなウィンドウBrotliのウィンドウビットと距離のエンコード
* The encoding of shared dictionary references in the brotli data format
* Brotliデータ形式での共有辞書参照のエンコード
This specification is intended for use by software implementers to compress data into and/or decompress data from the shared brotli dictionary format.
この仕様は、ソフトウェア実装者が共有Brotli辞書形式からデータを圧縮および/または解凍するために使用することを目的としています。
The text of the specification assumes a basic background in programming at the level of bits and other primitive data representations. Familiarity with the technique of LZ77 coding [LZ77] is helpful, but not required.
仕様のテキストは、ビットのレベルやその他の原始的なデータ表現のレベルでのプログラミングの基本的な背景を想定しています。LZ77コーディング[LZ77]の手法に精通することは役立ちますが、必要ありません。
This specification defines a data format for shared brotli compression, which adds support for dictionaries and extended features to brotli [RFC7932].
この仕様は、共有Brotli圧縮のデータ形式を定義します。これにより、辞書と拡張機能のサポートがBrotli [RFC7932]にサポートされます。
Unless otherwise indicated below, a compliant decompressor must be able to accept and decompress any data set that conforms to all the specifications presented here. Additionally, a compliant compressor must produce data sets that conform to all the specifications presented here.
以下に特に示されない限り、準拠した減圧器は、ここに示されているすべての仕様に準拠するデータセットを受け入れて減圧することができなければなりません。さらに、準拠したコンプレッサーは、ここに示されているすべての仕様に準拠するデータセットを生成する必要があります。
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 that store a character on a number of bits different from eight. See below for the numbering of bits within a byte.
ユニットとして保存または送信された8ビット（オクテットと同じ）。この仕様では、バイトは8ビットと正確に8ビットです。8つとは異なる多数のビットにキャラクターを保存するマシンでも。バイト内のビットの番号付けについては、以下を参照してください。
String:
弦：
A sequence of arbitrary 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 significant bit (MSB) and least significant bit (LSB), and since we write numbers with the most significant digit on the left, we also write bytes with the MSB on the left. In the diagrams below, the bits of a byte are written so that bit 0 is the LSB, i.e., the bits are numbered as follows:
コンピューター内に保存されているバイトには、常にユニットとして扱われているため、「ビット注文」はありません。ただし、0〜255の間の整数と見なされるバイトは、最も有意なビット（MSB）と最小の有意ビット（LSB）を持ち、左側に最も重要な数字で数字を記述するため、左側にMSBが付いたバイトも書きます。以下の図では、ビット0がLSBであるように、バイトのビットが書かれています。つまり、ビットに次のように番号が付けられています。
+--------+
|76543210|
+--------+
Within a computer, a number may occupy multiple bytes. All multi-byte numbers in the format described here are unsigned and stored with the least significant byte first (at the lower memory address). For example, the decimal 16-bit number 520 is stored as:
コンピューター内では、数字が複数のバイトを占める場合があります。ここで説明する形式のすべてのマルチバイト数値は署名されておらず、最初に最も有意なバイトで保存されます（メモリアドレスの下部）。たとえば、小数点以下の16ビット番号520は次のように保存されます。
0 1
+--------+--------+
|00001000|00000010|
+--------+--------+
^ ^
| |
| + more significant byte = 2 x 256
+ less significant byte = 8
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 final data format described here is byte- rather than bit-oriented. However, the compressed block format is described below as a sequence of data elements of various bit lengths, not a sequence of bytes. Therefore, we must specify how to pack these data elements into bytes to form the final compressed byte sequence:
このドキュメントは、ここで説明する最終的なデータ形式はビット指向ではなくバイト形式であるため、バイトのビットが少しシーケンシャルメディアに送信される順序の問題に対処しません。ただし、圧縮ブロック形式は、バイトのシーケンスではなく、さまざまなビット長のデータ要素のシーケンスとして説明されています。したがって、これらのデータ要素をバイトにパックする方法を指定して、最終的な圧縮バイトシーケンスを形成する必要があります。
* Data elements are packed into bytes in order of increasing bit number within the byte, i.e., starting with the LSB of the byte.
* データ要素は、バイト内のビット数を増やす順にバイトに詰め込まれています。つまり、バイトのLSBから始まります。
* Data elements other than prefix codes are packed starting with the LSB of the data element. These are referred to here as integer values and are considered unsigned.
* プレフィックスコード以外のデータ要素は、データ要素のLSBから開始されます。これらはここで整数値と呼ばれ、符号なしと見なされます。
* Prefix codes are packed starting with the MSB of the code.
* プレフィックスコードは、コードのMSBから開始されます。
In other words, if one were to print out the compressed data as a sequence of bytes starting with the first byte at the *right* margin and proceeding to the *left*, with the MSB of each byte on the left as usual, one would be able to parse the result from right to left with fixed-width elements in the correct MSB-to-LSB order and prefix codes in bit-reversed order (i.e., with the first bit of the code in the relative LSB position).
言い換えれば、圧縮データを、 *右 *マージンの最初のバイトから始まり、 *左 *に進むと、通常どおり左側の各バイトのMSBが左から左に左から左から左から左から正しい幅の要素が正しいMSBからLSBの注文、FIRT-REVERSED ORDESの接頭辞コードの固定幅の要素で左から左から左の要素で左から左に左にある（I.）（I.）位置）。
As an example, consider packing the following data elements into a sequence of 3 bytes: 3-bit integer value 6, 4-bit integer value 2, 3-bit prefix code b'110, 2-bit prefix code b'10, and 12-bit integer value 3628.
例として、次のデータ要素を3バイトのシーケンスにパックすることを検討してください：3ビット整数値6、4ビット整数値2、3ビットプレフィックスコードB'110、2ビットプレフィックスコードB'10、および12ビット整数値3628。
byte 2 byte 1 byte 0
+--------+--------+--------+
|11100010|11000101|10010110|
+--------+--------+--------+
^ ^ ^ ^ ^
| | | | |
| | | | +------ integer value 6
| | | +---------- integer value 2
| | +-------------- prefix code 110
| +---------------- prefix code 10
+----------------------------- integer value 3628
Shared brotli extends brotli [RFC7932] with support for shared dictionaries, a larger LZ77 window, and a framing format.
共有Brotliは、共有辞書、より大きなLZ77ウィンドウ、およびフレーミング形式をサポートしてBrotli [RFC7932]を拡張します。
A shared dictionary is a piece of data shared by a compressor and decompressor. The compressor can take advantage of the dictionary context to encode the input in a more compact manner. The compressor and the decompressor must use exactly the same dictionary. A shared dictionary is specially useful to compress short input sequences.
共有辞書は、コンプレッサーと減圧器が共有するデータです。コンプレッサーは、辞書のコンテキストを利用して、よりコンパクトな方法で入力をエンコードできます。コンプレッサーと減圧器はまったく同じ辞書を使用する必要があります。共有辞書は、短い入力シーケンスを圧縮するのに特に便利です。
A shared brotli dictionary can use two methods of sharing context:
共有Brotli辞書では、2つの共有コンテキストの方法を使用できます。
LZ77 dictionary:
LZ77辞書：
The encoder and decoder could refer to a given sequence of bytes. Multiple LZ77 dictionaries can be set.
エンコーダーとデコーダーは、特定のバイトシーケンスを参照できます。複数のLZ77辞書を設定できます。
Custom static dictionary:
カスタム静的辞書：
A word list with transforms. The encoder and decoder will replace the static dictionary data with the data in the shared dictionary. The original static dictionary is described in Section 8 in [RFC7932]. The original data from Appendices A and B of [RFC7932] will be replaced. In addition, it is possible to dynamically switch this dictionary based on the data compression context and/or include a reference to the original dictionary in the custom dictionary.
変換のある単語リスト。エンコーダとデコーダーは、静的辞書データを共有辞書のデータに置き換えます。元の静的辞書は、[RFC7932]のセクション8で説明されています。[RFC7932]の付録AとBの元のデータが置き換えられます。さらに、データ圧縮コンテキストに基づいてこの辞書を動的に切り替えたり、カスタム辞書の元の辞書への参照を含めることができます。
If no shared dictionary is set, the decoder behaves the same as in [RFC7932] on a brotli stream.
共有辞書が設定されていない場合、デコーダーはBrotliストリームで[RFC7932]と同じように動作します。
If a shared dictionary is set, then it can set LZ77 dictionaries, override static dictionary words, and/or override transforms.
共有辞書が設定されている場合、LZ77辞書を設定したり、静的辞書ワードをオーバーライドしたり、変換をオーバーライドできます。
If a custom word list is set, then the following behaviors of the decoder defined in [RFC7932] are overridden:
カスタムワードリストが設定されている場合、[RFC7932]で定義されているデコーダーの次の動作がオーバーライドされます。
Instead of the Static Dictionary Data from Appendix A of [RFC7932], one or more word lists from the custom static dictionary data are used.
[RFC7932]の付録Aの静的辞書データの代わりに、カスタム静的辞書データの1つ以上の単語リストが使用されています。
Instead of NDBITS at the end of Appendix A of [RFC7932], a custom SIZE_BITS_BY_LENGTH per custom word list is used.
[RFC7932]の付録Aの最後にあるNDBITSの代わりに、カスタムワードリストごとにカスタムsize_bits_by_lengthが使用されます。
The copy length for a static dictionary reference must be between 4 and 31 and may not be a value for which SIZE_BITS_BY_LENGTH of this dictionary is 0.
静的辞書の参照のコピー長は4〜31でなければならず、この辞書のsize_bits_by_lengthが0の値ではない場合があります。
If a custom transforms list is set without context dependency, then the following behaviors of the decoder defined in [RFC7932] are overridden:
カスタム変換リストがコンテキスト依存関係なしに設定されている場合、[RFC7932]で定義されたデコーダーの次の動作がオーバーライドされます。
The "List of Word Transformations" from Appendix B of [RFC7932] is overridden by one or more lists of custom prefixes, suffixes, and transform operations.
[RFC7932]の付録Bからの「単語変換のリスト」は、カスタムプレフィックス、接尾辞、変換操作の1つ以上のリストによってオーバーライドされています。
The transform_id must be smaller than the number of transforms given in the custom transforms list.
Transform_idは、カスタム変換リストに記載されている変換の数よりも小さくなければなりません。
If the dictionary is context dependent, it includes a lookup table of 64 word list and transform list combinations. When resolving a static dictionary word, the decoder computes the literal Context ID as described in Section 7.1 of [RFC7932]. The literal Context ID is used as the index in the lookup tables to select the word list and transforms to use. If the dictionary is not context dependent, this ID is implicitly 0 instead.
辞書がコンテキストに依存している場合、64ワードリストと変換リストの組み合わせのルックアップテーブルが含まれています。静的辞書ワードを解決するとき、デコーダーは[RFC7932]のセクション7.1で説明されているように、リテラルコンテキストIDを計算します。リテラルコンテキストIDは、ルックアップテーブルのインデックスとして使用され、使用する単語リストと変換を選択します。辞書がコンテキストに依存しない場合、このIDは代わりに暗黙的に0です。
If a distance goes beyond the dictionary for the current ID and multiple word/transform list combinations are defined, then the next dictionary is used in the following order:
現在のIDの辞書を超えて距離を越え、複数の単語/変換リストの組み合わせが定義されている場合、次の辞書は次の順序で使用されます。
* If context dependent:
* コンテキスト依存の場合：
- use the index matching the current context first, and then
- 最初に現在のコンテキストに一致するインデックスを使用してから、次に
- use the same order as defined in the shared dictionary (excluding the current context) next.
- 共有辞書（現在のコンテキストを除く）で定義されているのと同じ順序を使用します。
* If not context dependent:
* コンテキストに依存していない場合：
- use the same order as defined in the shared dictionary.
- 共有辞書で定義されているのと同じ順序を使用します。
A shared dictionary may include custom word transformations to replace those specified in Section 8 and Appendix B of [RFC7932]. A transform consists of a possible prefix, a transform operation, a parameter (for some operations), and a possible suffix. In the shared dictionary format, the transform operation is represented by a numerical ID, which is listed in the table below.
共有辞書には、[RFC7932]のセクション8および付録Bで指定されたものを置き換えるカスタムワード変換が含まれる場合があります。変換は、可能なプレフィックス、変換操作、パラメーター（一部の操作の場合）、および可能な接尾辞で構成されます。共有辞書形式では、変換操作は数値IDで表され、以下の表にリストされています。
+====+===========================+
| ID | Operation |
+====+===========================+
| 0 | Identity |
+----+---------------------------+
| 1 | OmitLast1 |
+----+---------------------------+
| 2 | OmitLast2 |
+----+---------------------------+
| 3 | OmitLast3 |
+----+---------------------------+
| 4 | OmitLast4 |
+----+---------------------------+
| 5 | OmitLast5 |
+----+---------------------------+
| 6 | OmitLast6 |
+----+---------------------------+
| 7 | OmitLast7 |
+----+---------------------------+
| 8 | OmitLast8 |
+----+---------------------------+
| 9 | OmitLast9 |
+----+---------------------------+
| 10 | FermentFirst |
+----+---------------------------+
| 11 | FermentAll |
+----+---------------------------+
| 12 | OmitFirst1 |
+----+---------------------------+
| 13 | OmitFirst2 |
+----+---------------------------+
| 14 | OmitFirst3 |
+----+---------------------------+
| 15 | OmitFirst4 |
+----+---------------------------+
| 16 | OmitFirst5 |
+----+---------------------------+
| 17 | OmitFirst6 |
+----+---------------------------+
| 18 | OmitFirst7 |
+----+---------------------------+
| 19 | OmitFirst8 |
+----+---------------------------+
| 20 | OmitFirst9 |
+----+---------------------------+
| 21 | ShiftFirst (by PARAMETER) |
+----+---------------------------+
| 22 | ShiftAll (by PARAMETER) |
+----+---------------------------+
Table 1
Operations 0 to 20 are specified in Section 8 of [RFC7932]. ShiftFirst and ShiftAll transform specifically encoded SCALARs.
操作0〜20は、[RFC7932]のセクション8で指定されています。ShiftFirstおよびShiftall変換特異的にエンコードされたスカラー。
A SCALAR is a 7-, 11-, 16-, or 21-bit unsigned integer encoded with 1, 2, 3, or 4 bytes, respectively, with the following bit contents:
スカラーは、それぞれ1、2、3、または4バイトでエンコードされた7、11、16-、または21ビットの符号なし整数で、次のビット内容があります。
7-bit SCALAR:
+--------+
|0sssssss|
+--------+
11-bit SCALAR:
+--------+--------+
|110sssss|XXssssss|
+--------+--------+
16-bit SCALAR:
+--------+--------+--------+
|1110ssss|XXssssss|XXssssss|
+--------+--------+--------+
21-bit SCALAR:
+--------+--------+--------+--------+
|11110sss|XXssssss|XXssssss|XXssssss|
+--------+--------+--------+--------+
Given the input bytes matching the SCALAR encoding pattern, the SCALAR value is obtained by concatenation of the "s" bits, with the MSBs coming from the earliest byte. The "X" bits could have arbitrary value.
スカラーエンコードパターンに一致する入力バイトを考えると、スカラー値は「S」ビットの連結によって取得され、MSBは初期のバイトから来ます。「x」ビットには任意の価値があります。
An ADDEND is defined as the result of limited sign extension of a 16-bit unsigned PARAMETER:
加算値は、16ビットの署名されていないパラメーターの限られた符号拡張の結果として定義されます。
At first, the PARAMETER is zero-extended to 32 bits. After this, 0xFF0000 is added if the resulting value is greater or equal than 0x8000.
最初は、パラメーターは32ビットにゼロ拡張されています。この後、結果の値が0x8000以下の場合、0xFF0000が追加されます。
ShiftAll starts at the beginning of the word and repetitively applies the following transformation until the whole word is transformed:
Shiftallは単語の先頭から始まり、単語全体が変換されるまで次の変換を繰り返し適用します。
If the next untransformed byte matches the first byte of the 7-, 11-, 16-, or 21-bit SCALAR pattern, then:
次の変換されていないバイトが7、11、16、または21ビットのスカラーパターンの最初のバイトと一致する場合、次のとおりです。
If the untransformed part of the word is not long enough to match the whole SCALAR pattern, then the whole word is marked as transformed.
単語の変換されていない部分がスカラーパターン全体に一致するほど長くない場合、単語全体が変換されているとマークされます。
Otherwise, let SHIFTED be the sum of the ADDEND and the encoded SCALAR. The lowest bits from SHIFTED are written back into the corresponding "s" bits. The "0", "1", and "X" bits remain unchanged. Next, 1, 2, 3, or 4 untransformed bytes are marked as transformed according to the SCALAR pattern length.
それ以外の場合は、シフトして、エンコードされたスカラーの合計とします。シフトされた最低ビットは、対応する「s」ビットに書き戻されます。「0」、「1」、および「X」ビットは変わらないままです。次に、1、2、3、または4つの変換されていないバイトは、スカラーパターンの長さに応じて変換されているとマークされます。
Otherwise, the next untransformed byte is marked as transformed.
それ以外の場合、次の変換されていないバイトが変換されているとマークされています。
ShiftFirst applies the same transformation as ShiftAll, but does not iterate.
ShiftFirstはShiftallと同じ変換を適用しますが、反復しません。
If an LZ77 dictionary is set, the decoder treats it as a regular LZ77 copy but behaves as if the bytes of this dictionary are accessible as the uncompressed bytes outside of the regular LZ77 window for backwards references.
LZ77辞書が設定されている場合、デコーダーはそれを通常のLZ77コピーとして扱いますが、この辞書のバイトには、逆方向の参照のために通常のLZ77ウィンドウの外側の非圧縮バイトとしてアクセス可能であるかのように動作します。
Let LZ77_DICTIONARY_LENGTH be the length of the LZ77 dictionary. Then word_id, described in Section 8 of [RFC7932], is redefined as:
LZ77_Dictionary_lengthをLZ77辞書の長さとします。次に、[RFC7932]のセクション8で説明されているWord_idは、次のように再定義されます。
word_id = distance - (max allowed distance + 1 +
LZ77_DICTIONARY_LENGTH)
For the case when LZ77_DICTIONARY_LENGTH is 0, word_id matches the [RFC7932] definition.
LZ77_Dictionary_Lengthが0の場合、Word_IDは[RFC7932]定義と一致します。
Let dictionary_address be:
dictionary_addressとしましょう。
LZ77_DICTIONARY_LENGTH + max allowed distance - distance
lz77_dictionary_length + max許容距離 - 距離
Then distance values of <length, distance> pairs [RFC7932] in range (max allowed distance + 1)..(LZ77_DICTIONARY_LENGTH + max allowed distance) are interpreted as references starting in the LZ77 dictionary at the byte at dictionary_address. If length is longer than (LZ77_DICTIONARY_LENGTH - dictionary_address), then the reference continues to copy (length - LZ77_DICTIONARY_LENGTH + dictionary_address) bytes from the regular LZ77 window starting at the beginning.
次に、範囲の<長さ、距離>ペア[RFC7932]の距離値（最大許容距離 + 1）..（LZ77_Dictionary_Length + Max許容距離）は、dictionary_addressのBYTEのLZ77辞書から始まる参照として解釈されます。長さが（lz77_dictionary_length -dictionary_address）より長い場合、参照は、最初から始まる通常のLZ77ウィンドウからのバイト（長さ-LZ77_Dictionary_Length + Dictionary_Address）をコピーし続けます。
A varint is encoded in base 128 in one or more bytes as follows:
VARINTは、次のように、1つ以上のバイトでベース128にエンコードされています。
+--------+--------+ +--------+
|1xxxxxxx|1xxxxxxx| {0-8 times} |0xxxxxxx|
+--------+--------+ +--------+
where the "x" bits of the first byte are the LSBs of the value and the "x" bits of the last byte are the MSBs of the value. The last byte must have its MSB set to 0 and all other bytes must have their MSBs set to 1 to indicate there is a next byte.
最初のバイトの「x」ビットが値のLSBであり、最後のバイトの「x」ビットは値のMSBです。最後のバイトにはMSBが0に設定されている必要があり、他のすべてのバイトが次のバイトがあることを示すためにMSBを1に設定する必要があります。
The maximum allowed amount of bits to read is 63 bits; if the 9th byte is present and has its MSB set, then the stream must be considered as invalid.
読み取るビットの最大量は63ビットです。9番目のバイトが存在し、MSBセットがある場合、ストリームは無効と見なされる必要があります。
The shared dictionary stream encodes a custom dictionary for brotli, including custom words and/or custom transformations. A shared dictionary may appear as a standalone or as contents of a resource in a framing format container.
共有辞書ストリームは、カスタムワードやカスタム変換を含むBrotliのカスタム辞書をエンコードします。共有辞書は、スタンドアロンとして、またはフレーミング形式のコンテナでリソースの内容として表示される場合があります。
A compliant shared brotli dictionary stream must have the following format:
準拠した共有Brotli辞書ストリームには、次の形式が必要です。
2 bytes:
2バイト：
File signature in hexadecimal format (bytes 91 and 0).
16進形式のファイル署名（バイト91および0）。
varint:
VARINT：
LZ77_DICTIONARY_LENGTH. The number of bytes for an LZ77 dictionary, or 0 if there is none. The maximum allowed value is the maximum possible sliding window size of brotli or large window brotli.
lz77_dictionary_length。LZ77辞書のバイト数、またはない場合は0。許可された最大値は、Brotliまたは大きなウィンドウBrotliの最大スライディングウィンドウサイズです。
LZ77_DICTIONARY_LENGTH bytes:
lz77_dictionary_lengthバイト：
Contents of the LZ77 dictionary.
LZ77辞書の内容。
1 byte:
1バイト：
NUM_CUSTOM_WORD_LISTS. May have a value in range 0 to 64.
num_custom_word_lists。範囲0〜64の値がある場合があります。
NUM_CUSTOM_WORD_LISTS times a word list with the following format for each word list:
num_custom_word_lists各単語リストの次の形式で単語リストを締めます。
28 bytes:
28バイト：
SIZE_BITS_BY_LENGTH. An array of 28 unsigned 8-bit integers, indexed by word lengths 4 to 31. The value represents log2(number of words of this length), with the exception of 0 meaning 0 words of this length. The max allowed length value is 15 bits. OFFSETS_BY_LENGTH is computed from this as OFFSETS_BY_LENGTH[i + 1] = OFFSETS_BY_LENGTH[i] + (SIZE_BITS_BY_LENGTH[i] ? (i << SIZE_BITS_BY_LENGTH[i]) : 0).
size_bits_by_length。単語の長さ4〜31でインデックス化された28の署名されていない8ビット整数の配列。値は、この長さの0を意味する0を除き、log2（この長さの単語数）を表します。最大許容長さの値は15ビットです。offsets_by_lengthは、これからOffsets_by_length [i + 1] = offsets_by_length [i] +（size_bits_by_length [i]？（i << size_bits_by_length [i]）：0）として計算されます。
N bytes:
nバイト：
Words dictionary data, where N is OFFSETS_BY_LENGTH[31] + (SIZE_BITS_BY_LENGTH[31] ? (31 << SIZE_BITS_BY_LENGTH[31]) : 0), with all the words of shortest length first, then all words of the next length, and so on, where there are either 0 or a positive power of two number of words for each length.
単語辞書データ、nはoffsets_by_length [31] +（size_bits_by_length [31]？（31 << size_bits_by_length [31]）：0）、最初に最短の単語で、次に次の長さのすべての単語など、各長さの2つの単語の肯定的なパワーがあります。
1 byte:
1バイト：
NUM_CUSTOM_TRANSFORM_LISTS. May have a value in range 0 to 64.
num_custom_transform_lists。範囲0〜64の値がある場合があります。
NUM_CUSTOM_TRANSFORM_LISTS times a transform list with the following format for each transform list:
num_custom_transform_lists各変換リストの次の形式で変換リストをタイムします。
2 bytes:
2バイト：
PREFIX_SUFFIX_LENGTH. The length of prefix/suffix data. Must be at least 1 because the list must always end with a zero-length stringlet even if it is empty.
prefix_suffix_length。プレフィックス/サフィックスデータの長さ。リストは、たとえ空であっても、常にゼロ長さのストリングレットで常に終了する必要があるため、少なくとも1でなければなりません。
NUM_PREFIX_SUFFIX times:
num_prefix_suffixタイム：
Prefix/suffix stringlet. NUM_PREFIX_SUFFIX is the number of stringlets parsed and must be in range 1..256.
プレフィックス/接尾辞Stringlet。num_prefix_suffixは解析された弦楽器の数であり、範囲1..256でなければなりません。
1 byte:
1バイト：
STRING_LENGTH. The length of the entry contents. 0 for the last (terminating) entry of the transform list. For other entries, STRING_LENGTH must be in range 1..255. The 0 entry must be present and must be the last byte of the PREFIX_SUFFIX_LENGTH bytes of prefix/suffix data, else the stream must be rejected as invalid.
string_length。エントリコンテンツの長さ。変換リストの最後（終了）エントリの0。他のエントリの場合、string_lengthは範囲1..255でなければなりません。0のエントリが存在する必要があり、プレフィックス/サフィックスデータのプレフィックス_Suffix_Lengthバイトの最後のバイトでなければなりません。そうしないと、ストリームは無効として拒否される必要があります。
STRING_LENGTH bytes:
string_lengthバイト：
Contents of the prefix/suffix.
接頭辞/接尾辞の内容。
1 byte:
1バイト：
NTRANSFORMS. Number of transformation triplets.
ntransforms。変換トリプレットの数。
NTRANSFORMS times the data for each transform listed below:
NTRANSFORMS以下にリストされている各変換のデータの時間：
1 byte:
1バイト：
Index of prefix in prefix/suffix data; must be less than NUM_PREFIX_SUFFIX.
プレフィックス/サフィックスデータのプレフィックスのインデックス。num_prefix_suffixよりも少ない必要があります。
1 byte:
1バイト：
Index of suffix in prefix/suffix data; must be less than NUM_PREFIX_SUFFIX.
接頭辞/サフィックスデータの接尾辞のインデックス。num_prefix_suffixよりも少ない必要があります。
1 byte:
1バイト：
Operation index; must be an index in the table of operations listed in Section 3.1.1.
操作インデックス;セクション3.1.1にリストされている運用表のインデックスである必要があります。
If and only if at least one transform has operation index ShiftFirst or ShiftAll, then NTRANSFORMS times the following:
少なくとも1つの変換に操作インデックスシフトファーストまたはシフトがある場合にのみ、ntransformsは次の倍になります。
2 bytes:
2バイト：
Parameters for the transform. If the transform does not have type ShiftFirst or ShiftAll, the value must be 0. ShiftFirst and ShiftAll interpret these bytes as an unsigned 16-bit integer.
変換のパラメーター。変換にタイプShiftFirstまたはShiftallがない場合、値は0でなければなりません。
If NUM_CUSTOM_WORD_LISTS > 0 or NUM_CUSTOM_TRANSFORM_LISTS > 0 (else implicitly NUM_DICTIONARIES is 1 and points to the brotli built-in and there is no context map):
num_custom_word_lists> 0またはnum_custom_transform_lists> 0（elws num_dictionariesは1で、Brotli内蔵のポイントがあり、コンテキストマップはありません）：
1 byte:
1バイト：
NUM_DICTIONARIES. May have a value in range 1 to 64. Each dictionary is a combination of a word list and a transform list. Each next dictionary is used when the distance goes beyond the previous. If a CONTEXT_MAP is enabled, then the dictionary matching the context is moved to the front in the order for this context.
num_dictionaries。範囲1〜64の値がある場合があります。各辞書は、単語リストと変換リストの組み合わせです。距離が前の距離を超えると、次の各辞書が使用されます。Context_Mapが有効になっている場合、コンテキストに一致する辞書は、このコンテキストの順序で前面に移動します。
NUM_DICTIONARIES times the DICTIONARY_MAP, which contains:
num_dictionarisは、dictionary_mapをタイムタイムします。
1 byte:
1バイト：
Index into a custom word list or value NUM_CUSTOM_WORD_LISTS to indicate using the brotli [RFC7932] built-in default word list.
カスタムワードリストまたは値num_custom_word_listsにインデックスを付けて、Brotli [rfc7932]内蔵デフォルトワードリストを使用して示す。
1 byte:
1バイト：
Index into a custom transform list or value NUM_CUSTOM_TRANSFORM_LISTS to indicate using the brotli [RFC7932] built-in default transform list.
カスタム変換リストまたは値Num_custom_transform_listsにインデックスを付けて、Brotli [rfc7932]ビルトインデフォルト変換リストを使用して示す。
1 byte:
1バイト：
CONTEXT_ENABLED. If 0, there is no context map. If 1, a context map used to select the dictionary is encoded as below.
context_enabled。0の場合、コンテキストマップはありません。1の場合、辞書の選択に使用されるコンテキストマップは、以下のようにエンコードされます。
If CONTEXT_ENABLED is 1, there is a context map for the 64 brotli [RFC7932] literals contexts:
Context_Enabledが1の場合、64 Brotli [RFC7932]リテラルコンテキストのコンテキストマップがあります。
64 bytes:
64バイト：
CONTEXT_MAP. Index into the DICTIONARY_MAP for the first dictionary to use for this context.
context_map。このコンテキストに使用する最初の辞書のdictionary_mapへのインデックス。
Large window brotli allows a sliding window beyond the 24-bit maximum of regular brotli [RFC7932].
大きなウィンドウBrotliは、通常のBrotli [RFC7932]の24ビットの最大値を超えるスライドウィンドウを可能にします。
The compressed data stream is backwards compatible to brotli [RFC7932] and may optionally have the following differences:
圧縮データストリームは、Brotli [RFC7932]に逆方向に互換性があり、オプションで次の違いがある場合があります。
In the encoding of WBITS in the stream header, the following new pattern of 14 bits is supported:
ストリームヘッダー内のWbitsのエンコードでは、14ビットの次の新しいパターンがサポートされています。
8 bits:
8ビット：
Value 00010001 to indicate a large window brotli stream.
Value 00010001大きなウィンドウBrotliストリームを示す。
6 bits:
6ビット：
WBITS. Must have value in range 10 to 62.
wbits。10〜62の範囲の値が必要です。
Distance alphabet:
距離アルファベット：
If the stream is a large window brotli stream, the maximum number of extra bits is 62 and the theoretical maximum size of the distance alphabet is (16 + NDIRECT + (124 << NPOSTFIX)). This overrides the value for the distance alphabet size given in Section 3.3 of [RFC7932] and affects the number of bits in the encoding of the Simple Prefix Code for distances as described in Section 3.4 of [RFC7932]. An additional limitation to distances, despite the large allowed alphabet size, is that the alphabet is not allowed to contain a distance symbol able to represent a distance larger than ((1 << 63) - 4) when its extra bits have their maximum value. It depends on NPOSTFIX and NDIRECT when this can occur.
ストリームが大きなウィンドウBrotliストリームの場合、追加ビットの最大数は62で、距離アルファベットの理論的最大サイズは（16 + ndirect +（124 << npostfix））です。これは、[RFC7932]のセクション3.3に記載されている距離アルファベットサイズの値をオーバーライドし、[RFC7932]のセクション3.4で説明されているように、距離の単純なプレフィックスコードのエンコードのビット数に影響します。距離への追加の制限は、大きな許可されたアルファベットサイズにもかかわらず、アルファベットに、追加ビットが最大値を持っている場合（（1 << 63）-4）よりも大きい距離を表すことができる距離記号を含めることが許可されていないことです。これが発生する可能性がある場合、npostfixとndirectに依存します。
A decoder that does not support 64-bit integers may reject a stream if WBITS is higher than 30 or a distance symbol from the distance alphabet is able to encode a distance larger than 2147483644.
64ビットの整数をサポートしないデコーダーは、WBITが30を超える場合、または距離アルファベットからの距離記号が2147483644を超える距離をエンコードできる場合、ストリームを拒否する場合があります。
The format of a shared brotli compressed data stream without a framing format is backwards compatible with brotli [RFC7932] with the following optional differences:
フレーミング形式のない共有Brotli圧縮データストリームの形式は、次のオプションの違いを伴うBrotli [RFC7932]と逆方向に互換性があります。
* LZ77 dictionaries as described above are supported.
* 上記のLZ77辞書がサポートされています。
* Custom static dictionaries replacing or extending the static dictionary of brotli [RFC7932] with different words or transforms are supported.
* Brotli [RFC7932]の静的辞書を異なる単語または変換に置き換えるまたは拡張するカスタム静的辞書がサポートされています。
* The stream may have the format of regular brotli [RFC7932] or the format of large window brotli as described in Section 6.
* ストリームには、セクション6で説明されているように、通常のBrotli [RFC7932]の形式または大きなウィンドウBrotliの形式があります。
A compliant shared brotli framing format stream has the format described below.
準拠した共有Brotliフレーミング形式のストリームには、以下で説明されている形式があります。
4 bytes:
4バイト：
File signature in hexadecimal format (bytes 0x91, 0x0a, 0x42, and 0x52). The first byte contains the invalid WBITS combination for brotli [RFC7932] and large window brotli.
16進形式のファイル署名（バイト0x91、0x0a、0x42、および0x52）。最初のバイトには、Brotli [RFC7932]と大きなウィンドウBrotliの無効なWbitsの組み合わせが含まれています。
1 byte:
1バイト：
Container flags that are 8 bits and have the following meanings:
8ビットで、次の意味を持つコンテナフラグ：
bits 0 and 1:
ビット0および1：
Version indicator that must be b'00. Otherwise, the decoder must reject the data stream as invalid.
B'00でなければならないバージョンインジケーター。それ以外の場合、デコーダーはデータストリームを無効として拒否する必要があります。
bit 2:
ビット2：
If 0, the file contains no final footer, may not contain any metadata chunks, may not contain a central directory, and may encode only a single resource (using one or more data chunks). If 1, the file may contain one or more resources, metadata, and a central directory, and it must contain a final footer.
0の場合、ファイルに最終フッターが含まれていない場合、メタデータのチャンクが含まれておらず、中央のディレクトリを含まない場合があり、単一のリソースのみをエンコードする場合があります（1つ以上のデータチャンクを使用）。1の場合、ファイルには1つ以上のリソース、メタデータ、および中央ディレクトリが含まれている場合があり、最終的なフッターを含める必要があります。
multiple times:
複数回：
A chunk, each with the format specified in Section 8.2.
セクション8.2で指定された形式を備えたチャンク。
varint:
VARINT：
Length of this chunk excluding this varint but including all next header bytes and data. If the value is 0, then the chunk type byte is not present and the chunk type is assumed to be 0.
このチャンクの長さは、このvarintを除外しますが、すべての次のヘッダーバイトとデータを含みます。値が0の場合、チャンクタイプのバイトは存在せず、チャンクタイプは0と想定されます。
1 byte:
1バイト：
CHUNK_TYPE
chunk_type
0:
0：
padding chunk
パディングチャンク
1:
1：
metadata chunk
メタデータチャンク
2:
2：
data chunk
データチャンク
3:
3：
first partial data chunk
最初の部分データチャンク
4:
4：
middle partial data chunk
中央の部分データチャンク
5:
5：
last partial data chunk
最後の部分データチャンク
6:
6：
footer metadata chunk
フッターメタデータチャンク
7:
7：
global metadata chunk
グローバルメタデータチャンク
8:
8：
repeat metadata chunk
メタデータチャンクを繰り返します
9:
9：
central directory chunk
中央ディレクトリチャンク
10:
10：
final footer
最終フッター
If CHUNK_TYPE is not padding chunk, central directory, or final footer:
chunk_typeがチャンク、中央ディレクトリ、または最終フッターをパディングしていない場合：
1 byte:
1バイト：
CODEC:
コーデック：
0:
0：
uncompressed
圧迫されていません
1:
1：
keep decoder
デコーダーを保持します
2:
2：
brotli
brotli
3:
3：
shared brotli
共有Brotli
If CODEC is not "uncompressed":
コーデックが「圧縮されていない」場合：
varint:
VARINT：
Uncompressed size in bytes of the data contained within the compressed stream.
圧縮ストリーム内に含まれるデータのバイトの非圧縮サイズ。
If CODEC is "shared brotli":
コーデックが「共有Brotli」の場合：
1 byte:
1バイト：
Number of dictionary references. Multiple dictionary references are possible with the following restrictions: there can be 1 serialized dictionary and 15 prefix dictionaries maximum (a serialized dictionary may already contain one of those). Circular references are not allowed (any dictionary reference that directly or indirectly uses this chunk itself as dictionary).
辞書参照の数。次の制限で複数の辞書参照が可能です。シリアル化された辞書と15のプレフィックス辞書の最大値があります（シリアル化された辞書にはすでにそれらのいずれかが含まれている場合があります）。循環参照は許可されていません（このチャンク自体を辞書として直接的または間接的に使用する辞書参照）。
Per dictionary reference:
辞書ごとのリファレンス：
1 byte:
1バイト：
Flags:
フラグ：
bits 0 and 1:
ビット0および1：
Dictionary source:
辞書ソース：
00:
00：
Internal dictionary reference to a full resource by pointer, which can span one or more chunks. Must point to a full data chunk or a first partial data chunk.
ポインターによる完全なリソースへの内部辞書の参照。1つ以上のチャンクにまたがる可能性があります。完全なデータチャンクまたは最初の部分データチャンクを指す必要があります。
01:
01：
Internal dictionary reference to single chunk contents by pointer. May point to any chunk with content (data or metadata). If a partial data chunk, only this part is the dictionary. In this case, the dictionary type is not allowed to be a serialized dictionary.
ポインターによる単一チャンクコンテンツへの内部辞書参照。コンテンツ（データまたはメタデータ）のあるチャンクを指すことがあります。部分的なデータチャンクの場合、この部分のみが辞書です。この場合、辞書タイプはシリアル化された辞書になることは許可されていません。
10:
10：
Reference to a dictionary by hash code of a resource. The dictionary can come from an external source, such as a different container. The user of the decoder must be able to provide the dictionary contents given its hash code (even if it comes from this container itself) or treat it as an error when the user does not have it available.
リソースのハッシュコードによる辞書への参照。辞書は、異なる容器などの外部ソースから届くことができます。デコーダーのユーザーは、ハッシュコードを考慮して（このコンテナ自体から来た場合でも）辞書の内容を提供したり、ユーザーが利用できない場合はエラーとして扱うことができる必要があります。
11:
11：
Invalid bit combination
無効なビットの組み合わせ
bits 2 and 3:
ビット2および3：
Dictionary type:
辞書タイプ：
00:
00：
Prefix dictionary, set in front of the sliding window
スライドウィンドウの前に設定されたプレフィックス辞書
01:
01：
Serialized dictionary in the shared brotli format as specified in Section 5.
セクション5で指定されている共有Brotli形式のシリアル化辞書。
10:
10：
Invalid bit combination
無効なビットの組み合わせ
11:
11：
Invalid bit combination
無効なビットの組み合わせ
bits 4-7:
ビット4-7：
Must be 0
0でなければなりません
If hash-based:
ハッシュベースの場合：
1 byte:
1バイト：
Type of hash used. Only supported value: 3, indicating 256-bit HighwayHash [HWYHASH].
使用するハッシュのタイプ。サポートされている値のみ：3、256ビットの高速ハッシュ[Hwyhash]を示しています。
32 bytes:
32バイト：
256-bit HighwayHash checksum to refer to dictionary.
辞書を参照するための256ビット高速ハッシュチェックサム。
If pointer based:
ポインターベースの場合：
Varint-encoded pointer to its chunk in this container. The chunk must come in the container earlier than the current chunk.
この容器内のチャンクへのvarintエンコードポインター。チャンクは、現在のチャンクよりも早くコンテナに入っている必要があります。
X bytes:
Xバイト：
Extra header bytes, depending on CHUNK_TYPE. If present, they are specified in the subsequent sections.
chunk_typeに応じて、追加のヘッダーバイト。存在する場合、それらは後続のセクションで指定されています。
remaining bytes:
残りのバイト：
The chunk contents. The uncompressed data in the chunk content depends on CHUNK_TYPE and is specified in the subsequent sections. The compressed data has following format depending on CODEC:
チャンクの内容。Chunkコンテンツの非圧縮データはChunk_Typeに依存し、後続のセクションで指定されています。圧縮データには、コーデックに応じて次の形式があります。
* uncompressed: The raw bytes.
* 非圧縮：生のバイト。
* If "keep decoder", the continuation of the compressed stream that was interrupted at the end of the previous chunk. The decoder from the previous chunk must be used and its state it had at the end of the previous chunk must be kept at the start of the decoding of this chunk.
* 「キープデコーダー」の場合、前のチャンクの終わりに中断された圧縮ストリームの継続。前のチャンクからのデコーダーを使用する必要があり、前のチャンクの最後に持っていた状態は、このチャンクのデコードの開始時に保持する必要があります。
* brotli: The bytes are in brotli format [RFC7932].
* Brotli：バイトはBrotli形式[RFC7932]です。
* shared brotli: The bytes are in the shared brotli format specified in Section 7.
* 共有Brotli：バイトは、セクション7で指定された共有Brotli形式にあります。
All the metadata chunk types use the following format for the uncompressed content:
すべてのメタデータチャンクタイプは、非圧縮コンテンツに次の形式を使用します。
Per field:
フィールドごと：
2 bytes:
2バイト：
Code to identify this metadata field. This must be two lowercase or two uppercase alpha ASCII characters. If the decoder encounters a lowercase field that it does not recognize for the current chunk type, non-ASCII characters, or non-alpha characters, the decoder must reject the data stream as invalid. Uppercase codes may be used for custom user metadata and can be ignored by a compliant decoder.
このメタデータフィールドを識別するコード。これは、2つの小文字または2つの大文字のアルファASCII文字でなければなりません。デコーダーが現在のチャンクタイプ、非ASCII文字、または非アルファ文字について認識していない小文字フィールドに遭遇する場合、デコーダーはデータストリームを無効として拒否する必要があります。大文字コードはカスタムユーザーメタデータに使用でき、準拠したデコーダーでは無視できます。
varint:
VARINT：
Length of the content of this field in bytes, excluding the code bytes and this varint.
このフィールドのコンテンツの長さは、コードバイトとこのvarintを除外します。
N bytes:
nバイト：
The contents of this field.
このフィールドの内容。
The last field is reached when the chunk content end is reached. If the length of the last field does not end at the same byte as the end of the uncompressed content of the chunk, the decoder must reject the data stream as invalid.
チャンクコンテンツエンドに到達すると、最後のフィールドに到達します。最後のフィールドの長さが、チャンクの非圧縮コンテンツの終了と同じバイトで終了しない場合、デコーダーはデータストリームを無効として拒否する必要があります。
All bytes in this chunk must be zero except for the initial varint that specifies the remaining chunk length.
このチャンクのすべてのバイトは、残りのチャンク長を指定する初期のVarintを除き、ゼロでなければなりません。
Since the varint itself takes up bytes as well, when the goal is to introduce a number of padding bytes, the dependence of the length of the varint on the value it encodes must be taken into account.
Varint自体もバイトを占有するため、目標が多数のパディングバイトを導入することである場合、Varintの長さのエンコードの長さの依存性を考慮する必要があります。
A single byte varint with a value of 0 is a padding chunk of length 1. For more padding, use higher varint values. Do not use multiple shorter padding chunks since this is slower to decode.
値が0の単一バイトVarintは、長さ1のパディングチャンクです。パディングを増やすには、より高いVarint値を使用します。これはデコードが遅いため、複数の短いパディングチャンクを使用しないでください。
This chunk contains metadata that applies to the resource whose beginning is encoded in the subsequent data chunk or first partial data chunk.
このチャンクには、後続のデータチャンクまたは最初の部分データチャンクで開始がエンコードされているリソースに適用されるメタデータが含まれています。
The contents of this chunk follows the format described in Section 8.3.
このチャンクの内容は、セクション8.3で説明されている形式に従います。
The following field types are recognized:
次のフィールドタイプが認識されています。
id (N bytes):
id（nバイト）：
Name field. May appear 0 or 1 times. Has the following format: name in UTF-8 encoding, length determined by the field length. Treated generically but may be used as a filename. If used as a filename, forward slashes '/' should be used as directory separators, relative paths should be used, and filenames ending in a slash with 0-length content in the matching data chunk should be treated as an empty directory.
名前フィールド。0または1回表示される場合があります。次の形式があります：UTF-8エンコーディングの名前、フィールドの長さによって決定されます。一般的に扱われますが、ファイル名として使用できます。ファイル名として使用される場合、フォワードスラッシュ '/'をディレクトリセパレーターとして使用する必要があり、相対パスを使用する必要があり、一致するデータチャンクの0レングスコンテンツを含むスラッシュで終了するファイル名は、空のディレクトリとして扱う必要があります。
mt (8 bytes):
MT（8バイト）：
Modification type. May appear 0 or 1 times. Has the following format: contains microseconds since epoch, as a little-endian, signed two's complement 64-bit integer.
変更タイプ。0または1回表示される場合があります。次の形式があります。エポックは、小さなエンディアンとして、2つの補完64ビット整数に署名したため、マイクロ秒を含みます。
custom user field:
カスタムユーザーフィールド：
Any two uppercase ASCII characters.
2つの大文字のASCII文字。
A data chunk contains the actual data of a resource.
データチャンクには、リソースの実際のデータが含まれています。
This chunk has the following extra header bytes:
このチャンクには、次の追加のヘッダーバイトがあります。
1 byte:
1バイト：
Flags:
フラグ：
bit 0:
ビット0：
If true, indicates this is not a resource that should be output implicitly as part of extracting resources from this container. Instead, it may be referred to only explicitly, e.g., as a dictionary reference by hash code or offset. This flag should be set for data used as dictionary to improve compression of actual resources.
真実の場合、これがこのコンテナからリソースを抽出する一部として暗黙的に出力する必要があるリソースではないことを示します。代わりに、ハッシュコードまたはオフセットによる辞書の参照として、たとえば明示的にのみ参照される場合があります。このフラグは、実際のリソースの圧縮を改善するために辞書として使用されるデータに設定する必要があります。
bit 1:
ビット1：
If true, hash code is given.
Trueの場合、ハッシュコードが指定されます。
bits 2-7:
ビット2-7：
Must be zero.
ゼロでなければなりません。
If hash code is given:
ハッシュコードが指定されている場合：
1 byte:
1バイト：
Type of hash used. Only supported value: 3, indicating 256-bit HighwayHash [HWYHASH].
使用するハッシュのタイプ。サポートされている値のみ：3、256ビットの高速ハッシュ[Hwyhash]を示しています。
32 bytes:
32バイト：
256-bit HighwayHash checksum of the uncompressed data.
非圧縮データの256ビットHighwayhashチェックサム。
The uncompressed content bytes of this chunk are the actual data of the resource.
このチャンクの非圧縮コンテンツバイトは、リソースの実際のデータです。
This chunk contains partial data of a resource. This is the first chunk in a series containing the entire data of the resource.
このチャンクには、リソースの部分的なデータが含まれています。これは、リソースのデータ全体を含むシリーズの最初のチャンクです。
The format of this chunk is the same as the format of a data chunk (Section 8.4.3) except for the differences noted below.
このチャンクの形式は、以下の違いを除き、データチャンク（セクション8.4.3）の形式と同じです。
The second bit of flags must be set to 0 and no hash code given.
フラグの2番目のビットは0に設定し、ハッシュコードが与えられない必要があります。
The uncompressed data size is only of this part of the resource, not of the full resource.
圧縮されていないデータサイズは、リソースのこの部分のみであり、完全なリソースではありません。
This chunk contains partial data of a resource and is neither the first nor the last part of the full resource.
このチャンクには、リソースの部分的なデータが含まれており、完全なリソースの最初でも最後の部分でもありません。
The format of this chunk is the same as the format of a data chunk (Section 8.4.3) except for the differences noted below.
このチャンクの形式は、以下の違いを除き、データチャンク（セクション8.4.3）の形式と同じです。
The first and second bits of flags must be set to 0.
フラグの最初と2番目のビットは0に設定する必要があります。
The uncompressed data size is only of this part of the resource, not of the full resource.
圧縮されていないデータサイズは、リソースのこの部分のみであり、完全なリソースではありません。
This chunk contains the final piece of partial data of a resource.
このチャンクには、リソースの部分的なデータの最後の部分が含まれています。
The format of this chunk is the same as the format of a data chunk (Section 8.4.3) except for the differences noted below.
このチャンクの形式は、以下の違いを除き、データチャンク（セクション8.4.3）の形式と同じです。
The first bit of flags must be set to 0.
フラグの最初のビットは0に設定する必要があります。
If a hash code is given, the hash code of the full resource (concatenated from all previous chunks and this chunk) is given in this chunk.
ハッシュコードが指定されている場合、完全なリソースのハッシュコード（以前のすべてのチャンクとこのチャンクから連結）がこのチャンクに与えられます。
The uncompressed data size is only of this part of the resource, not of the full resource.
圧縮されていないデータサイズは、リソースのこの部分のみであり、完全なリソースではありません。
The type of this chunk indicates that there are no further chunk encoding this resource, so the full resource is now known.
このチャンクのタイプは、このリソースをエンコードするチャンクがそれ以上ないことを示しているため、完全なリソースが現在既知になっています。
This metadata applies to the resource whose encoding ended in the preceding data chunk or last partial data chunk.
このメタデータは、エンコードが前のデータチャンクまたは最後の部分データチャンクで終了したリソースに適用されます。
The contents of this chunk follows the format described in Section 8.3.
このチャンクの内容は、セクション8.3で説明されている形式に従います。
There are no lowercase field types defined for footer metadata. Uppercase field types can be used as custom user data.
フッターメタデータ用に定義された小文字のフィールドタイプはありません。大文字のフィールドタイプは、カスタムユーザーデータとして使用できます。
This metadata applies to the whole container instead of a single resource.
このメタデータは、単一のリソースではなく、コンテナ全体に適用されます。
The contents of this chunk follows the format described in Section 8.3.
このチャンクの内容は、セクション8.3で説明されている形式に従います。
There are no lowercase field types defined for global metadata. Uppercase field types can be used as custom user data.
グローバルメタデータ用に定義された小文字のフィールドタイプはありません。大文字のフィールドタイプは、カスタムユーザーデータとして使用できます。
These chunks optionally repeat metadata that is interleaved between data chunks. To use these chunks, it is necessary to also read additional information, such as pointers to the original chunks, from the central directory.
これらのチャンクは、オプションで、データチャンク間でインターリーブされるメタデータを繰り返します。これらのチャンクを使用するには、中央ディレクトリから元のチャンクのポインターなどの追加情報も読む必要があります。
The contents of this chunk follows the format described in Section 8.3.
このチャンクの内容は、セクション8.3で説明されている形式に従います。
This chunk has an extra header byte:
このチャンクには追加のヘッダーバイトがあります。
1 byte:
1バイト：
Chunk type of repeated chunk (metadata chunk or footer metadata chunk).
チャンクタイプの繰り返しチャンク（メタデータチャンクまたはフッターメタデータチャンク）。
This set of chunks must follow the following restrictions:
この一連のチャンクは、次の制限に従う必要があります。
* It is optional whether or not repeat metadata chunks are present.
* 繰り返しメタデータチャンクが存在するかどうかはオプションです。
* If they are present, then they must be present for all metadata chunks and footer metadata chunks.
* それらが存在する場合、それらはすべてのメタデータチャンクとフッターメタデータチャンクに存在する必要があります。
* There may be only 1 repeat metadata chunk per repeated metadata chunk.
* 繰り返されるメタデータチャンクごとに、メタデータチャンクが1つしかない場合があります。
* They must appear in the same order as the chunks appear in the container, which is also the same order as listed in the central directory.
* チャンクがコンテナに表示されるのと同じ順序で表示される必要があります。これは、中央ディレクトリにリストされているのと同じ順序でもあります。
* Compression of these chunks is allowed; however, it is not allowed to use any internal dictionary except an earlier repeat metadata chunk of this series, and it is not allowed for a metadata chunk to keep the decoder state if the previous chunk is not a repeat metadata chunk. That is, the series of metadata chunks must be decompressible without using other chunks of the framing format file.
* これらのチャンクの圧縮は許可されています。ただし、このシリーズの以前の繰り返しメタデータチャンクを除いて内部辞書を使用することは許可されておらず、前のチャンクが繰り返しメタデータチャンクでない場合、メタデータチャンクがデコーダー状態を維持することは許可されていません。つまり、一連のメタデータチャンクは、フレーミング形式ファイルの他のチャンクを使用せずに減圧できなければなりません。
The fields contained in this metadata chunk must follow the following restrictions:
このメタデータチャンクに含まれるフィールドは、次の制限に従う必要があります。
* If a field is present, it must exactly match the corresponding field of the copied chunk.
* フィールドが存在する場合、コピーされたチャンクの対応するフィールドと正確に一致する必要があります。
* It is allowed to leave out a field that is present in the copied chunk.
* コピーされたチャンクに存在するフィールドを除外することができます。
* If a field is present, then it must be present in *all* other repeat metadata chunks when the copied chunk contains this field. In other words, if you know you can get the name field from a repeat chunk, you know that you will be able to get all names of all resources from all repeat chunks.
* フィールドが存在する場合、コピーされたチャンクにこのフィールドが含まれている場合、他のすべての繰り返しメタデータチャンクに存在する必要があります。言い換えれば、繰り返しチャンクから名前フィールドを取得できることがわかっている場合、すべてのリピートチャンクからすべてのリソースのすべての名前を取得できることを知っています。
The central directory chunk along with the repeat metadata chunks allow quickly finding and listing compressed resources in the container file.
中央のディレクトリチャンクと繰り返しメタデータチャンクにより、コンテナファイルに圧縮リソースをすばやく見つけてリストすることができます。
The central directory chunk is always uncompressed and does not have the codec byte. It instead has the following format:
中央ディレクトリチャンクは常に圧縮されておらず、コーデックバイトがありません。代わりに、次の形式があります。
varint:
VARINT：
Pointer into the file where the repeat metadata chunks are located or 0 if they are not present.
繰り返しメタデータチャンクが配置されているファイルへのポインタ、または存在しない場合は0。
per chunk listed:
一切ごとにリストされています：
varint:
VARINT：
Pointer into the file where this chunk begins.
このチャンクが始まるファイルへのポインタ。
varint:
VARINT：
Number of header bytes N used below.
以下で使用するヘッダーバイトnの数。
N bytes:
nバイト：
Copy of all the header bytes of the pointed at chunk, including total size, chunk type byte, codec, uncompressed size, dictionary references, and X extra header bytes. The content is not repeated here.
総サイズ、チャンクタイプバイト、コーデック、非圧縮サイズ、辞書参照、Xエクストラヘッダーバイトなど、チャンクに尖ったすべてのヘッダーバイトのコピー。ここではコンテンツが繰り返されません。
The last listed chunk is reached when the end of the contents of the central directory are reached. If the end does not match the last byte of the central directory, the decoder must reject the data stream as invalid.
中央ディレクトリの内容の終わりに到達すると、最後にリストされたチャンクに到達します。端が中央ディレクトリの最後のバイトと一致しない場合、デコーダーはデータストリームを無効として拒否する必要があります。
If present, the central directory must list all data and metadata chunks of all types.
存在する場合、中央のディレクトリには、すべてのタイプのすべてのデータとメタデータチャンクをリストする必要があります。
The final footer chunk closes the file and is only present if bit 2 of the initial container flags was set.
最後のフッターチャンクはファイルを閉じ、初期コンテナフラグのビット2が設定されている場合にのみ存在します。
This chunk has the following content, which is always uncompressed:
このチャンクには次のコンテンツがあり、常に圧縮されていません。
reversed varint:
逆バリント：
Size of this entire framing format file, including these bytes themselves, or 0 if this size is not given.
これらのバイト自体を含むこのフレーミングフォーマットファイル全体のサイズ、またはこのサイズが与えられない場合は0。
reversed varint:
逆バリント：
Pointer to the start of the central directory, or 0 if there is none.
中央ディレクトリの開始へのポインタ、またはない場合は0。
A reversed varint has the same format as a varint but its bytes are in reversed order, and it is designed to be parsed from the end of the file towards the beginning.
反転したVarintはVarintと同じ形式を持っていますが、そのバイトは反転した順序であり、ファイルの最後から最初に解析されるように設計されています。
The chunk ordering must follow the rules described below. If the decoder sees otherwise, it must reject the data stream as invalid.
チャンクの順序は、以下のルールに従う必要があります。デコーダーがそうでない場合、データストリームを無効と拒否する必要があります。
Padding chunks may be inserted anywhere, even between chunks for which the rules below say no other chunk types may come in between.
パディングチャンクは、以下のルールが他のチャンクタイプの間に入ることができないと言っているチャンクの間であっても、どこにでも挿入される場合があります。
Metadata chunks must come immediately before the data chunks of the resource they apply to.
メタデータのチャンクは、適用されるリソースのデータチャンクの直前に来なければなりません。
Footer metadata chunks must come immediately after the data chunks of the resource they apply to.
フッターメタデータチャンクは、適用されるリソースのデータチャンクの直後に来る必要があります。
There may be only 0 or 1 metadata chunks per resource.
リソースごとに0または1のメタデータチャンクしかない場合があります。
There may be only 0 or 1 footer metadata chunks per resource.
リソースごとに0または1のフッターメタデータチャンクしかない場合があります。
A resource must exist out of either 1 data chunk or 1 first partial data chunk, 0 or more middle partial data chunks, and 1 last partial data chunk, in that order.
1つのデータチャンクまたは1つの最初の部分データチャンク、0以上の中央部分データチャンク、および1つの最後の部分データチャンクのいずれかからリソースが存在する必要があります。
Repeat metadata chunks must follow the rules of Section 8.4.9.
繰り返しメタデータチャンクは、セクション8.4.9の規則に従う必要があります。
There may be only 0 or 1 central directory chunks.
セントラルディレクトリのチャンクは0または1のみです。
If bit 2 of the container flags is set, there may be only a single resource, no metadata chunks of any type, no central directory, and no final footer.
コンテナフラグのビット2が設定されている場合、単一のリソースのみ、どのタイプのメタデータチャンクも、中央ディレクトリも、最終フッターもありません。
If bit 2 of the container flags is not set, there must be exactly 1 final footer chunk, and it must be the last chunk in the file.
コンテナフラグのビット2が設定されていない場合、最終的なフッターチャンクが正確に1つある必要があり、ファイル内の最後のチャンクでなければなりません。
The security considerations for brotli [RFC7932] apply to shared brotli as well.
Brotli [RFC7932]のセキュリティ上の考慮事項は、共有Brotliにも適用されます。
In addition, the same considerations apply to the decoding of new file format streams for shared brotli, including shared dictionaries, the framing format, and the shared brotli format.
さらに、共有辞書、フレーミング形式、共有Brotli形式など、共有Brotliの新しいファイル形式のストリームのデコードにも同じ考慮事項が適用されます。
The dictionary must be treated with the same security precautions as the content because a change to the dictionary can result in a change to the decompressed content.
辞書はコンテンツと同じセキュリティ上の注意事項で扱う必要があります。これは、辞書を変更すると、減圧コンテンツが変更される可能性があるためです。
The CRIME attack [CRIME] shows that it's a bad idea to compress data from mixed (e.g., public and private) sources -- the data sources include not only the compressed data but also the dictionaries. For example, if you compress secret cookies using a public-data-only dictionary, you still leak information about the cookies.
犯罪攻撃[犯罪]は、混合（たとえば、公共および民間）ソースからデータを圧縮することは悪い考えであることを示しています。データソースには、圧縮データだけでなく辞書も含まれます。たとえば、Public-Dataのみの辞書を使用してシークレットCookieを圧縮する場合、Cookieに関する情報を漏らします。
The dictionary can reveal information about the compressed data and vice versa. That is, data compressed with the dictionary can reveal contents of the dictionary when an adversary can control parts of the data to compress and see the compressed size. On the other hand, if the adversary can control the dictionary, the adversary can learn information about the compressed data.
辞書は、圧縮データに関する情報を明らかにすることができ、その逆も同様です。つまり、辞書で圧縮されたデータは、敵がデータの一部を制御して圧縮されたサイズを圧縮して確認できる場合、辞書の内容を明らかにすることができます。一方、敵が辞書を制御できる場合、敵は圧縮データに関する情報を学ぶことができます。
The most robust defense against CRIME is not to compress private data, e.g., sensitive headers like cookies or any content with personally identifiable information (PII). The challenge has been to identify secrets within a vast amount of data to be compressed. Cloudflare uses a regular expression [CLOUDFLARE]. Another idea is to extend existing web template systems (e.g., Soy [SOY]) to allow developers to mark secrets that must not be compressed.
犯罪に対する最も堅牢な防御は、たとえば、クッキーや個人識別可能な情報（PII）のコンテンツなどの敏感なヘッダーなどのプライベートデータを圧縮することではありません。課題は、圧縮される膨大な量のデータ内で秘密を特定することでした。CloudFlareは正規表現[CloudFlare]を使用します。もう1つのアイデアは、既存のWebテンプレートシステム（Soy [Soy]など）を拡張して、開発者が圧縮してはならない秘密をマークできるようにすることです。
A less robust idea, but easier to implement, is to randomize the compression algorithm, i.e., adding randomly generated padding, varying the compression ratio, etc. The tricky part is to find the right balance between cost and security (i.e., on one hand, we don't want to add too much padding because it adds a cost to data, but on the other hand, we don't want to add too little because the adversary can detect a small amount of padding with traffic analysis).
堅牢ではないが実装しやすいのは、圧縮アルゴリズム、つまりランダムに生成されたパディングを追加し、圧縮比などを変えることです。トリッキーな部分は、コストとセキュリティの間の適切なバランスを見つけることです（つまり、片手で、データを追加するために少額を追加するために、コストを追加するために、コストを追加するために、コストを追加するために、パディングを追加することです。分析）。
Additionally, another defense is to not use dictionaries for cross-domain requests and to only use shared brotli for the response when the origin is the same as where the content is hosted (using CORS). This prevents an adversary from using a private dictionary with user secrets to compress content hosted on the adversary's origin. It also helps prevent CRIME attacks that try to benefit from a public dictionary by preventing data compression with dictionaries for requests that do not originate from the host itself.
さらに、別の防御は、クロスドメイン要求に辞書を使用しないこと、および起源がコンテンツがホストされている場所（CORを使用）と同じ場合の応答に共有Brotliのみを使用することです。これにより、敵がユーザーシークレットを備えたプライベート辞書を使用して、敵の起源にホストされたコンテンツを圧縮することを防ぎます。また、ホスト自体から発生しない要求について、辞書とのデータ圧縮を防ぐことにより、パブリック辞書から利益を得ようとする犯罪攻撃を防ぐのにも役立ちます。
The content of the dictionary itself should not be affected by external users; allowing adversaries to control the dictionary allows a form of chosen plaintext attack. Instead, only base the dictionary on content you control or generic large scale content such as a spoken language and update the dictionary with large time intervals (days, not seconds) to prevent fast probing.
辞書自体の内容は、外部ユーザーの影響を受けるべきではありません。敵が辞書を制御できるようにすると、選択したプレーンテキスト攻撃の形式が許可されます。代わりに、コントロールするコンテンツまたは音声言語などの一般的な大規模なコンテンツに基づいて辞書のみを作成し、高速プロービングを防ぐために大きな時間間隔（日、秒ではなく日数）で辞書を更新します。
The use of HighwayHash [HWYHASH] for dictionary identifiers does not guarantee against collisions in an adversarial environment and is intended to be used for identifying the dictionary within a trusted, known set of dictionaries. In an adversarial environment, users of shared brotli should use another mechanism to validate a negotiated dictionary such as a cryptographically proven secure hash.
辞書識別子にHighwayhash [Hwyhash]の使用は、敵対的環境での衝突に対する保証ではなく、信頼できる既知の辞書セット内で辞書を識別するために使用することを目的としています。敵対的な環境では、共有Brotliのユーザーは別のメカニズムを使用して、暗号化された安全な安全性ハッシュなどのネゴシエート辞書を検証する必要があります。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[HWYHASH] Alakuijala, J., Cox, B., and J. Wassenberg, "Fast keyed
hash/pseudo-random function using SIMD multiply and
permute", DOI 10.48550/arXiv.1612.06257, February 2017,
<https://arxiv.org/abs/1612.06257>.
[RFC7932] Alakuijala, J. and Z. Szabadka, "Brotli Compressed Data
Format", RFC 7932, DOI 10.17487/RFC7932, July 2016,
<https://www.rfc-editor.org/info/rfc7932>.
[CLOUDFLARE]
Loring, B., "A Solution to Compression Oracles on the
Web", The Cloudflare Blog, 27 March 2018,
<https://blog.cloudflare.com/a-solution-to-compression-
oracles-on-the-web/>.
[CRIME] CVE Program, "CVE-2012-4929",
<https://www.cve.org/CVERecord?id=CVE-2012-4929>.
[LZ77] Ziv, J. and A. Lempel, "A Universal Algorithm for
Sequential Data Compression", IEEE Transactions on
Information Theory, vol. 23, no. 3, pp. 337-343,
DOI 10.1109/TIT.1977.1055714, May 1977,
<https://doi.org/10.1109/TIT.1977.1055714>.
[SOY] Google Developers, "Closure Tools",
<https://developers.google.com/closure>.
The authors would like to thank Robert Obryk for suggesting improvements to the format and the text of the specification.
著者は、仕様の形式とテキストの改善を提案してくれたRobert Obrykに感謝したいと思います。
Jyrki Alakuijala
Google, Inc.
Email: jyrki@google.com
Thai Duong
Google, Inc.
Email: thaidn@google.com
Evgenii Kliuchnikov
Google, Inc.
Email: eustas@google.com
Zoltan Szabadka
Google, Inc.
Email: szabadka@google.com
Lode Vandevenne (editor)
Google, Inc.
Email: lode@google.com