[要約] RFC 8941はHTTPで使用される構造化フィールド値を定義しており、HTTPヘッダー、トレーラー、パラメーターの表現を標準化します。この仕様は、データの解析と生成を簡素化し、エラーの可能性を減少させることを目的としています。主に、複雑なデータ構造を効率的に伝達するためのHTTPアプリケーションやサービスで利用されます。
Internet Engineering Task Force (IETF) M. Nottingham
Request for Comments: 8941 Fastly
Category: Standards Track P-H. Kamp
ISSN: 2070-1721 The Varnish Cache Project
February 2021
Structured Field Values for HTTP
httpの構造化フィールド値
Abstract
概要
This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values.
この文書では、「構造化フィールド」、「構造化ヘッダー」、「構造化トレーラー」と呼ばれるHTTPヘッダーおよびトレーラー・フィールドの定義および処理を容易にし、より安全にすることを目的とした一連のデータ型と関連付けられています。従来のHTTPフィールド値よりも制限的な共通構文を使用したい新しいHTTPフィールドの仕様による使用を目的としています。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc8941.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8941で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Intentionally Strict Processing
1.2. Notational Conventions
2. Defining New Structured Fields
3. Structured Data Types
3.1. Lists
3.1.1. Inner Lists
3.1.2. Parameters
3.2. Dictionaries
3.3. Items
3.3.1. Integers
3.3.2. Decimals
3.3.3. Strings
3.3.4. Tokens
3.3.5. Byte Sequences
3.3.6. Booleans
4. Working with Structured Fields in HTTP
4.1. Serializing Structured Fields
4.1.1. Serializing a List
4.1.2. Serializing a Dictionary
4.1.3. Serializing an Item
4.1.4. Serializing an Integer
4.1.5. Serializing a Decimal
4.1.6. Serializing a String
4.1.7. Serializing a Token
4.1.8. Serializing a Byte Sequence
4.1.9. Serializing a Boolean
4.2. Parsing Structured Fields
4.2.1. Parsing a List
4.2.2. Parsing a Dictionary
4.2.3. Parsing an Item
4.2.4. Parsing an Integer or Decimal
4.2.5. Parsing a String
4.2.6. Parsing a Token
4.2.7. Parsing a Byte Sequence
4.2.8. Parsing a Boolean
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Frequently Asked Questions
A.1. Why Not JSON?
Appendix B. Implementation Notes
Acknowledgements
Authors' Addresses
Specifying the syntax of new HTTP header (and trailer) fields is an onerous task; even with the guidance in Section 8.3.1 of [RFC7231], there are many decisions -- and pitfalls -- for a prospective HTTP field author.
新しいHTTPヘッダー（およびトレーラー）フィールドの構文を指定することは、Onerousタスクです。[RFC7231]のセクション8.3.1のガイダンスでも、多くの決定があります。
Once a field is defined, bespoke parsers and serializers often need to be written, because each field value has a slightly different handling of what looks like common syntax.
フィールドが定義されると、各フィールド値には一般的な構文のようなものがわずかに異なるのがわずかに異なる場合があります。
This document introduces a set of common data structures for use in definitions of new HTTP field values to address these problems. In particular, it defines a generic, abstract model for them, along with a concrete serialization for expressing that model in HTTP [RFC7230] header and trailer fields.
この文書では、これらの問題に対処するための新しいHTTPフィールド値の定義に使用するための一連の共通データ構造を紹介します。特に、HTTP [RFC7230]ヘッダーフィールドとトレーラフィールドでそのモデルを表現するための具体的なシリアル化とともに、それらのための一般的な抽象モデルを定義します。
An HTTP field that is defined as a "Structured Header" or "Structured Trailer" (if the field can be either, it is a "Structured Field") uses the types defined in this specification to define its syntax and basic handling rules, thereby simplifying both its definition by specification writers and handling by implementations.
「構造化ヘッダー」または「構造化トレーラー」として定義されているHTTPフィールド（フィールドが「構造化フィールド」の場合）この仕様で定義されている型を使用して、その構文と基本的な処理規則を定義します。実装による仕様作成者と処理の両方の定義を単純化する。
Additionally, future versions of HTTP can define alternative serializations of the abstract model of these structures, allowing fields that use that model to be transmitted more efficiently without being redefined.
さらに、HTTPの将来のバージョンは、これらの構造体の抽象モデルの代替シリアル化を定義でき、そのモデルを使用するフィールドを再定義せずにより効率的に送信することができます。
Note that it is not a goal of this document to redefine the syntax of existing HTTP fields; the mechanisms described herein are only intended to be used with fields that explicitly opt into them.
既存のHTTPフィールドの構文を再定義するのは、このドキュメントの目標ではありません。本明細書に記載のメカニズムは、明示的にそれらを求めるフィールドと共に使用されることを意図している。
Section 2 describes how to specify a Structured Field.
セクション2は構造化フィールドを指定する方法を説明しています。
Section 3 defines a number of abstract data types that can be used in Structured Fields.
セクション3は、構造化フィールドで使用できる抽象データ型の数を定義します。
Those abstract types can be serialized into and parsed from HTTP field values using the algorithms described in Section 4.
これらの抽象タイプは、セクション4に記載されているアルゴリズムを使用してHTTPフィールド値にシリアル化され、解析することができます。
This specification intentionally defines strict parsing and serialization behaviors using step-by-step algorithms; the only error handling defined is to fail the operation altogether.
この仕様は意図的に、ステップバイステップのアルゴリズムを使用して厳密な解析とシリアル化の動作を定義します。定義された唯一のエラー処理は、操作を完全に失敗させることです。
It is designed to encourage faithful implementation and good interoperability. Therefore, an implementation that tried to be helpful by being more tolerant of input would make interoperability worse, since that would create pressure on other implementations to implement similar (but likely subtly different) workarounds.
それは忠実な実施と良好な相互運用性を促進するように設計されています。したがって、入力のより寛容であることによって役立つようにしようとした実装は相互運用性を悪化させるであろうので、それは他の実装に圧力を生み出して類似している（しかし、微妙に異なる）回避策を実装することができます。
In other words, strict processing is an intentional feature of this specification; it allows non-conformant input to be discovered and corrected by the producer early and avoids both interoperability and security issues that might otherwise result.
言い換えれば、厳密な処理はこの仕様の意図的な特徴である。それは、不適合の入力をプロデューサによって早期に発見され修正され、そうでなければ結果的になる可能性がある相互運用性とセキュリティの両方の問題を回避することができます。
Note that as a result of this strictness, if a field is appended to by multiple parties (e.g., intermediaries or different components in the sender), an error in one party's value is likely to cause the entire field value to fail parsing.
この厳密さの結果として、フィールドが複数の当事者（例えば、送信者内の仲介者または異なるコンポーネント）によって添付されている場合、一方の当事者の値のエラーがフィールド値全体が解析を失敗させる可能性があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document uses algorithms to specify parsing and serialization behaviors and the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] to illustrate expected syntax in HTTP header fields. In doing so, it uses the VCHAR, SP, DIGIT, ALPHA, and DQUOTE rules from [RFC5234]. It also includes the tchar and OWS rules from [RFC7230].
この文書は、HTTPヘッダーフィールドの予想される構文を説明するために、解析とシリアル化の動作と、[RFC5234]の拡張された背景 - Naur形式（ABNF）表記を指定するためのアルゴリズムを使用します。そうすることで、[RFC5234]からVCHAR、SP、DIGIT、ALPHA、およびDQUOTEルールを使用します。[RFC7230]からTCHARとOWSの規則も含まれています。
When parsing from HTTP fields, implementations MUST have behavior that is indistinguishable from following the algorithms. If there is disagreement between the parsing algorithms and ABNF, the specified algorithms take precedence.
HTTPフィールドから解析する場合、実装にはアルゴリズムに従って区別がつかない動作が必要です。解析アルゴリズムとABNFの間に不一致がある場合、指定されたアルゴリズムは優先されます。
For serialization to HTTP fields, the ABNF illustrates their expected wire representations, and the algorithms define the recommended way to produce them. Implementations MAY vary from the specified behavior so long as the output is still correctly handled by the parsing algorithm described in Section 4.2.
HTTPフィールドへのシリアル化のために、ABNFは予想されるワイヤ表現を示し、アルゴリズムはそれらを作成するための推奨される方法を定義します。実装は、セクション4.2で説明されている解析アルゴリズムによって依然として正しく処理されている限り、実装は指定された動作によって異なります。
To specify an HTTP field as a Structured Field, its authors need to:
httpフィールドを構造化フィールドとして指定するには、次のことが必要です。
* Normatively reference this specification. Recipients and generators of the field need to know that the requirements of this document are in effect.
* 通常の仕様を参照してください。フィールドの受信者と発電機は、この文書の要件が有効であることを知っておく必要があります。
* Identify whether the field is a Structured Header (i.e., it can only be used in the header section -- the common case), a Structured Trailer (only in the trailer section), or a Structured Field (both).
* フィールドが構造化ヘッダーかを特定します（すなわち、ヘッダセクション - 共通ケース（予告編セクション内のみ）、構造化されたトレーラ、または構造化フィールド（両方）でのみ使用できます。
* Specify the type of the field value; either List (Section 3.1), Dictionary (Section 3.2), or Item (Section 3.3).
* フィールド値の種類を指定してください。リスト（3.1）、辞書（3.2項）、または項目（セクション3.3）。
* Define the semantics of the field value.
* フィールド値のセマンティクスを定義します。
* Specify any additional constraints upon the field value, as well as the consequences when those constraints are violated.
* フィールド値に追加の制約、およびそれらの制約が違反した場合の結果を指定します。
Typically, this means that a field definition will specify the top-level type -- List, Dictionary, or Item -- and then define its allowable types and constraints upon them. For example, a header defined as a List might have all Integer members, or a mix of types; a header defined as an Item might allow only Strings, and additionally only strings beginning with the letter "Q", or strings in lowercase. Likewise, Inner Lists (Section 3.1.1) are only valid when a field definition explicitly allows them.
通常、これはフィールド定義が最上位タイプ - リスト、辞書、または項目を指定してから、その許容型と制約を定義します。たとえば、リストとして定義されているヘッダーには、すべての整数メンバー、またはタイプの組み合わせがあります。アイテムとして定義されたヘッダーは文字列のみを許可し、さらに文字 "Q"、または文字列の文字列だけで小文字の文字列だけです。同様に、内部リスト（セクション3.1.1）は、フィールド定義が明示的にそれらを許可する場合にのみ有効です。
When parsing fails, the entire field is ignored (see Section 4.2); in most situations, violating field-specific constraints should have the same effect. Thus, if a header is defined as an Item and required to be an Integer, but a String is received, the field will by default be ignored. If the field requires different error handling, this should be explicitly specified.
解析が失敗すると、フィールド全体が無視されます（セクション4.2を参照）。ほとんどの状況では、フィールド固有の制約に違反するはずの効果があるはずです。したがって、ヘッダーが項目として定義されているが文字列が受信された場合、そのフィールドはデフォルトでは無視されます。フィールドに異なるエラー処理が必要な場合は、これを明示的に指定する必要があります。
Both Items and Inner Lists allow parameters as an extensibility mechanism; this means that values can later be extended to accommodate more information, if need be. To preserve forward compatibility, field specifications are discouraged from defining the presence of an unrecognized parameter as an error condition.
アイテムと内部リストの両方が拡張メカニズムとしてパラメータを許可します。これは、必要に応じて、値をより多くの情報に対応するように延長することができることを意味します。前方の互換性を維持するために、フィールド仕様は、認識されていないパラメータの存在をエラー状態として定義することを推奨しています。
To further assure that this extensibility is available in the future, and to encourage consumers to use a complete parser implementation, a field definition can specify that "grease" parameters be added by senders. A specification could stipulate that all parameters that fit a defined pattern are reserved for this use and then encourage them to be sent on some portion of requests. This helps to discourage recipients from writing a parser that does not account for Parameters.
この拡張性が将来利用可能であり、消費者に完全なパーサの実装を使用することを促すことをさらに保証するために、フィールド定義は「グリース」パラメータを送信者によって追加するように指定することができる。指定されたパターンに適合するすべてのパラメータがこの使用のために予約されてから、それらが要求のいくつかの部分で送信されるように促すことを規定することができます。これにより、受信者がパラメータを説明しないパーサを書くことができないようにします。
Specifications that use Dictionaries can also allow for forward compatibility by requiring that the presence of -- as well as value and type associated with -- unknown members be ignored. Subsequent specifications can then add additional members, specifying constraints on them as appropriate.
辞書を使用する仕様は、存在すること、および関連する型とタイプの存在とタイプを無視することを要求することで、互換性の互換性も可能になる可能性があります。その後の仕様で追加のメンバーを追加し、必要に応じて制約を指定できます。
An extension to a Structured Field can then require that an entire field value be ignored by a recipient that understands the extension if constraints on the value it defines are not met.
構造化フィールドへの拡張機能は、定義された値の制約が満たされていない場合に拡張子を理解する受信者によってフィールド値全体を無視する必要があります。
A field definition cannot relax the requirements of this specification because doing so would preclude handling by generic software; they can only add additional constraints (for example, on the numeric range of Integers and Decimals, the format of Strings and Tokens, the types allowed in a Dictionary's values, or the number of Items in a List). Likewise, field definitions can only use this specification for the entire field value, not a portion thereof.
この仕様の要件を緩和することはできませんので、一般的なソフトウェアによる処理を妨げるためです。それらは、追加の制約を追加することしか（たとえば、整数と小数点の数値範囲、文字列とトークンの形式、辞書の値に許可されている型、またはリスト内の項目数）を追加できます。同様に、フィールド定義は、その一部ではなく、フィールド値全体に対してのみ使用することができる。
This specification defines minimums for the length or number of various structures supported by implementations. It does not specify maximum sizes in most cases, but authors should be aware that HTTP implementations do impose various limits on the size of individual fields, the total number of fields, and/or the size of the entire header or trailer section.
この仕様は、実装によってサポートされているさまざまな構造の長さまたは数の最小値を定義します。ほとんどの場合最大サイズを指定しませんが、HTTP実装は個々のフィールドのサイズ、フィールドの総数、および/またはヘッダーまたはトレーラセクションのサイズにさまざまな制限を課すことに注意してください。
Specifications can refer to a field name as a "structured header name", "structured trailer name", or "structured field name" as appropriate. Likewise, they can refer its field value as a "structured header value", "structured trailer value", or "structured field value" as necessary. Field definitions are encouraged to use the ABNF rules beginning with "sf-" defined in this specification; other rules in this specification are not intended to be used in field definitions.
仕様は、「構造化ヘッダー名」、「構造化トレーラー名」、「構造化・フィールド名」としてのフィールド名を適切に参照できます。同様に、そのフィールド値を「構造化ヘッダ値」、「構造化トレーラ値」、または必要に応じて「構造化フィールド値」として参照することができる。フィールド定義は、この仕様で定義された「SF-」で始まるABNF規則を使用することをお勧めします。この仕様の他の規則は、フィールド定義で使用することを意図していません。
For example, a fictitious Foo-Example header field might be specified as:
たとえば、架空のFoo-example headerフィールドは次のように指定されている可能性があります。
| 42. Foo-Example Header
|
| The Foo-Example HTTP header field conveys information about how
| much Foo the message has.
|
| Foo-Example is an Item Structured Header [RFC8941]. Its value
| MUST be an Integer (Section 3.3.1 of [RFC8941]). Its ABNF is:
|
| Foo-Example = sf-integer
|
| Its value indicates the amount of Foo in the message, and it MUST
| be between 0 and 10, inclusive; other values MUST cause the entire
| header field to be ignored.
|
| The following parameter is defined:
| * A parameter whose key is "foourl", and whose value is a String
| (Section 3.3.3 of [RFC8941]), conveying the Foo URL for the
| message. See below for processing requirements.
|
| "foourl" contains a URI-reference (Section 4.1 of [RFC3986]). If
| its value is not a valid URI-reference, the entire header field
| MUST be ignored. If its value is a relative reference
| (Section 4.2 of [RFC3986]), it MUST be resolved (Section 5 of
| [RFC3986]) before being used.
|
| For example:
|
| Foo-Example: 2; foourl="https://foo.example.com/"
This section defines the abstract types for Structured Fields. The ABNF provided represents the on-wire format in HTTP field values.
このセクションでは、構造化フィールドの抽象タイプを定義します。提供されたABNFは、HTTPフィールド値のオンイワイヤフォーマットを表します。
In summary:
要約すれば：
* There are three top-level types that an HTTP field can be defined as: Lists, Dictionaries, and Items.
* HTTPフィールドは、リスト、辞書、およびアイテムとして定義できる3つの最上位タイプがあります。
* Lists and Dictionaries are containers; their members can be Items or Inner Lists (which are themselves arrays of Items).
* リストと辞書はコンテナです。彼らのメンバーはアイテムまたはインナーリスト（それ自体アイテムの配列です）です。
* Both Items and Inner Lists can be Parameterized with key/value pairs.
* アイテムと内部リストの両方をキー/値のペアでパラメータ化できます。
Lists are arrays of zero or more members, each of which can be an Item (Section 3.3) or an Inner List (Section 3.1.1), both of which can be Parameterized (Section 3.1.2).
リストは0個以上のメンバーの配列であり、それぞれが項目（セクション3.3）または内部リスト（セクション3.1.1）であり、どちらもパラメータ化できます（セクション3.1.2）。
The ABNF for Lists in HTTP fields is:
HTTPフィールドのリストのABNFは次のとおりです。
sf-list = list-member *( OWS "," OWS list-member )
list-member = sf-item / inner-list
Each member is separated by a comma and optional whitespace. For example, a field whose value is defined as a List of Tokens could look like:
各メンバーはコンマとオプションの空白によって区切られています。たとえば、値がトークンのリストとして定義されているフィールドは次のようになります。
Example-List: sugar, tea, rum
例リスト：砂糖、紅茶、ラム
An empty List is denoted by not serializing the field at all. This implies that fields defined as Lists have a default empty value.
空のリストは、フィールドをまったくシリアル化しないことによって示されます。これは、リストとして定義されたフィールドにデフォルトの空の値があることを意味します。
Note that Lists can have their members split across multiple lines of the same header or trailer section, as per Section 3.2.2 of [RFC7230]; for example, the following are equivalent:
[RFC7230]のセクション3.2.2のセクション3.2.2に従って、メンバーを同じヘッダーまたはトレーラー・セクションの複数行に分割することができます。たとえば、以下は同等です。
Example-List: sugar, tea, rum
例リスト：砂糖、紅茶、ラム
and
そして
Example-List: sugar, tea Example-List: rum
例リスト：砂糖、ティーサンプルリスト：ラム
However, individual members of a List cannot be safely split between lines; see Section 4.2 for details.
ただし、リストの個々のメンバーは行の間で安全に分割できません。詳細は4.2節をご覧ください。
Parsers MUST support Lists containing at least 1024 members. Field specifications can constrain the types and cardinality of individual List values as they require.
パーサーは、少なくとも1024のメンバーを含むリストをサポートする必要があります。フィールド仕様は、必要なように個々のリスト値の型と濃度を制限することができます。
An Inner List is an array of zero or more Items (Section 3.3). Both the individual Items and the Inner List itself can be Parameterized (Section 3.1.2).
内側リストは、ゼロ以上の項目の配列です（セクション3.3）。個々の項目と内部リスト自体の両方をパラメータ化することができます（セクション3.1.2）。
The ABNF for Inner Lists is:
内部リストのABNFは次のとおりです。
inner-list = "(" *SP [ sf-item *( 1*SP sf-item ) *SP ] ")"
parameters
Inner Lists are denoted by surrounding parenthesis, and their values are delimited by one or more spaces. A field whose value is defined as a List of Inner Lists of Strings could look like:
内部リストは周囲の括弧によって示され、それらの値は1つ以上のスペースによって区切られています。値が文字列の内部リストのリストとして定義されているフィールドは次のようになります。
Example-List: ("foo" "bar"), ("baz"), ("bat" "one"), ()
例 - リスト：（ "foo" "" "（" baz "）、（" bat "" 1 "）、（）
Note that the last member in this example is an empty Inner List.
この例の最後のメンバーは空の内部リストです。
A header field whose value is defined as a List of Inner Lists with Parameters at both levels could look like:
両方のレベルでパラメータを持つインナーリストのリストとして値が定義されているヘッダーフィールドは次のようになります。
Example-List: ("foo"; a=1;b=2);lvl=5, ("bar" "baz");lvl=1
Parsers MUST support Inner Lists containing at least 256 members. Field specifications can constrain the types and cardinality of individual Inner List members as they require.
パーサーは、少なくとも256のメンバーを含む内部リストをサポートしなければなりません。フィールド仕様は、必要なように個々の内部リストメンバーのタイプとカーディナリティを制限できます。
Parameters are an ordered map of key-value pairs that are associated with an Item (Section 3.3) or Inner List (Section 3.1.1). The keys are unique within the scope of the Parameters they occur within, and the values are bare items (i.e., they themselves cannot be parameterized; see Section 3.3).
パラメータは、アイテム（セクション3.3）または内部リストに関連付けられているキー値ペアの順序付けられたマップです（セクション3.1.1）。キーは、内部に発生したパラメータの範囲内で一意であり、値は裸のアイテムである（すなわち、それら自体はパラメータ化できません。セクション3.3を参照）。
Implementations MUST provide access to Parameters both by index and by key. Specifications MAY use either means of accessing them.
実装は、インデックスとキーの両方でパラメータへのアクセスを提供する必要があります。仕様はそれらにアクセスする手段を使用することができます。
The ABNF for Parameters is:
パラメータのABNFは次のとおりです。
parameters = *( ";" *SP parameter )
parameter = param-key [ "=" param-value ]
param-key = key
key = ( lcalpha / "*" )
*( lcalpha / DIGIT / "_" / "-" / "." / "*" )
lcalpha = %x61-7A ; a-z
param-value = bare-item
Note that parameters are ordered as serialized, and parameter keys cannot contain uppercase letters. A parameter is separated from its Item or Inner List and other parameters by a semicolon. For example:
パラメータは直列化されていると並べられ、パラメータキーに大文字を含めることはできません。パラメータは、その項目または内部リストおよびその他のパラメータからセミコロンで区切られています。例えば：
Example-List: abc;a=1;b=2; cde_456, (ghi;jk=4 l);q="9";r=w
Parameters whose value is Boolean (see Section 3.3.6) true MUST omit that value when serialized. For example, the "a" parameter here is true, while the "b" parameter is false:
値がboolean（セクション3.3.6を参照）のパラメータ（セクション3.3.6を参照）。たとえば、 "b"パラメータがfalseである間、 "A"パラメータはtrueです。
Example-Integer: 1; a; b=?0
Note that this requirement is only on serialization; parsers are still required to correctly handle the true value when it appears in a parameter.
この要件はシリアル化に限らないことに注意してください。パーサーは、パラメータに表示されたときに真の値を正しく処理するために依然として必要です。
Parsers MUST support at least 256 parameters on an Item or Inner List, and support parameter keys with at least 64 characters. Field specifications can constrain the order of individual parameters, as well as their values' types as required.
パーサーは、アイテムまたはインナーリストで少なくとも256のパラメーターをサポートし、少なくとも64文字のパラメーターキーをサポートしてください。フィールド仕様は、必要に応じて個々のパラメータの順序、および値のタイプを制限することができます。
Dictionaries are ordered maps of key-value pairs, where the keys are short textual strings and the values are Items (Section 3.3) or arrays of Items, both of which can be Parameterized (Section 3.1.2). There can be zero or more members, and their keys are unique in the scope of the Dictionary they occur within.
辞書はキー値ペアの順序付けられたマップです。ここで、キーは短いテキスト文字列であり、値は項目（セクション3.3）またはアイテムの配列です。どちらもパラメータ化できます（セクション3.1.2）。ゼロ以上のメンバーがある可能性があり、それらのキーは内部に発生する辞書の範囲内で一意です。
Implementations MUST provide access to Dictionaries both by index and by key. Specifications MAY use either means of accessing the members.
実装は、索引と鍵による辞書にアクセスする必要があります。仕様はメンバーにアクセスする手段を使用することができます。
The ABNF for Dictionaries is:
辞書のABNFは次のとおりです。
sf-dictionary = dict-member *( OWS "," OWS dict-member )
dict-member = member-key ( parameters / ( "=" member-value ))
member-key = key
member-value = sf-item / inner-list
Members are ordered as serialized and separated by a comma with optional whitespace. Member keys cannot contain uppercase characters. Keys and values are separated by "=" (without whitespace). For example:
メンバーはシリアル化され、オプションの空白を持つコンマによって区切られています。メンバーキーに大文字を含めることはできません。キーと値は "="で区切ります（空白なし）。例えば：
Example-Dict: en="Applepie", da=:w4ZibGV0w6ZydGU=:
例 - dict：en = "applepie"、da =：w4zibgv0w6zydgu =：
Note that in this example, the final "=" is due to the inclusion of a Byte Sequence; see Section 3.3.5.
この例では、最後の "="はバイトシーケンスを含めることによるものです。3.3.5項を参照してください。
Members whose value is Boolean (see Section 3.3.6) true MUST omit that value when serialized. For example, here both "b" and "c" are true:
値がbooleanであるメンバー（セクション3.3.6を参照）。たとえば、ここで「B」と「C」の両方が当てはまります。
Example-Dict: a=?0, b, c; foo=bar
Note that this requirement is only on serialization; parsers are still required to correctly handle the true Boolean value when it appears in Dictionary values.
この要件はシリアル化に限らないことに注意してください。パーサーは、辞書の値に表示されたときに真のブール値を正しく処理するために依然として必要です。
A Dictionary with a member whose value is an Inner List of Tokens:
値がトークンの内部リストであるメンバーを持つ辞書
Example-Dict: rating=1.5, feelings=(joy sadness)
A Dictionary with a mix of Items and Inner Lists, some with parameters:
アイテムと内部リストの組み合わせを持つ辞書、パラメータを持つものがあります。
Example-Dict: a=(1 2), b=3, c=4;aa=bb, d=(5 6);valid
As with Lists, an empty Dictionary is represented by omitting the entire field. This implies that fields defined as Dictionaries have a default empty value.
リストと同様に、空の辞書はフィールド全体を省略することによって表されます。これは、辞書として定義されたフィールドにデフォルトの空の値があることを意味します。
Typically, a field specification will define the semantics of Dictionaries by specifying the allowed type(s) for individual members by their keys, as well as whether their presence is required or optional. Recipients MUST ignore members whose keys that are undefined or unknown, unless the field's specification specifically disallows them.
通常、フィールド仕様は、個々のメンバーの許可された型をそれらの鍵で指定することによって、そしてそれらの存在が必要かオプションかを指定することによって辞書の意味論を定義します。受信者は、フィールドの仕様が具体的にそれらを許可しない限り、未定義または不明なキーを無視する必要があります。
Note that Dictionaries can have their members split across multiple lines of the same header or trailer section; for example, the following are equivalent:
辞書は、同じヘッダーまたはトレーラーセクションの複数の行に分割されていることがあります。たとえば、以下は同等です。
Example-Dict: foo=1, bar=2
and
そして
Example-Dict: foo=1
Example-Dict: bar=2
However, individual members of a Dictionary cannot be safely split between lines; see Section 4.2 for details.
ただし、辞書の個々のメンバーは行の間で安全に分割できません。詳細は4.2節をご覧ください。
Parsers MUST support Dictionaries containing at least 1024 key/value pairs and keys with at least 64 characters. Field specifications can constrain the order of individual Dictionary members, as well as their values' types as required.
パーサーは、少なくとも1024のキー/値のペアと少なくとも64文字のキーを含む辞書をサポートする必要があります。フィールド仕様は、個々の辞書メンバーの順序、および必要に応じて値のタイプを制限することができます。
An Item can be an Integer (Section 3.3.1), a Decimal (Section 3.3.2), a String (Section 3.3.3), a Token (Section 3.3.4), a Byte Sequence (Section 3.3.5), or a Boolean (Section 3.3.6). It can have associated parameters (Section 3.1.2).
アイテムは、整数（セクション3.3.1）、10進数（セクション3.3.2）、文字列（セクション3.3.3）、トークン（セクション3.3.4）、バイトシーケンス（セクション3.3.5）です。またはブール値（セクション3.3.6）。それは関連するパラメータを持つことができます（セクション3.1.2）。
The ABNF for Items is:
アイテムのABNFは次のとおりです。
sf-item = bare-item parameters
bare-item = sf-integer / sf-decimal / sf-string / sf-token
/ sf-binary / sf-boolean
For example, a header field that is defined to be an Item that is an Integer might look like:
たとえば、整数の項目になるように定義されているヘッダーフィールドは次のようになります。
Example-Integer: 5
例 - 整数：5
or with parameters:
またはパラメータと：
Example-Integer: 5; foo=bar
Integers have a range of -999,999,999,999,999 to 999,999,999,999,999 inclusive (i.e., up to fifteen digits, signed), for IEEE 754 compatibility [IEEE754].
整数は[IEEE754]IEEE754互換性のために、-999,999,999,999,999999,999,999,999,999に包括（15桁、すなわち、最大、署名された）の範囲を有します。
The ABNF for Integers is:
整数のABNFは次のとおりです。
sf-integer = ["-"] 1*15DIGIT
For example:
例えば：
Example-Integer: 42
例 - 整数：42
Integers larger than 15 digits can be supported in a variety of ways; for example, by using a String (Section 3.3.3), a Byte Sequence (Section 3.3.5), or a parameter on an Integer that acts as a scaling factor.
整数15桁を超える整数はさまざまな方法でサポートできます。たとえば、文字列（3.3.3）、バイトシーケンス（セクション3.3.5）、またはスケーリングファクタとして機能する整数のパラメータを使用することによって。
While it is possible to serialize Integers with leading zeros (e.g., "0002", "-01") and signed zero ("-0"), these distinctions may not be preserved by implementations.
先行ゼロ（例えば、「0002」、「-01」）と整数をシリアル化し、ゼロ（「-0」）を順番にシリアル化することが可能であるが、これらの区別は実装によって保持されない可能性がある。
Note that commas in Integers are used in this section's prose only for readability; they are not valid in the wire format.
このセクションでは、読みやすさの場合にのみ整数のコンマが使用されていることに注意してください。ワイヤ形式では無効です。
Decimals are numbers with an integer and a fractional component. The integer component has at most 12 digits; the fractional component has at most three digits.
小数部は整数と小数成分の数字です。整数コンポーネントは最大12桁です。分数成分は最大3桁です。
The ABNF for decimals is:
小数のABNFは次のとおりです。
sf-decimal = ["-"] 1*12DIGIT "." 1*3DIGIT
For example, a header whose value is defined as a Decimal could look like:
たとえば、値が小数点以下として定義されているヘッダーは次のようになります。
Example-Decimal: 4.5
例 - 10進数：4.5
While it is possible to serialize Decimals with leading zeros (e.g., "0002.5", "-01.334"), trailing zeros (e.g., "5.230", "-0.40"), and signed zero (e.g., "-0.0"), these distinctions may not be preserved by implementations.
小切手ゼロ（例えば、「0002.5」、「-01.334」）、末尾のゼロ（例えば、「5.230」、「-0.40」）を有する小桁（例えば、「5.230」、「-0.40」）でシリアル化することが可能であるが、ゼロ（例えば「-0.0」）これらの区別は実装によって保持されないかもしれません。
Note that the serialization algorithm (Section 4.1.5) rounds input with more than three digits of precision in the fractional component. If an alternative rounding strategy is desired, this should be specified by the header definition to occur before serialization.
直列化アルゴリズム（セクション4.1.5）は、小数成分の3桁以上の精度で入力を切ります。代替の丸め方針が望まれる場合、これはシリアル化の前に発生するヘッダ定義によって指定されるべきです。
Strings are zero or more printable ASCII [RFC0020] characters (i.e., the range %x20 to %x7E). Note that this excludes tabs, newlines, carriage returns, etc.
文字列は、0個以上の印刷可能なASCII [RFC0020]文字（すなわち、％x20から％x7eの範囲）である。これはタブ、改行、キャリッジリターンなどを除外することに注意してください。
The ABNF for Strings is:
文字列のABNFは次のとおりです。
sf-string = DQUOTE *chr DQUOTE
chr = unescaped / escaped
unescaped = %x20-21 / %x23-5B / %x5D-7E
escaped = "\" ( DQUOTE / "\" )
Strings are delimited with double quotes, using a backslash ("\") to escape double quotes and backslashes. For example:
文字列は、バックスラッシュ（ "\"）を使って二重引用符とバックスラッシュをエスケープします。例えば：
Example-String: "hello world"
例列： "Hello World"
Note that Strings only use DQUOTE as a delimiter; single quotes do not delimit Strings. Furthermore, only DQUOTE and "\" can be escaped; other characters after "\" MUST cause parsing to fail.
文字列はDELIMITERとしてDQUOTEのみを使用することに注意してください。一重引用符は文字列を区切らない。さらに、DQUOTEと「\」のみが逃げることができます。「\」の後の他の文字は、解析が失敗する原因となります。
Unicode is not directly supported in Strings, because it causes a number of interoperability issues, and -- with few exceptions -- field values do not require it.
Unicodeは、数多くの相互運用性の問題を引き起こすため、文字列では直接サポートされていません。
When it is necessary for a field value to convey non-ASCII content, a Byte Sequence (Section 3.3.5) can be specified, along with a character encoding (preferably UTF-8 [STD63]).
フィールド値が非ASCIIコンテンツを搬送する必要がある場合は、文字符号化（好ましくはUTF - 8 [STD63]）とともにバイトシーケンス（セクション3.3.5）を指定することができる。
Parsers MUST support Strings (after any decoding) with at least 1024 characters.
パーサーは、（デコードの後に）1024文字以上の文字列をサポートしている必要があります。
Tokens are short textual words; their abstract model is identical to their expression in the HTTP field value serialization.
トークンは短いテキスト単語です。それらの抽象モデルは、HTTPフィールド値のシリアル化におけるそれらの式と同じです。
The ABNF for Tokens is:
トークンのABNFは次のとおりです。
sf-token = ( ALPHA / "*" ) *( tchar / ":" / "/" )
For example:
例えば：
Example-Token: foo123/456
例 - トークン：foo 123/456
Parsers MUST support Tokens with at least 512 characters.
パーサーは少なくとも512文字のトークンをサポートする必要があります。
Note that Token allows the same characters as the "token" ABNF rule defined in [RFC7230], with the exceptions that the first character is required to be either ALPHA or "*", and ":" and "/" are also allowed in subsequent characters.
トークンでは、[RFC7230]で定義されている「トークン」ABNF規則と同じ文字を使用すると、最初の文字がアルファまたは「*」、「：」と「/」のいずれかであることが必要な例外があります。後続の文字
Byte Sequences can be conveyed in Structured Fields.
バイトシーケンスは構造化フィールドで伝えられます。
The ABNF for a Byte Sequence is:
バイトシーケンスのABNFは次のとおりです。
sf-binary = ":" *(base64) ":"
base64 = ALPHA / DIGIT / "+" / "/" / "="
A Byte Sequence is delimited with colons and encoded using base64 ([RFC4648], Section 4). For example:
バイトシーケンスはコロンで区切られ、Base64（[RFC4648]、セクション4）を使用してエンコードされます。例えば：
Example-ByteSequence: :cHJldGVuZCB0aGlzIGlzIGJpbmFyeSBjb250ZW50Lg==:
例 - bytesequence :: chjldgvuzcb0aglziglzigjpbmfyesbjb250zw50lg ==：
Parsers MUST support Byte Sequences with at least 16384 octets after decoding.
パーサーは、デコード後に少なくとも16384オクテットのバイトシーケンスをサポートしている必要があります。
Boolean values can be conveyed in Structured Fields.
ブール値は構造化フィールドで伝えられます。
The ABNF for a Boolean is:
ブール値のABNFは次のとおりです。
sf-boolean = "?" boolean
boolean = "0" / "1"
A Boolean is indicated with a leading "?" character followed by a "1" for a true value or "0" for false. For example:
ブール値は、先頭の「？」で示されています。文字の後には「1」、またはfalseの場合は "0"が続きます。例えば：
Example-Boolean: ?1
例 - ブール値：？1
Note that in Dictionary (Section 3.2) and Parameter (Section 3.1.2) values, Boolean true is indicated by omitting the value.
辞書（セクション3.2）およびパラメータ（セクション3.1.2）の値では、BUALEAN TRUEが値を省略して表示されます。
This section defines how to serialize and parse Structured Fields in textual HTTP field values and other encodings compatible with them (e.g., in HTTP/2 [RFC7540] before compression with HPACK [RFC7541]).
このセクションでは、構造化フィールドとそれらと互換性のある他のエンコーディング（例えば、HPACK [RFC7541]で圧縮する前にHTTP / 2 [RFC7540]）に構造化フィールドをシリアライズおよび解析する方法を定義します。
Given a structure defined in this specification, return an ASCII string suitable for use in an HTTP field value.
この仕様で定義された構造を考えると、HTTPフィールド値での使用に適したASCII文字列を返します。
1. If the structure is a Dictionary or List and its value is empty (i.e., it has no members), do not serialize the field at all (i.e., omit both the field-name and field-value).
1. 構造体が辞書またはリストであり、その値が空の場合（すなわち、メンバーがいない）は、フィールドをまったくシリアル化しない（すなわち、フィールド名とフィールド値の両方を省略します）。
2. If the structure is a List, let output_string be the result of running Serializing a List (Section 4.1.1) with the structure.
2. 構造がリストの場合は、OUTPUT_STRINGを構造体のシリアル化（セクション4.1.1）を実行した結果です。
3. Else, if the structure is a Dictionary, let output_string be the result of running Serializing a Dictionary (Section 4.1.2) with the structure.
3. そうでなければ、構造が辞書であれば、opput_stringを構造体で辞書のシリアル化（セクション4.1.2）を実行した結果にします。
4. Else, if the structure is an Item, let output_string be the result of running Serializing an Item (Section 4.1.3) with the structure.
4. そうでなければ、構造がアイテムの場合は、OUTPUT_STRINGを構造体で項目のシリアル化（4.1.3）を実行した結果にします。
5. Else, fail serialization.
5. そうでなければ、シリアル化に失敗します。
6. Return output_string converted into an array of bytes, using ASCII encoding [RFC0020].
6. ASCIIエンコード[RFC0020]を使用して、OUTPUT_STRINGをバイトの配列に変換します。
Given an array of (member_value, parameters) tuples as input_list, return an ASCII string suitable for use in an HTTP field value.
input_listとして（member_value、パラメータ）タプルの配列を指定して、HTTPフィールド値での使用に適したASCII文字列を返します。
1. Let output be an empty string.
1. 出力を空の文字列にすることができます。
2. For each (member_value, parameters) of input_list:
2. input_listの各（member_value、パラメータ）について：
1. If member_value is an array, append the result of running Serializing an Inner List (Section 4.1.1.1) with (member_value, parameters) to output.
1. member_valueが配列である場合は、内部リストのシリアル化の結果（セクション4.1.1.1）を出力に出力します。
2. Otherwise, append the result of running Serializing an Item (Section 4.1.3) with (member_value, parameters) to output.
2. それ以外の場合は、出力を出力する（member_value、パラメータ）とともに、item（セクション4.1.3）を実行して実行した結果を追加します。
3. If more member_values remain in input_list:
3. もっとmember_valuesがinput_listに残っている場合：
1. Append "," to output.
1. 出力するには、「」を追加します。
2. Append a single SP to output.
2. 出力するSPを追加します。
3. Return output.
3. 出力を返します。
Given an array of (member_value, parameters) tuples as inner_list, and parameters as list_parameters, return an ASCII string suitable for use in an HTTP field value.
INVER_LISTとして（member_value、パラメータ）タプルの配列、およびlist_parametersとしてのパラメータを考えると、HTTPフィールド値での使用に適したASCII文字列を返します。
1. Let output be the string "(".
1. 出力を文字列 "（"（ "）にすることができます。
2. For each (member_value, parameters) of inner_list:
2. inner_listの各（member_value、パラメータ）について：
1. Append the result of running Serializing an Item (Section 4.1.3) with (member_value, parameters) to output.
1. 出力を出力する（member_value、パラメータ）を（セクション4.1.3）、item（セクション4.1.3）を実行して実行した結果を追加します。
2. If more values remain in inner_list, append a single SP to output.
2. より多くの値がinner_listに残っている場合は、出力に1つのSPを追加します。
3. Append ")" to output.
3. 出力するには "）"を追加してください。
4. Append the result of running Serializing Parameters (Section 4.1.1.2) with list_parameters to output.
4. 出力するLIST_PARAMETERSを使用して、シリアル化パラメータを実行した結果（4.1.1.2項）を追加します。
5. Return output.
5. 出力を返します。
Given an ordered Dictionary as input_parameters (each member having a param_key and a param_value), return an ASCII string suitable for use in an HTTP field value.
input_parameters（param_keyとparam_valueを持つ各メンバー）として順序付けられた辞書が与えられた場合は、HTTPフィールド値での使用に適したASCII文字列を返します。
1. Let output be an empty string.
1. 出力を空の文字列にすることができます。
2. For each param_key with a value of param_value in input_parameters:
2. input_parametersにparam_valueの値を持つ各param_keyについて：
1. Append ";" to output.
1. 「;」を追加する。出力する。
2. Append the result of running Serializing a Key (Section 4.1.1.3) with param_key to output.
2. 出力をPARAM_KEYに並べ替える（セクション4.1.1.3）をパラメータに実行した結果を追加します。
3. If param_value is not Boolean true:
3. param_valueがboolean trueでない場合：
1. Append "=" to output.
1. 出力するには "="を追加してください。
2. Append the result of running Serializing a bare Item (Section 4.1.3.1) with param_value to output.
2. aparam_valueを出力するように、シリアル化の結果（セクション4.1.3.1）を実行した結果を追加します。
3. Return output.
3. 出力を返します。
Given a key as input_key, return an ASCII string suitable for use in an HTTP field value.
input_keyとしてキーを指定して、HTTPフィールド値での使用に適したASCII文字列を返します。
1. Convert input_key into a sequence of ASCII characters; if conversion fails, fail serialization.
1. INPUT_KEYをASCII文字のシーケンスに変換します。変換が失敗した場合は、シリアル化に失敗します。
2. If input_key contains characters not in lcalpha, DIGIT, "_", "-", ".", or "*", fail serialization.
2. input_keyがlcalphaではなく、桁、 "_"、 " - "、 "。"、または "*"でない文字が含まれている場合は、シリアル化に失敗します。
3. If the first character of input_key is not lcalpha or "*", fail serialization.
3. input_keyの最初の文字がlcalphaまたは "*"ではない場合は、シリアル化に失敗します。
4. Let output be an empty string.
4. 出力を空の文字列にすることができます。
5. Append input_key to output.
5. 出力するINPUT_KEYを追加します。
6. Return output.
6. 出力を返します。
Given an ordered Dictionary as input_dictionary (each member having a member_key and a tuple value of (member_value, parameters)), return an ASCII string suitable for use in an HTTP field value.
input_dictionaryとして順序付けられた辞書が与えられます（Member_Keyと（member_value、parameters）のタプル値）、HTTPフィールド値での使用に適したASCII文字列を返します。
1. Let output be an empty string.
1. 出力を空の文字列にすることができます。
2. For each member_key with a value of (member_value, parameters) in input_dictionary:
2. input_dictionaryの（member_value、パラメータ）の値を持つ各member_keyについて：
1. Append the result of running Serializing a Key (Section 4.1.1.3) with member's member_key to output.
1. 出力をメンバーのmember_keyにシリアライズする結果を追加します。
2. If member_value is Boolean true:
2. member_valueがboolean trueの場合：
1. Append the result of running Serializing Parameters (Section 4.1.1.2) with parameters to output.
1. 出力するパラメータを使用して、シリアル化パラメータを実行した結果（セクション4.1.1.2）を追加します。
3. Otherwise:
3. さもないと：
1. Append "=" to output.
1. 出力するには "="を追加してください。
2. If member_value is an array, append the result of running Serializing an Inner List (Section 4.1.1.1) with (member_value, parameters) to output.
2. member_valueが配列である場合は、内部リストのシリアル化の結果（セクション4.1.1.1）を出力に出力します。
3. Otherwise, append the result of running Serializing an Item (Section 4.1.3) with (member_value, parameters) to output.
3. それ以外の場合は、出力を出力する（member_value、パラメータ）とともに、item（セクション4.1.3）を実行して実行した結果を追加します。
4. If more members remain in input_dictionary:
4. より多くのメンバーがinput_dictionaryに残っている場合
1. Append "," to output.
1. 出力するには、「」を追加します。
2. Append a single SP to output.
2. 出力するSPを追加します。
3. Return output.
3. 出力を返します。
Given an Item as bare_item and Parameters as item_parameters, return an ASCII string suitable for use in an HTTP field value.
item_parametersとしてbare_itemおよびパラメータとしてアイテムを指定した場合は、HTTPフィールド値での使用に適したASCII文字列を返します。
1. Let output be an empty string.
1. 出力を空の文字列にすることができます。
2. Append the result of running Serializing a Bare Item (Section 4.1.3.1) with bare_item to output.
2. 出力をBARE_ITEMに備えて、Bare項目（セクション4.1.3.1）を実行して実行した結果を追加します。
3. Append the result of running Serializing Parameters (Section 4.1.1.2) with item_parameters to output.
3. 出力するITEM_PARAMETERSを使用して、シリアル化パラメータ（セクション4.1.1.2）を実行した結果を追加します。
4. Return output.
4. 出力を返します。
Given an Item as input_item, return an ASCII string suitable for use in an HTTP field value.
INPUT_ITEMとして項目を指定して、HTTPフィールド値での使用に適したASCII文字列を返します。
1. If input_item is an Integer, return the result of running Serializing an Integer (Section 4.1.4) with input_item.
1. INPUT_ITEMが整数の場合は、integer（セクション4.1.4）をinput_itemで実行して実行した結果を返します。
2. If input_item is a Decimal, return the result of running Serializing a Decimal (Section 4.1.5) with input_item.
2. INPUT_ITEMが10進数の場合は、input_itemを使用して、DECIMAL（4.1.5）をraning ringして実行した結果を返します。
3. If input_item is a String, return the result of running Serializing a String (Section 4.1.6) with input_item.
3. INPUT_ITEMが文字列の場合は、input_itemに文字列のシリアル化（セクション4.1.6）を実行した結果を返します。
4. If input_item is a Token, return the result of running Serializing a Token (Section 4.1.7) with input_item.
4. input_itemがトークンの場合は、tokenのシリアル化の結果（セクション4.1.7）をinput_itemに返します。
5. If input_item is a Byte Sequence, return the result of running Serializing a Byte Sequence (Section 4.1.8) with input_item.
5. INPUT_ITEMがバイトシーケンスの場合は、INPUT_ITEMを使用して、シリアル化実行結果（セクション4.1.8）を実行します。
6. If input_item is a Boolean, return the result of running Serializing a Boolean (Section 4.1.9) with input_item.
6. INPUT_ITEMがブール値であれば、input_itemにブール値のシリアル化（セクション4.1.9）を実行した結果を返します。
7. Otherwise, fail serialization.
7. それ以外の場合は、シリアル化に失敗します。
Given an Integer as input_integer, return an ASCII string suitable for use in an HTTP field value.
input_integerとして整数を指定して、HTTPフィールド値での使用に適したASCII文字列を返します。
1. If input_integer is not an integer in the range of -999,999,999,999,999 to 999,999,999,999,999 inclusive, fail serialization.
1. INPUT_INTEGERが-999,999,999,999,999,999,999,999,999,999の範囲の整数ではない場合は、シリアル化をフェイル化します。
2. Let output be an empty string.
2. 出力を空の文字列にすることができます。
3. If input_integer is less than (but not equal to) 0, append "-" to output.
3. INPUT_INTEGERが（でも等しくない）0未満の場合は、出力に「 - 」を追加します。
4. Append input_integer's numeric value represented in base 10 using only decimal digits to output.
4. input_integerの数値を追加して、4桁の数字を出力に使用して、Base 10で表されています。
5. Return output.
5. 出力を返します。
Given a decimal number as input_decimal, return an ASCII string suitable for use in an HTTP field value.
input_decimalとして10進数を指定して、HTTPフィールド値での使用に適したASCII文字列を返します。
1. If input_decimal is not a decimal number, fail serialization.
1. input_decimalが10進数でない場合は、シリアル化に失敗します。
2. If input_decimal has more than three significant digits to the right of the decimal point, round it to three decimal places, rounding the final digit to the nearest value, or to the even value if it is equidistant.
2. input_decimalが小数点の右側に3桁を超える大きい桁数を超える場合は、小数点以下の桁数に丸めて、最後の数字を最も近い値に丸めたり、等距離である場合は偶数値です。
3. If input_decimal has more than 12 significant digits to the left of the decimal point after rounding, fail serialization.
3. input_decimalに丸め後の小数点の左側に12を超える有効な数字がある場合は、シリアル化に失敗します。
4. Let output be an empty string.
4. 出力を空の文字列にすることができます。
5. If input_decimal is less than (but not equal to) 0, append "-" to output.
5. INPUT_DECIMALが（が等しくない）0未満の場合は、出力に「 - 」を追加します。
6. Append input_decimal's integer component represented in base 10 (using only decimal digits) to output; if it is zero, append "0".
6. input_decimalの整数コンポーネントを追加して出力する（10進数のみのみを使用）。ゼロの場合は、 "0"を追加してください。
7. Append "." to output.
7. 「」を追加する。出力する。
8. If input_decimal's fractional component is zero, append "0" to output.
8. input_decimalの小数成分がゼロの場合は、出力に "0"を追加してください。
9. Otherwise, append the significant digits of input_decimal's fractional component represented in base 10 (using only decimal digits) to output.
9. それ以外の場合は、BASE 10（10進数のみを使用して）出力に表されているINPUT_DECIMALの小数成分の有効桁を追加します。
10. Return output.
10. 出力を返します。
Given a String as input_string, return an ASCII string suitable for use in an HTTP field value.
input_stringとして文字列を指定して、HTTPフィールド値での使用に適したASCII文字列を返します。
1. Convert input_string into a sequence of ASCII characters; if conversion fails, fail serialization.
1. input_stringをASCII文字のシーケンスに変換します。変換が失敗した場合は、シリアル化に失敗します。
2. If input_string contains characters in the range %x00-1f or %x7f-ff (i.e., not in VCHAR or SP), fail serialization.
2. input_stringの場合、％x00-1fまたは％x7f-ff（すなわち、VCHARまたはSPではなく）の文字が含まれている場合は、シリアル化に失敗します。
3. Let output be the string DQUOTE.
3. 出力を文字列dquoteにしましょう。
4. For each character char in input_string:
4. INPUT_STRINGの各文字の場合
1. If char is "\" or DQUOTE:
1. charが "\"またはdquoteの場合：
1. Append "\" to output.
1. 出力するには "\"を追加してください。
2. Append char to output.
2. 出力を追加します。
5. Append DQUOTE to output.
5. 出力するDQUOTEを追加します。
6. Return output.
6. 出力を返します。
Given a Token as input_token, return an ASCII string suitable for use in an HTTP field value.
input_tokenとしてトークンを指定して、HTTPフィールド値での使用に適したASCII文字列を返します。
1. Convert input_token into a sequence of ASCII characters; if conversion fails, fail serialization.
1. input_tokenをASCII文字のシーケンスに変換します。変換が失敗した場合は、シリアル化に失敗します。
2. If the first character of input_token is not ALPHA or "*", or the remaining portion contains a character not in tchar, ":", or "/", fail serialization.
2. input_tokenの最初の文字がアルファまたは "*"ではない場合、または残りの部分には、tchar、 "："、または "/"にない文字が含まれています。
3. Let output be an empty string.
3. 出力を空の文字列にすることができます。
4. Append input_token to output.
4. input_tokenを出力に追加します。
5. Return output.
5. 出力を返します。
Given a Byte Sequence as input_bytes, return an ASCII string suitable for use in an HTTP field value.
INPUT_BTESとしてバイトシーケンスを指定して、HTTPフィールド値での使用に適したASCII文字列を返します。
1. If input_bytes is not a sequence of bytes, fail serialization.
1. INPUT_BYTESが一連のバイトではない場合は、シリアル化に失敗します。
2. Let output be an empty string.
2. 出力を空の文字列にすることができます。
3. Append ":" to output.
3. 出力するには "："を追加してください。
4. Append the result of base64-encoding input_bytes as per [RFC4648], Section 4, taking account of the requirements below.
4. 下記の要件を考慮して、[RFC4648]、セクション4に従ってBase64エンコーディングINPUT_BYTESの結果を追加します。
5. Append ":" to output.
5. 出力するには "："を追加してください。
6. Return output.
6. 出力を返します。
The encoded data is required to be padded with "=", as per [RFC4648], Section 3.2.
符号化されたデータは、[RFC4648]、セクション3.2に従って、「=」で埋められる必要があります。
Likewise, encoded data SHOULD have pad bits set to zero, as per [RFC4648], Section 3.5, unless it is not possible to do so due to implementation constraints.
同様に、符号化データは、実装制約のためにそうすることが不可能でない限り、[RFC4648]、セクション3.5に従って、パッドビットがゼロに設定されるべきである。
Given a Boolean as input_boolean, return an ASCII string suitable for use in an HTTP field value.
input_booleanとしてブール値を指定して、HTTPフィールド値での使用に適したASCII文字列を返します。
1. If input_boolean is not a boolean, fail serialization.
1. input_booleanがブール値ではない場合は、シリアル化に失敗します。
2. Let output be an empty string.
2. 出力を空の文字列にすることができます。
3. Append "?" to output.
3. 追加する？出力する。
4. If input_boolean is true, append "1" to output.
4. input_booleanがtrueの場合は、出力に "1"を追加してください。
5. If input_boolean is false, append "0" to output.
5. input_booleanがfalseの場合は、出力に "0"を追加してください。
6. Return output.
6. 出力を返します。
When a receiving implementation parses HTTP fields that are known to be Structured Fields, it is important that care be taken, as there are a number of edge cases that can cause interoperability or even security problems. This section specifies the algorithm for doing so.
受信実装が構造化されたフィールドであることが知られているHTTPフィールドを解析した場合、相互運用性またはセキュリティ上の問題を引き起こす可能性があるいくつかのエッジケースがあるため、注意を払うことが重要です。このセクションは、そうするためのアルゴリズムを指定します。
Given an array of bytes as input_bytes that represent the chosen field's field-value (which is empty if that field is not present) and field_type (one of "dictionary", "list", or "item"), return the parsed header value.
選択されたフィールドのフィールド値（そのフィールドが存在しない場合は空である）およびfield_type（ "辞書"、 "list"、または "item"のいずれかの項目）を表すINPUT_BYTESとしてバイトの配列を指定した場合は、解析されたヘッダー値を返します。。
1. Convert input_bytes into an ASCII string input_string; if conversion fails, fail parsing.
1. input_btesをASCII文字列input_stringに変換します。変換が失敗した場合は、解析をフェイメントします。
2. Discard any leading SP characters from input_string.
2. INPUT_STRINGから先行のSP文字を破棄します。
3. If field_type is "list", let output be the result of running Parsing a List (Section 4.2.1) with input_string.
3. field_typeが "list"の場合は、INPUT_STRINGを使用してリストの解析（セクション4.2.1）を実行して実行した結果を出力させます。
4. If field_type is "dictionary", let output be the result of running Parsing a Dictionary (Section 4.2.2) with input_string.
4. field_typeが "Dictionary"の場合は、input_stringを使用して辞書の解析（セクション4.2.2）を実行した結果を出力させます。
5. If field_type is "item", let output be the result of running Parsing an Item (Section 4.2.3) with input_string.
5. field_typeが "item"の場合は、INPUT_STRINGを使用して項目（4.2.3節）の解析を実行した結果を出力させます。
6. Discard any leading SP characters from input_string.
6. INPUT_STRINGから先行のSP文字を破棄します。
7. If input_string is not empty, fail parsing.
7. INPUT_STRINGが空でない場合は、解析をフェイメントします。
8. Otherwise, return output.
8. それ以外の場合は、出力を返します。
When generating input_bytes, parsers MUST combine all field lines in the same section (header or trailer) that case-insensitively match the field name into one comma-separated field-value, as per [RFC7230], Section 3.2.2; this assures that the entire field value is processed correctly.
INPUT_BYTESを生成するとき、パーサーは、ケースのすべてのフィールド行（ヘッダーまたはトレーラー）内のすべてのフィールド行を組み合わせて、フィールド名を、[RFC7230]、セクション3.2.2に従って、1つのコンマ区切りのフィールド値に区別する必要があります。これは、フィールド値全体が正しく処理されることを保証します。
For Lists and Dictionaries, this has the effect of correctly concatenating all of the field's lines, as long as individual members of the top-level data structure are not split across multiple header instances. The parsing algorithms for both types allow tab characters, since these might be used to combine field lines by some implementations.
リストと辞書の場合、最上位データ構造の個々のメンバーが複数のヘッダーインスタンスに分割されていない限り、これはすべてのフィールドの行を正確に連結するという効果があります。両方のタイプの解析アルゴリズムは、これらの実装によってフィールドラインを組み合わせるために使用される可能性があるため、タブ文字を使用できます。
Strings split across multiple field lines will have unpredictable results, because one or more commas (with optional whitespace) will become part of the string output by the parser. Since concatenation might be done by an upstream intermediary, the results are not under the control of the serializer or the parser, even when they are both under the control of the same party.
1つ以上のカンマ（オプションの空白を持つ）がパーサーによって出力された文字列の一部になるため、複数のフィールドラインに分割された文字列は予測不可能な結果になります。連結は上流の仲介者によって行われる可能性があるので、それらが同じパーティーの制御下にあるときでさえ、結果はシリアライザまたはパーサーの制御下にはありません。
Tokens, Integers, Decimals, and Byte Sequences cannot be split across multiple field lines because the inserted commas will cause parsing to fail.
トークン、整数、デシミュール、およびバイトシーケンスは、挿入されたコンマが解決する原因となるため、複数のフィールドラインに分割できません。
Parsers MAY fail when processing a field value spread across multiple field lines, when one of those lines does not parse as that field. For example, a parsing handling an Example-String field that's defined as an sf-string is allowed to fail when processing this field section:
これらの線の1つがそのフィールドとして解析されない場合、フィールド値を複数のフィールドラインにわたって処理するときにパーサーが失敗することがあります。たとえば、このフィールドセクションを処理するときにSF文字列として定義されている例Stringフィールドを解析することができます。
Example-String: "foo Example-String: bar"
例 - 文字列： "foo例 - 文字列：bar"
If parsing fails -- including when calling another algorithm -- the entire field value MUST be ignored (i.e., treated as if the field were not present in the section). This is intentionally strict, to improve interoperability and safety, and specifications referencing this document are not allowed to loosen this requirement.
解析が失敗した場合 - 別のアルゴリズムを呼び出すとき - フィールド値全体は無視されなければならない（すなわち、フィールドがセクションに存在しなかった場合のように扱われる）。これは意図的に相互運用性と安全性を向上させるために、この文書を参照する仕様はこの要件を緩めることはできません。
Note that this requirement does not apply to an implementation that is not parsing the field; for example, an intermediary is not required to strip a failing field from a message before forwarding it.
この要件は、フィールドを解析していない実装には適用されません。たとえば、仲介者は、それを転送する前にメッセージから失敗したフィールドを削除する必要はありません。
Given an ASCII string as input_string, return an array of (item_or_inner_list, parameters) tuples. input_string is modified to remove the parsed value.
input_stringとしてASCII文字列を指定して、（item_or_inner_list、パラメータ）タプルの配列を返します。input_stringは解析値を削除するように変更されます。
1. Let members be an empty array.
1. メンバーを空の配列にしましょう。
2. While input_string is not empty:
2. input_stringは空ではありません。
1. Append the result of running Parsing an Item or Inner List (Section 4.2.1.1) with input_string to members.
1. INPUT_STRINGをinput_stringにinput_stringをメンバーに解析した結果を実行した結果を追加します。
2. Discard any leading OWS characters from input_string.
2. INPUT_STRINGから先頭のOWE文字を破棄します。
3. If input_string is empty, return members.
3. input_stringが空の場合は、メンバーを返します。
4. Consume the first character of input_string; if it is not ",", fail parsing.
4. input_stringの最初の文字を消費します。それが「」ではない場合は、解析に失敗します。
5. Discard any leading OWS characters from input_string.
5. INPUT_STRINGから先頭のOWE文字を破棄します。
6. If input_string is empty, there is a trailing comma; fail parsing.
6. input_stringが空の場合、末尾のコンマがあります。解析解析
3. No structured data has been found; return members (which is empty).
3. 構造化データは見つかりませんでした。リターンメンバー（これは空です）。
Given an ASCII string as input_string, return the tuple (item_or_inner_list, parameters), where item_or_inner_list can be either a single bare item or an array of (bare_item, parameters) tuples. input_string is modified to remove the parsed value.
input_stringとしてASCII文字列を指定して、Tuple（item_or_INNER_LIST、パラメータ）を返します。ここで、ITEM_OR_INNER_LISTは単一の裸の項目または（BARE_ITEM、パラメータ）タプルの配列にすることができます。input_stringは解析値を削除するように変更されます。
1. If the first character of input_string is "(", return the result of running Parsing an Inner List (Section 4.2.1.2) with input_string.
1. input_stringの最初の文字が "（"（ "（"（ "）の場合は、input_stringで内部リスト（セクション4.2.1.2）の解析結果を返します。
2. Return the result of running Parsing an Item (Section 4.2.3) with input_string.
2. INPUT_STRINGを使用して、アイテムの解析（4.2.3）を実行した結果を返します。
Given an ASCII string as input_string, return the tuple (inner_list, parameters), where inner_list is an array of (bare_item, parameters) tuples. input_string is modified to remove the parsed value.
input_stringとしてASCII文字列を指定すると、Tuple（Inner_list、Parameters）を返します。ここで、inner_listは（bare_item、パラメータ）タプルの配列です。input_stringは解析値を削除するように変更されます。
1. Consume the first character of input_string; if it is not "(", fail parsing.
1. input_stringの最初の文字を消費します。そうでない場合は「解析に失敗します。
2. Let inner_list be an empty array.
2. inner_listを空の配列にしましょう。
3. While input_string is not empty:
3. input_stringは空ではありません。
1. Discard any leading SP characters from input_string.
1. INPUT_STRINGから先行のSP文字を破棄します。
2. If the first character of input_string is ")":
2. input_stringの最初の文字が "）"の場合）
1. Consume the first character of input_string.
1. input_stringの最初の文字を消費します。
2. Let parameters be the result of running Parsing Parameters (Section 4.2.3.2) with input_string.
2. PARATCHE_STRINGを使用して、解析パラメータ（セクション4.2.3.2）を実行した結果になります。
3. Return the tuple (inner_list, parameters).
3. タプル（INNER_LIST、パラメータ）を返します。
3. Let item be the result of running Parsing an Item (Section 4.2.3) with input_string.
3. INPUT_STRINGで項目（4.2.3節）の解析を実行した結果を項目にします。
4. Append item to inner_list.
4. Inner_listにアイテムを追加します。
5. If the first character of input_string is not SP or ")", fail parsing.
5. 入力文字列の最初の文字がそうでない、または「）」でない場合は、解析を解除してください。
4. The end of the Inner List was not found; fail parsing.
4. 内側リストの終わりが見つかりませんでした。解析解析
Given an ASCII string as input_string, return an ordered map whose values are (item_or_inner_list, parameters) tuples. input_string is modified to remove the parsed value.
input_stringとしてASCII文字列を指定して、値が（item_or_inner_list、パラメータ）タプルの順序付けマップを返します。input_stringは解析値を削除するように変更されます。
1. Let dictionary be an empty, ordered map.
1. 辞書を空の注文マップにしましょう。
2. While input_string is not empty:
2. input_stringは空ではありません。
1. Let this_key be the result of running Parsing a Key (Section 4.2.3.3) with input_string.
1. this_keyをinput_stringでキーの解析（セクション4.2.3.3）を実行した結果になりましょう。
2. If the first character of input_string is "=":
2. input_stringの最初の文字が "="の場合：
1. Consume the first character of input_string.
1. input_stringの最初の文字を消費します。
2. Let member be the result of running Parsing an Item or Inner List (Section 4.2.1.1) with input_string.
2. INPUT_STRINGを使用して、項目または内部リスト（セクション4.2.1.1）の解析を実行した結果をメンバーにしましょう。
3. Otherwise:
3. さもないと：
1. Let value be Boolean true.
1. 値をBoolean Trueにしましょう。
2. Let parameters be the result of running Parsing Parameters (Section 4.2.3.2) with input_string.
2. PARATCHE_STRINGを使用して、解析パラメータ（セクション4.2.3.2）を実行した結果になります。
3. Let member be the tuple (value, parameters).
3. メンバーをタプル（値、パラメーター）にしましょう。
4. If dictionary already contains a key this_key (comparing character for character), overwrite its value with member.
4. 辞書に既にkey this_key（文字の比較）が含まれている場合は、その値をメンバーで上書きしてください。
5. Otherwise, append key this_key with value member to dictionary.
5. それ以外の場合は、key this_keyを辞書に付加して付加してください。
6. Discard any leading OWS characters from input_string.
6. INPUT_STRINGから先頭のOWE文字を破棄します。
7. If input_string is empty, return dictionary.
7. input_stringが空の場合は、辞書を返します。
8. Consume the first character of input_string; if it is not ",", fail parsing.
8. input_stringの最初の文字を消費します。それが「」ではない場合は、解析に失敗します。
9. Discard any leading OWS characters from input_string.
9. INPUT_STRINGから先頭のOWE文字を破棄します。
10. If input_string is empty, there is a trailing comma; fail parsing.
10. input_stringが空の場合、末尾のコンマがあります。解析解析
3. No structured data has been found; return dictionary (which is empty).
3. 構造化データは見つかりませんでした。戻り辞書（これは空です）。
Note that when duplicate Dictionary keys are encountered, all but the last instance are ignored.
辞書キーが重複している場合、最後のインスタンスはすべて無視されます。
Given an ASCII string as input_string, return a (bare_item, parameters) tuple. input_string is modified to remove the parsed value.
input_stringとしてASCII文字列を指定すると、（bare_item、パラメータ）タプルを返します。input_stringは解析値を削除するように変更されます。
1. Let bare_item be the result of running Parsing a Bare Item (Section 4.2.3.1) with input_string.
1. input_stringを使用して、Bare項目（セクション4.2.3.1）の構文解析の結果にBARE_ITEMを使用します。
2. Let parameters be the result of running Parsing Parameters (Section 4.2.3.2) with input_string.
2. PARATCHE_STRINGを使用して、解析パラメータ（セクション4.2.3.2）を実行した結果になります。
3. Return the tuple (bare_item, parameters).
3. タプル（BARE_ITEM、パラメータ）を返します。
Given an ASCII string as input_string, return a bare Item. input_string is modified to remove the parsed value.
input_stringとしてASCII文字列を指定して、裸の項目を返します。input_stringは解析値を削除するように変更されます。
1. If the first character of input_string is a "-" or a DIGIT, return the result of running Parsing an Integer or Decimal (Section 4.2.4) with input_string.
1. input_stringの最初の文字が " - "または数字である場合は、intecterまたはdecimal（セクション4.2.4）をinput_stringに解析して実行する結果を返します。
2. If the first character of input_string is a DQUOTE, return the result of running Parsing a String (Section 4.2.5) with input_string.
2. INPUT_STRINGの最初の文字がDQUOTEである場合は、input_stringを使用して文字列（セクション4.2.5）の解析結果を返します。
3. If the first character of input_string is an ALPHA or "*", return the result of running Parsing a Token (Section 4.2.6) with input_string.
3. INPUT_STRINGの最初の文字がアルファまたは「*」の場合は、input_stringにトークンの解析（セクション4.2.6）を実行して実行した結果を返します。
4. If the first character of input_string is ":", return the result of running Parsing a Byte Sequence (Section 4.2.7) with input_string.
4. INPUT_STRINGの最初の文字が "："の場合は、input_stringを使用して、バイトシーケンス（セクション4.2.7）の構文解析結果を返します。
5. If the first character of input_string is "?", return the result of running Parsing a Boolean (Section 4.2.8) with input_string.
5. INPUT_STRINGの最初の文字が「？」の場合は、input_stringを使用して、ブール値（セクション4.2.8）の解析結果を返します。
6. Otherwise, the item type is unrecognized; fail parsing.
6. それ以外の場合、アイテムタイプは認識されません。解析解析
Given an ASCII string as input_string, return an ordered map whose values are bare Items. input_string is modified to remove the parsed value.
INPUT_STRINGとしてASCII文字列を指定して、値が裸の項目である順序付けされたマップを返します。input_stringは解析値を削除するように変更されます。
1. Let parameters be an empty, ordered map.
1. パラメータを空の順序付けられたマップにしましょう。
2. While input_string is not empty:
2. input_stringは空ではありません。
1. If the first character of input_string is not ";", exit the loop.
1. input_stringの最初の文字が ";"ではない場合は、ループを終了します。
2. Consume the ";" character from the beginning of input_string.
2. 「;」を消費するinput_stringの先頭からの文字。
3. Discard any leading SP characters from input_string.
3. INPUT_STRINGから先行のSP文字を破棄します。
4. Let param_key be the result of running Parsing a Key (Section 4.2.3.3) with input_string.
4. param_keyをinput_stringを使用してキー（セクション4.2.3.3）の解析を実行した結果になりましょう。
5. Let param_value be Boolean true.
5. param_valueをBoolean Trueにすることができます。
6. If the first character of input_string is "=":
6. input_stringの最初の文字が "="の場合：
1. Consume the "=" character at the beginning of input_string.
1. input_stringの始めに "="文字を消費します。
2. Let param_value be the result of running Parsing a Bare Item (Section 4.2.3.1) with input_string.
2. param_valueをinput_stringで裸項目（セクション4.2.3.1）の解析を実行した結果にします。
7. If parameters already contains a key param_key (comparing character for character), overwrite its value with param_value.
7. パラメータに既にキーPARAM_KEY（文字の比較）が含まれている場合は、その値をparam_valueで上書きしてください。
8. Otherwise, append key param_key with value param_value to parameters.
8. それ以外の場合は、パラメータに値param_valueを持つキーparam_keyを追加します。
3. Return parameters.
3. 戻りパラメータ。
Note that when duplicate parameter keys are encountered, all but the last instance are ignored.
重複パラメータキーが検出されたときは、最後のインスタンスがすべて無視されます。
Given an ASCII string as input_string, return a key. input_string is modified to remove the parsed value.
input_stringとしてASCII文字列を指定して、キーを返します。input_stringは解析値を削除するように変更されます。
1. If the first character of input_string is not lcalpha or "*", fail parsing.
1. INPUT_STRINGの最初の文字がLCALPHAまたは「*」ではない場合は、解析をフェイメントします。
2. Let output_string be an empty string.
2. output_stringを空の文字列にすることができます。
3. While input_string is not empty:
3. input_stringは空ではありません。
1. If the first character of input_string is not one of lcalpha, DIGIT, "_", "-", ".", or "*", return output_string.
1. INPUT_STRINGの最初の文字がLCALPHA、桁、 "_"、 " - "、 "。"、 "*"の1つではない場合、 "*"、 "*"、output_stringを返します。
2. Let char be the result of consuming the first character of input_string.
2. INPUT_STRINGの最初の文字を消費した結果をCHARにしましょう。
3. Append char to output_string.
3. char pounts_stringを追加します。
4. Return output_string.
4. output_stringを返します。
Given an ASCII string as input_string, return an Integer or Decimal. input_string is modified to remove the parsed value.
input_stringとしてASCII文字列を指定すると、整数または10進数を返します。input_stringは解析値を削除するように変更されます。
NOTE: This algorithm parses both Integers (Section 3.3.1) and Decimals (Section 3.3.2), and returns the corresponding structure.
注：このアルゴリズムは、整数（セクション3.3.1）と小数点（セクション3.3.2）の両方を解析し、対応する構造を返します。
1. Let type be "integer".
1. タイプを "整数"にしましょう。
2. Let sign be 1.
2. 符号を1にしましょう。
3. Let input_number be an empty string.
3. input_numberを空の文字列にすることができます。
4. If the first character of input_string is "-", consume it and set sign to -1.
4. input_stringの最初の文字が " - "の場合は、それを消費して-1を設定します。
5. If input_string is empty, there is an empty integer; fail parsing.
5. input_stringが空の場合、空の整数があります。解析解析
6. If the first character of input_string is not a DIGIT, fail parsing.
6. INPUT_STRINGの最初の文字が桁ではない場合は、解析を失敗させます。
7. While input_string is not empty:
7. input_stringは空ではありません。
1. Let char be the result of consuming the first character of input_string.
1. INPUT_STRINGの最初の文字を消費した結果をCHARにしましょう。
2. If char is a DIGIT, append it to input_number.
2. charが数字の場合は、INPUT_NUMBERに追加してください。
3. Else, if type is "integer" and char is ".":
3. そうでなければ、Typeが "integer"の場合は "。"です。
1. If input_number contains more than 12 characters, fail parsing.
1. input_numberに12文字を超える文字が含まれている場合は、解析に失敗します。
2. Otherwise, append char to input_number and set type to "decimal".
2. それ以外の場合は、CHARをinput_numberに追加し、タイプを「10進」に設定します。
4. Otherwise, prepend char to input_string, and exit the loop.
4. それ以外の場合は、input_stringにcharを追加し、ループを終了します。
5. If type is "integer" and input_number contains more than 15 characters, fail parsing.
5. typeが "integer"とinput_numberに15文字を超える場合は、解析をフェイメントします。
6. If type is "decimal" and input_number contains more than 16 characters, fail parsing.
6. typeが "Decimal"とInput_numberの場合は16文字を超える場合は、解析が解決します。
8. If type is "integer":
8. typeが "整数"の場合：
1. Parse input_number as an integer and let output_number be the product of the result and sign.
1. input_numberを整数として解析し、output_numberを結果と符号の積にすることができます。
9. Otherwise:
9. さもないと：
1. If the final character of input_number is ".", fail parsing.
1. input_numberの最後の文字が "。"の場合は解析に失敗します。
2. If the number of characters after "." in input_number is greater than three, fail parsing.
2. 「」の後の文字数があればinput_numberでは3より大きい、解析解析が失敗します。
3. Parse input_number as a decimal number and let output_number be the product of the result and sign.
3. input_numberを10進数として解析し、output_numberを結果と符号の積にすることができます。
10. Return output_number.
10. output_numberを返します。
Given an ASCII string as input_string, return an unquoted String. input_string is modified to remove the parsed value.
input_stringとしてASCII文字列を指定して、引用符で囲まれていない文字列を返します。input_stringは解析値を削除するように変更されます。
1. Let output_string be an empty string.
1. output_stringを空の文字列にすることができます。
2. If the first character of input_string is not DQUOTE, fail parsing.
2. INPUT_STRINGの最初の文字がDQUOTEでない場合は、解析を失敗させます。
3. Discard the first character of input_string.
3. INPUT_STRINGの最初の文字を破棄します。
4. While input_string is not empty:
4. input_stringは空ではありません。
1. Let char be the result of consuming the first character of input_string.
1. INPUT_STRINGの最初の文字を消費した結果をCHARにしましょう。
2. If char is a backslash ("\"):
2. charがバックスラッシュの場合（ "\"）：
1. If input_string is now empty, fail parsing.
1. INPUT_STRINGが空の場合は、解析をフェイメントします。
2. Let next_char be the result of consuming the first character of input_string.
2. next_charnet_stringの最初の文字を消費した結果になりましょう。
3. If next_char is not DQUOTE or "\", fail parsing.
3. NEXT_CHARがDQUOTEまたは「\」でない場合は、解析を失敗させます。
4. Append next_char to output_string.
4. OUTPUT_STRINGにNEXT_CHARを追加します。
3. Else, if char is DQUOTE, return output_string.
3. そうでなければ、charがdquoteの場合は、output_stringを返します。
4. Else, if char is in the range %x00-1f or %x7f-ff (i.e., it is not in VCHAR or SP), fail parsing.
4. そうでなければ、charが％x00-1fまたは％x7f-ffの範囲内にある場合（すなわち、それはvcharまたはspではなく）、解析を失敗させる。
5. Else, append char to output_string.
5. そうでなければ、char foutp_stringを追加します。
5. Reached the end of input_string without finding a closing DQUOTE; fail parsing.
5. 閉鎖DQUOTEを見つけることなくinput_stringの終わりに達しました。解析解析
Given an ASCII string as input_string, return a Token. input_string is modified to remove the parsed value.
input_stringとしてASCII文字列を指定して、トークンを返します。input_stringは解析値を削除するように変更されます。
1. If the first character of input_string is not ALPHA or "*", fail parsing.
1. INPUT_STRINGの最初の文字がアルファまたは「*」ではない場合は、解析をフェイメントします。
2. Let output_string be an empty string.
2. output_stringを空の文字列にすることができます。
3. While input_string is not empty:
3. input_stringは空ではありません。
1. If the first character of input_string is not in tchar, ":", or "/", return output_string.
1. INPUT_STRINGの最初の文字がTCHAR、 "："、または "/"になっていない場合は、output_stringを返します。
2. Let char be the result of consuming the first character of input_string.
2. INPUT_STRINGの最初の文字を消費した結果をCHARにしましょう。
3. Append char to output_string.
3. char pounts_stringを追加します。
4. Return output_string.
4. output_stringを返します。
Given an ASCII string as input_string, return a Byte Sequence. input_string is modified to remove the parsed value.
input_stringとしてASCII文字列を指定して、バイトシーケンスを返します。input_stringは解析値を削除するように変更されます。
1. If the first character of input_string is not ":", fail parsing.
1. INPUT_STRINGの最初の文字が "："ではない場合は、解析をフェイメントします。
2. Discard the first character of input_string.
2. INPUT_STRINGの最初の文字を破棄します。
3. If there is not a ":" character before the end of input_string, fail parsing.
3. INPUT_STRINGの終了前に "："文字がない場合は、解析をフェイメントします。
4. Let b64_content be the result of consuming content of input_string up to but not including the first instance of the character ":".
4. B64_Contentを、文字の最初のインスタンスを最大限に引き出すが、INPUT_STRINGのコンテンツを消費した結果にすることができます。
5. Consume the ":" character at the beginning of input_string.
5. input_stringの始めに "："文字を消費します。
6. If b64_content contains a character not included in ALPHA, DIGIT, "+", "/", and "=", fail parsing.
6. B64_Contentにアルファ、桁、 ""、 "/"、 "="に含まれていない文字が含まれている場合は、解析をフェイメントします。
7. Let binary_content be the result of base64-decoding [RFC4648] b64_content, synthesizing padding if necessary (note the requirements about recipient behavior below). If base64 decoding fails, parsing fails.
7. basinar_contentをbase64-decoding [RFC4648] B64_Contentの結果になります。必要に応じてパディングを合成します（以下の受信機の動作に関する要件に注意してください）。base64デコードが失敗した場合、解析は失敗します。
8. Return binary_content.
8. binary_contentを返します。
Because some implementations of base64 do not allow rejection of encoded data that is not properly "=" padded (see [RFC4648], Section 3.2), parsers SHOULD NOT fail when "=" padding is not present, unless they cannot be configured to do so.
base64の実装によっては、正しく "=" paddedしていない符号化データの拒否を許可しない（[RFC4648]、セクション3.2を参照）、「=」パディングが存在しない場合はパーサは故障しないでください。そう。
Because some implementations of base64 do not allow rejection of encoded data that has non-zero pad bits (see [RFC4648], Section 3.5), parsers SHOULD NOT fail when non-zero pad bits are present, unless they cannot be configured to do so.
Base64の実装によっては、ゼロ以外のパッドビットを持つ符号化データの拒否を許可しない（[RFC4648]、セクション3.5を参照）、ゼロ以外のパッドビットが存在しない場合はパーサーは失敗しないでください。。
This specification does not relax the requirements in [RFC4648], Sections 3.1 and 3.3; therefore, parsers MUST fail on characters outside the base64 alphabet and on line feeds in encoded data.
この仕様では、[RFC4648]、セクション3.1および3.3の要件は緩和されません。したがって、パーサーは、Base64のアルファベットの外側の文字と符号化データ内の線フィードで失敗する必要があります。
Given an ASCII string as input_string, return a Boolean. input_string is modified to remove the parsed value.
input_stringとしてASCII文字列を指定して、ブール値を返します。input_stringは解析値を削除するように変更されます。
1. If the first character of input_string is not "?", fail parsing.
1. INPUT_STRINGの最初の文字が「？」ではない場合は、解析をフェイメントします。
2. Discard the first character of input_string.
2. INPUT_STRINGの最初の文字を破棄します。
3. If the first character of input_string matches "1", discard the first character, and return true.
3. input_stringの最初の文字が "1"と一致する場合は、最初の文字を破棄してtrueを返します。
4. If the first character of input_string matches "0", discard the first character, and return false.
4. input_stringの最初の文字が "0"と一致する場合は、最初の文字を破棄してfalseを返します。
5. No value has matched; fail parsing.
5. 値が一致しませんでした。解析解析
This document has no IANA actions.
この文書にはIANAの行動がありません。
The size of most types defined by Structured Fields is not limited; as a result, extremely large fields could be an attack vector (e.g., for resource consumption). Most HTTP implementations limit the sizes of individual fields as well as the overall header or trailer section size to mitigate such attacks.
構造化フィールドで定義されたほとんどの型のサイズは制限されていません。その結果、非常に大きなフィールドは攻撃ベクトル（例えば、リソース消費のために）であり得る。ほとんどのHTTP実装は、個々のフィールドのサイズと、そのような攻撃を軽減するための全体的なヘッダーまたはトレーラーのセクションのサイズを制限します。
It is possible for parties with the ability to inject new HTTP fields to change the meaning of a Structured Field. In some circumstances, this will cause parsing to fail, but it is not possible to reliably fail in all such circumstances.
構造化フィールドの意味を変更するために新しいHTTPフィールドを注入する機能を持つパーティーが可能です。状況によっては、これにより解析が失敗するため、そのような状況すべてで確実に失敗することは不可能です。
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <https://www.rfc-editor.org/info/rfc20>.
[RFC0020] CERF、V.、ネットワークインターチェンジの「ASCIIフォーマット」、STD 80、RFC 20、DOI 10.17487 / RFC0020、<https：//www.rfc-editor.org/info/rfc20>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<https：//www.rfc-editor.org/info/rfc4648>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D.、ED。2008年1月、<https://www.rfc-editor.org/info/rfc-editor.org/info/rfc- editor.org/info/rfc523,2008、<https://www.rfc-editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc5234>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールド、R.、ED。J.Reschke、ED。、「Hypertext Transfer Protocol（HTTP / 1.1）：メッセージ構文とルーティング」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<https：//www.rfc-editor.org/info/RFC7230>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", DOI 10.1109/IEEESTD.2019.8766229, IEEE 754-2019, July 2019, <https://ieeexplore.ieee.org/document/8766229>.
[IEEE754] IEEE、「浮動小数点演算のためのIEEE規格」、DOI 10.1109 / IEEESTD.2019.8766229、2019年7月、<https：//ieeexplore.ieee.org/document/8766229>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231] Fielding、R.、Ed。J. Reschke、ED。、「Hypertext Transfer Protocol（HTTP / 1.1）：セマンティクスとコンテンツ」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<https://www.rfc-editor.org/info/rfc7231>。
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, <https://www.rfc-editor.org/info/rfc7493>.
[RFC7493] Bray、T.、Ed。、「I-JSONメッセージフォーマット」、RFC 7493、DOI 10.17487 / RFC7493、2015年3月、<https：//www.rfc-editor.org/info/rfc7493>。
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <https://www.rfc-editor.org/info/rfc7540>.
[RFC7540] Belshe、M.、Peon、R.およびM.Thomson、Ed。、「Hypertext Transfer Protocol Version 2（HTTP / 2）」、RFC 7540、DOI 10.17487 / RFC7540、2015年5月、<https：//www.rfc-editor.org/info/rfc7540>。
[RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, <https://www.rfc-editor.org/info/rfc7541>.
[RFC7541] Peon、R.およびH. Ruellan、「HTPACK：ヘッダー圧縮、RFC 7541、DOI 10.17487 / RFC7541、2015年5月、<https：//www.rfc-editor.org/info/rfc7541>。
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259] Bray、T.、ED。、「JavaScriptオブジェクト表記（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<https：//www.rfc-editor.org/ info / rfc8259>。
[STD63] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003, <https://www.rfc-editor.org/info/std63>.
[STD63] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月、<https://www.rfc-editor.org/info/std63>。
Earlier proposals for Structured Fields were based upon JSON [RFC8259]. However, constraining its use to make it suitable for HTTP header fields required senders and recipients to implement specific additional handling.
構造化フィールドの以前の提案はJSON [RFC8259]に基づいていました。ただし、HTTPヘッダーフィールドに適しているために使用すると、送信者や受信者が特定の追加処理を実装する必要がありました。
For example, JSON has specification issues around large numbers and objects with duplicate members. Although advice for avoiding these issues is available (e.g., [RFC7493]), it cannot be relied upon.
たとえば、JSONには、重複したメンバーを持つ大量およびオブジェクトの周囲の仕様の問題があります。これらの問題を回避するためのアドバイスが利用可能であるが（例えば、[RFC7493]）、それに頼ることはできない。
Likewise, JSON strings are by default Unicode strings, which have a number of potential interoperability issues (e.g., in comparison). Although implementers can be advised to avoid non-ASCII content where unnecessary, this is difficult to enforce.
同様に、JSON文字列は、デフォルトのUnicode文字列であり、これは多数の潜在的な相互運用性の問題を有する（例えば、比較で）。実装者は不要な非ASCIIコンテンツを回避することをお勧めしますが、これは強制するのが難しいです。
Another example is JSON's ability to nest content to arbitrary depths. Since the resulting memory commitment might be unsuitable (e.g., in embedded and other limited server deployments), it's necessary to limit it in some fashion; however, existing JSON implementations have no such limits, and even if a limit is specified, it's likely that some field definition will find a need to violate it.
もう1つの例は、任意の深さにコンテンツをネストするJSONの機能です。結果として生じるメモリコミットメントは不適切であるかもしれない（例えば、埋め込みおよび他の限られたサーバ展開で）、それをいくつかの方法で制限することが必要である。ただし、既存のJSON実装にはそのような制限はありません。限界が指定されていても、あるフィールド定義に違反する必要があると思われる可能性があります。
Because of JSON's broad adoption and implementation, it is difficult to impose such additional constraints across all implementations; some deployments would fail to enforce them, thereby harming interoperability. In short, if it looks like JSON, people will be tempted to use a JSON parser/serializer on field values.
JSONの幅広い採用と実装のために、すべての実装にわたってそのような追加の制約を課すことは困難です。いくつかの展開はそれらを強制することができず、それによって相互運用性を損なうでしょう。要するに、それがJSONのように見えるならば、人々はフィールド値にJSONパーサー/シリアライザを使うように誘惑されます。
Since a major goal for Structured Fields is to improve interoperability and simplify implementation, these concerns led to a format that requires a dedicated parser and serializer.
構造化されたフィールドに対する主な目標は相互運用性を向上させ、実装を単純化することであるので、これらの懸念は専用のパーサとシリアライザを必要とするフォーマットをもたらしました。
Additionally, there were widely shared feelings that JSON doesn't "look right" in HTTP fields.
さらに、JSONがHTTPフィールドで「正しい」とは限らないという広く共有された感情がありました。
A generic implementation of this specification should expose the top-level serialize (Section 4.1) and parse (Section 4.2) functions. They need not be functions; for example, it could be implemented as an object, with methods for each of the different top-level types.
この仕様の一般的な実装は、最上位のシリアル化（セクション4.1）とPARSE（4.2）関数を公開する必要があります。彼らは機能する必要はありません。たとえば、それはオブジェクトとして実装され、それぞれの異なる最上位タイプのメソッドを使用することができます。
For interoperability, it's important that generic implementations be complete and follow the algorithms closely; see Section 1.1. To aid this, a common test suite is being maintained by the community at <https://github.com/httpwg/structured-field-tests>.
相互運用性のためには、一般的な実装が完了し、アルゴリズムに密接に従うことが重要です。1.1を参照してください。これを助けるために、一般的なテストスイートは<https://github.com/httpwg/Structured-Field-tests>でコミュニティによって維持されています。
Implementers should note that Dictionaries and Parameters are order-preserving maps. Some fields may not convey meaning in the ordering of these data types, but it should still be exposed so that it will be available to applications that need to use it.
実装者は、辞書とパラメータが注文保存マップであることに注意してください。一部のフィールドは、これらのデータ型の順序で意味を伝えることはできませんが、それを使用する必要があるアプリケーションで利用できるように、それを公開する必要があります。
Likewise, implementations should note that it's important to preserve the distinction between Tokens and Strings. While most programming languages have native types that map to the other types well, it may be necessary to create a wrapper "token" object or use a parameter on functions to assure that these types remain separate.
同様に、実装は、トークンと文字列の区別を保存することが重要であることに注意してください。ほとんどのプログラミング言語は、他のタイプによくマッピングされているネイティブ型を持っていますが、ラッパー "トークン"オブジェクトを作成するか、関数にパラメータを使用してこれらの型が別々のままであることを保証する必要があるかもしれません。
The serialization algorithm is defined in a way that it is not strictly limited to the data types defined in Section 3 in every case. For example, Decimals are designed to take broader input and round to allowed values.
シリアル化アルゴリズムは、すべての場合でセクション3で定義されているデータ型に厳密に制限されていないように定義されています。たとえば、小数点以下は、より広い入力とラウンドを許可された値にかかるように設計されています。
Implementations are allowed to limit the size of different structures, subject to the minimums defined for each type. When a structure exceeds an implementation limit, that structure fails parsing or serialization.
実装は、各タイプに対して定義された最小値を条件として、さまざまな構造のサイズを制限することができます。構造が実装制限を超えると、その構造は解析またはシリアル化に失敗します。
Acknowledgements
謝辞
Many thanks to Matthew Kerwin for his detailed feedback and careful consideration during the development of this specification.
この仕様書の開発中に、彼の詳細なフィードバックと慎重な検討のために、マシュー・ケルインに感謝します。
Thanks also to Ian Clelland, Roy Fielding, Anne van Kesteren, Kazuho Oku, Evert Pot, Julian Reschke, Martin Thomson, Mike West, and Jeffrey Yasskin for their contributions.
Ian Clelland、Roy Fielding、Anna van Kesteren、Julian Reschke、Martin Thomson、Mike West、Jeffrey Yasskinなど、貢献のためにもあります。
Authors' Addresses
著者の住所
Mark Nottingham Fastly Prahran VIC Australia
Mark Nottingham Fastly Prahran Vic Australia
Email: mnot@mnot.net
URI: https://www.mnot.net/
Poul-Henning Kamp The Varnish Cache Project
Poul-Henning Kampニスキャッシュプロジェクト
Email: phk@varnish-cache.org