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ヘッダーおよびトレーラーフィールドは「Structured Fields」「Structured Headers」または「Structured Trailers」として知られています。 新しいHTTPフィールドの仕様として使われることを意図しています。従来のHTTPフィールドの値よりも制限が多く共通の構文を使用したい場合に使用されます。
This is an Internet Standards Track document.
これはインターネット標準化団体（Internet Standards Track）の文章です。
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 (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
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）に従うものとします。 これらの文書は、この文書に関するあなたの権利と制限を記述しているので、注意深く確認してください。 この文書から抽出されたコードコンポーネントには、信託の法的規定のセクション4.eに記載されているように、 簡易BSDライセンステキストを含める必要があります。簡易BSDライセンスに記載されているように、保証なしに提供されます。
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ヘッダー（とトレーラー）フィールドの構文を指定するのは大変な作業です。 [RFC7231]のSection 8.3.1 のガイダンスがあったとしても、 これからHTTPフィールドを作ろうとする人にとっては多くの決定事項や落とし穴があります。
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 3 defines a number of abstract data types that can be used in Structured Fields.
Section 3 は、構造化フィールドで使用できる多くの抽象的なデータ型を定義しています。
Those abstract types can be serialized into and parsed from HTTP field values using the algorithms described in Section 4.
これらの抽象型は、Section 4 で説明されているアルゴリズムを使って、HTTP フィールド値にシリアライズしたり、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）」、「推奨されません（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].
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フィールドからパースする場合、 実装はアルゴリズムに従ったものと区別できない動作をしなければなりません(MUST)。 解析アルゴリズムと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はそれらの期待されるワイヤー表現を例示し、アルゴリズムはそれらを生成する推奨方法を定義します。 Section 4.2 で説明されている解析アルゴリズムによって出力が正しく処理される限り、実装は指定された動作から変化してもよいです（MAY）。
To specify an HTTP field as a Structured Field, its authors need to:
HTTP フィールドを Structured Field として指定するために、その作者は以下のことを行う必要があります。
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」で始まる文字列や、小文字の文字列のみを許可するかもしれません。 同様に、内部リスト(Section 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.
パースに失敗すると、フィールド全体が無視されます（Section 4.2 参照）。 ほとんどの状況で、フィールド固有の制約に違反しても同じ効果があります。 したがって、ヘッダーがアイテムとして定義され、整数（Integer）であることが要求されているにもかかわらず、文字列（String）を受信した場合、 そのフィールドはデフォルトで無視されるでしょう。 フィールドが異なるエラー処理を必要とする場合、これは明示的に指定されなければなりません。
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.
仕様書では、フィールド名を必要に応じて 「構造化ヘッダー名（structured header name）」、「構造化トレーラー名（structured trailer name）」、 「構造化フィールド名（structured field name）」と表記することができます。 同様に必要に応じて、そのフィールド値を「構造化ヘッダー値（structured header value）」、 「構造化トレーラー値（structured trailer value）」または「構造化フィールド値（structured field value）」として参照することができます。 フィールド定義は、本仕様で定義された「sf-」で始まるABNF規則を使用することが推奨されます。 本仕様の他の規則は、フィールド定義に使用されることを意図していない。
For example, a fictitious Foo-Example header field might be specified as:
たとえば、架空のFoo-Exampleヘッダーフィールドは次のように指定されるかもしれません。
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-integerIts 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/"
42.Foo-Example ヘッダー
Foo-Example HTTPヘッダーフィールドは、メッセージにどれだけのFooがあるかという情報を伝えます。
Foo-Example は Item Structured Header [RFC8941]である。その値は整数（Integer）でなければなりません(MUST) （[RFC8941]のSection 3.3.1参照）。そのABNFは
Foo-Example = sf-integerその値は、メッセージ中のFooの量を示し、0から10の間でなければなりません（MUST）。
以下のパラメーターが定義されています。
- キー「foourl」を持つパラメーターの値は文字列（String）（[RFC8941のSection 3.3.3]）です。 メッセージのFoo URL伝えるために使用されます。処理の要件は以下を参照してください。
「foourl」はURIリファレンス（[RFC3986]のSection 4.1）。 その値が有効なURIリファレンスでない場合、そのヘッダーフィールド全体は無視されなければなりません（MUST）。 その値が相対リファレンス（[RFC3986]のSection 5）の場合、使用される前に解決されなければなりません。
例を以下に示します：
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.
この節では、Structured Fields の抽象的な型を定義する。提供されるABNFは、HTTPフィールド値におけるオンワイヤーフォーマットを表します。
In summary:
まとめると
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).
リスト（List）は0個以上のメンバーからなる配列で、 それぞれがアイテム（Section 3.3） またはインナーリスト（Section 3.1.1）になります。 どちらもパラメーター化(Section 3.1.2)することが可能です。
The ABNF for Lists in HTTP fields is:
HTTPフィールドのListのABNFは以下の通りです。
sf-list = list-member *( OWS "," OWS list-member ) list-member = sf-item / inner-list
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
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]のSection 3.2.2 のように， そのメンバを同じヘッダーやトレーラーセクション内の複数の行に、分割することができることに注意してください。たとえば、以下は等価です:
Example-List: sugar, tea, rum
Example-List: sugar, tea, rum
and
と
Example-List: sugar, tea Example-List: rum
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.
ただし、Listの個々のメンバを安全に行に分割することはできません。 詳しくは、Section 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個のメンバーを含むListをサポートしなければなりません（MUST）。 フィールドの仕様は、必要に応じて個々のリスト値の型と要素数を制限することができます。
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).
インナーリスト（Inner List）は、0個以上のアイテム（Section 3.3)です。個々のItemもInner List自体もパラメーター化することができます(Section 3.1.2）からなる配列です。
The ABNF for Inner Lists is:
インナーリストのABNFは以下の通りです：
inner-list = "(" *SP [ sf-item *( 1*SP sf-item ) *SP ] ")"
parameters
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"), ()
Example-List: ("foo" "bar"), ("baz"), ("bat" "one"), ()
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
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のメンバーを含むインナーリストをサポートしなければなりません（MUST）。 フィールド仕様は、個々のインナーリストのメンバー型と要素数を、必要に応じて制限することができます。
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).
パラメーター（Parameter）は、アイテム（Section 3.3 ）または インナーリスト（Section 3.1.1 ）と関連付けられた、キーと値のペアの順序付きマップです。 キーはパラメーターの範囲内で一意であり、値は裸のアイテムです（つまり、それ自体をパラメーター化することはできません。Section 3.3 を参照してください）。
Implementations MUST provide access to Parameters both by index and by key. Specifications MAY use either means of accessing them.
実装は、パラメーターへのアクセス方法として、インデックスとキーの両方を提供しなければなりません（MUST）。 仕様は、どちらかの方法でアクセスしてもよいです（MAY）。
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
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
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:
値が真偽値（Section 3.3.6 参照）であるパラメーターは、 シリアライズ時にその値を省略しなければなりません（MUST）。 たとえば、ここで "a "パラメーターはtrueであり、"b "パラメーターはfalseです。
Example-Integer: 1; a; b=?0
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.
パーサはItemまたはInner Listで少なくとも256個のパラメーターをサポートし、 少なくとも64文字のパラメーターキーをサポートしなければなりません（MUST）。 フィールド指定は、必要に応じて個々のパラメーターの順序やその値の型を制約することができます。
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.
辞書（Dictionary）はキーと値のペアの順序付きマップであり、 キーは短いテキスト文字列、値はアイテム (Section 3.3) またはアイテムの配列で、 どちらもパラメーター化 (Section 3.1.2) が可能です。 メンバーは0個以上存在でき、そのキーは辞書のスコープ内で一意です。
Implementations MUST provide access to Dictionaries both by index and by key. Specifications MAY use either means of accessing the members.
実装は辞書へのアクセス方法として、インデックスとキーの両方を提供しなければなりません（MUST）。 仕様は、メンバーへのアクセスにどちらかの手段を使用してもよいです（MAY）。
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
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=:
Example-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.
この例では、最後の"="はバイト列（Section 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:
値が真偽値（Section 3.3.6 を参照）であるメンバーは、 シリアライズ時にその値を省略しなければなりません（MUST）。たとえば、以下の例では「b」と「c」の両方がtrueです。
Example-Dict: a=?0, b, c; foo=bar
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)
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
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.
一般的に、フィールド仕様は、キーによって個々のメンバーに許可される型と、 その存在が必須か任意かを指定することによって、辞書のセマンティクスを定義します。 受信者は、フィールドの仕様でとくに禁止されていない限り、キーが未定義または不明のメンバーを無視しなければなりません（MUST）。
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
Example-Dict: foo=1, bar=2
and
と
Example-Dict: foo=1 Example-Dict: bar=2
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.
ただし、辞書の個々のメンバーを安全に行に分割することはできません。 詳しくはSection 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文字のキーを含む辞書をサポートしなければなりません（MUST）。 フィールド指定は、必要に応じて値の型と、個々の辞書メンバーの順序を制限することができます。
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).
アイテム（Item）は、 整数(Section 3.3.1)、 小数(Section 3.3.2)、 文字列(Section 3.3.3)、 トークン(Section 3.3.4)、 バイト列(Section 3.3.5)、 真偽値(Section 3.3.6) のいずれかを表します。 また、関連するパラメーター(Section 3.1.2)を持つことも可能です。
The ABNF for Items is:
ItemのABNFは以下のとおりです：
sf-item = bare-item parameters
bare-item = sf-integer / sf-decimal / sf-string / sf-token
/ sf-binary / sf-boolean
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
Example-Integer: 5
or with parameters:
また、パラメーターで指定した場合です：
Example-Integer: 5; foo=bar
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].
整数（Integer）は、IEEE754互換[IEEE754]のため、 -999,999,999,999～999,999,999の範囲（すなわち最大15桁、符号あり）を持ちます。
The ABNF for Integers is:
整数のABNFは以下の通りです：
sf-integer = ["-"] 1*15DIGIT
sf-integer = ["-"] 1*15DIGIT
For example:
以下に例を示します：
Example-Integer: 42
Example-Integer: 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桁より大きい整数については、 様々な方法でサポートすることができます。 たとえば、文字列(Section 3.3.3)、 バイト列(Section 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.
整数のカンマは、本セクションの文中では読みやすくするためにのみ使用していることに注意してください。wireフォーマットでは無効です。
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.
小数（Decimal）は、整数部と小数部を持つ数です。 整数部は最大12桁、小数部は最大3桁です。
The ABNF for decimals is:
小数のABNFは以下の通りです。
sf-decimal = ["-"] 1*12DIGIT "." 1*3DIGIT
sf-decimal = ["-"] 1*12DIGIT "." 1*3DIGIT
For example, a header whose value is defined as a Decimal could look like:
たとえば、値が小数として定義されているヘッダーは、以下のようになります。
Example-Decimal: 4.5
Example-Decimal: 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」) および符号付きゼロ (たとえば「-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.
シリアライズアルゴリズム(Section 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.
文字列（String）は、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 / "\" )
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"
Example-String: "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.
文字列の区切り文字はDQUOTEのみで、シングルクォートでは区切りらないので注意してください。 また、エスケープできるのはDQUOTEと「\」だけで、それ以外の文字はパースに失敗しなければなりません（MUST）
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は、多くの相互運用性の問題を引き起こすため、文字列では直接サポートされていません。 また、いくつかの例外を除いて、フィールド値に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]）とともにバイト列（Section 3.3.5) を指定することができます。
Parsers MUST support Strings (after any decoding) with at least 1024 characters.
パーサーは、少なくとも1024文字の文字列（デコード後）をサポートしなければなりません（MUST）。
Tokens are short textual words; their abstract model is identical to their expression in the HTTP field value serialization.
トークン（Token）は短いテキストの単語であり、 その抽象的なモデルはHTTPフィールド値シリアライゼーションにおける表現と同じです。
The ABNF for Tokens is:
トークンのABNFは以下の通りです。
sf-token = ( ALPHA / "*" ) *( tchar / ":" / "/" )
sf-token = ( ALPHA / "*" ) *( tchar / ":" / "/" )
For example:
以下に例を示します：
Example-Token: foo123/456
Example-Token: foo123/456
Parsers MUST support Tokens with at least 512 characters.
パーサーは少なくとも512文字のトークンをサポートしなければなりません（MUST）。
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]で定義されている「token」ABNFルールと同じ文字が使えます。 ただし、最初の文字はALPHAか「*」でなければならず、「:」と「/」はそれ以降の文字でも許容されるという違いがあります。
Byte Sequences can be conveyed in Structured Fields.
バイト列（Byte Sequence）を、構造化フィールドで伝えることができます。
The ABNF for a Byte Sequence is:
バイト列のABNFは以下の通りです：
sf-binary = ":" *(base64) ":" base64 = ALPHA / DIGIT / "+" / "/" / "="
sf-binary = ":" *(base64) ":" base64 = ALPHA / DIGIT / "+" / "/" / "="
Example-ByteSequence: :cHJldGVuZCB0aGlzIGlzIGJpbmFyeSBjb250ZW50Lg==:
Example-ByteSequence: :cHJldGVuZCB0aGlzIGlzIGJpbmFyeSBjb250ZW50Lg==:
Parsers MUST support Byte Sequences with at least 16384 octets after decoding.
パーサーは、デコード後に少なくとも16384オクテットのバイト列をサポートしなければなりません（MUST）。
Boolean values can be conveyed in Structured Fields.
真偽値（Boolean）を構造化フィールドで伝えることができます。
The ABNF for a Boolean is:
真偽値のABNFは以下の通りです。
sf-boolean = "?" boolean boolean = "0" / "1"
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」、偽の場合は「0」で表されます。以下に例を示します：
Example-Boolean: ?1
Example-Boolean: ?1
Note that in Dictionary (Section 3.2) and Parameter (Section 3.1.2) values, Boolean true is indicated by omitting the value.
なお、辞書(Section 3.2)およびパラメーター(Section 3.1.2)の値では、 ブール値の真は値を省略することで表されます。
Given a structure defined in this specification, return an ASCII string suitable for use in an HTTP field value.
本仕様書で定義された構造体が与えられた場合、HTTPフィールド値として使用するのに適したASCII文字列を返します。
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, parameters) タプルの配列が与えられた場合、HTTPフィールドの値として使用するのに適したASCII文字列を返します。
For each (member_value, parameters) of input_list:
If more member_values remain in input_list:
input_list の各（member_value, parameters）に対して：
input_list にさらに member_value が残っている場合：
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.
(member_value, parameters) タプルの配列を inner_list、 パラメーターを list_parameters として与えたとき、HTTP フィールドの値として使用するのに適したASCII文字列を返します。
For each (member_value, parameters) of inner_list:
inner_listの各(member_value, parameters)に対して：
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 文字列を返します。
For each param_key with a value of param_value in input_parameters:
If param_value is not Boolean true:
input_parameters中でparam_keyの値がparam_valueであるものについて：
param_valueが真偽値の真でない場合：
Given a key as input_key, return an ASCII string suitable for use in an HTTP field value.
キーをinput_keyとして渡すと、HTTPフィールドの値として適切なASCII文字列を返します。
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文字列を返します。
For each member_key with a value of (member_value, parameters) in input_dictionary:
If member_value is Boolean true:
Otherwise:
If more members remain in input_dictionary:
input_dictionary の、値が (member_value, parameters) である member_key について、その値を取得します。
member_value が真偽値の真の場合：
それ以外の場合：
input_dictionary にさらにメンバーが残っている場合：
Given an Item as bare_item and Parameters as item_parameters, return an ASCII string suitable for use in an HTTP field value.
bare_itemとしてアイテムを、item_parameters としてパラメーターを与えられたとき、 HTTP フィールド値として使用するのに適したASCII文字列を返します。
Given an Item as input_item, return an ASCII string suitable for use in an HTTP field value.
input_itemとしてアイテムを与えられたとき、 HTTPフィールドの値として使用するのに適したASCII文字列を返します。
Given an Integer as input_integer, return an ASCII string suitable for use in an HTTP field value.
整数をinput_integerとして与えると、HTTPフィールドの値として使用するのに適したASCII文字列を返します。
Given a decimal number as input_decimal, return an ASCII string suitable for use in an HTTP field value.
小数をinput_decimalとして与えると、HTTP フィールドの値として使用するのに適したASCII文字列を返します。
Given a String as input_string, return an ASCII string suitable for use in an HTTP field value.
文字列をinput_stringとして与えると、HTTPフィールドの値として使用するのに適したASCII文字列を返します。
For each character char in input_string:
If char is "\" or DQUOTE:
input_stringの各文字charについて：
charが「\」またはDQUOTEの場合
Given a Token as input_token, return an ASCII string suitable for use in an HTTP field value.
トークンをinput_tokenとして与えると、HTTPフィールドの値として使用するのに適したASCII文字列を返します。
Given a Byte Sequence as input_bytes, return an ASCII string suitable for use in an HTTP field value.
バイト列をinput_bytesとして与え、HTTP のフィールド値として使用するのに適したASCII文字列を返します。
The encoded data is required to be padded with "=", as per [RFC4648], Section 3.2.
エンコードされたデータは、[RFC4648], Section 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], Section 3.5 にしたがってパッドビットをゼロに設定すべきです（SHOULD）。
Given a Boolean as input_boolean, return an ASCII string suitable for use in an HTTP field value.
真偽値をinput_booleanとして与えると、HTTPフィールドの値として使用するのに適したASCII文字列を返します。
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.
受け取り側の実装が、Structured Fieldsであることが分かっている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（dictionary, list, item のいずれか）を表すバイト列を input_bytes として与え、 解析されたヘッダー値を返します。
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], Section 3.2.2 にしたがって、 大文字小文字を区別せずにフィールド名と一致する同じセクション（ヘッダーまたはトレーラー）のすべてのフィールド行を1つのカンマ区切りフィールド値に結合しなければなりません（MUST）。 これは、フィールド値全体が正しく処理されることを確実にするものです。
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つがそのフィールドとしてパースされない場合、失敗してもよいです（MAY）。 たとえば、sf-stringとして定義されたExample-Stringフィールドを処理するパーサーは、このフィールドセクションを処理する際に失敗しても構いません。
Example-String: "foo Example-String: bar"
Example-String: "foo Example-String: 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.
パースに失敗した場合(別のアルゴリズムを呼び出す場合も含む)、フィールド値全体を無視しなければなりません（MUST） （すなわち、そのセクションにフィールドが存在しないかのように扱います）。 これは相互運用性と安全性を高めるために意図的に厳しくしており、この文書を参照する仕様では、この要件を緩めることは許されません。
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.
ASCII文字列をinput_stringとして与え、(item_or_inner_list, parameters) タプルの配列を返します。 input_stringは解析済みの値を除去するために変更されます。
While input_string is not empty:
input_stringが空でない間:
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.
ASCII文字列をinput_stringとして与えると、タプル (item_or_inner_list, parameters) を返します。 ここで item_or_inner_list は単一の裸のアイテムか、 (bare_item, parameters) タプルの配列のいずれかです。
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.
ASCII文字列をinput_stringとして与え、inner_listを(bare_item, parameters)の配列としたタプルを返します。 input_stringは解析済みの値を除去するために変更されます。
While input_string is not empty:
If the first character of input_string is ")":
input_stringが空でない間:
もしinput_stringの先頭一文字が「)」である場合:
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.
ASCII文字列をinput_stringとして与え、(item_or_inner_list, parameters)タプルを値とする順序付きマップを返します。 input_stringは解析済みの値を除去するために変更されます。
While input_string is not empty:
If the first character of input_string is "=":
Otherwise:
input_stringが空でない間:
input_stringの最初の文字が"="である場合:
それ以外の場合:
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.
ASCII 文字列を input_string として与え、(bare_item, parameters) タプルを返します。 input_stringは解析済みの値を除去するために変更されます。
Given an ASCII string as input_string, return a bare Item. input_string is modified to remove the parsed value.
ASCII文字列をinput_stringとして与え、裸のアイテムを返します。 input_stringは解析済みの値を除去するために変更されます。
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.
ASCII文字列をinput_stringとして与え、裸のアイテムを値とする順序付きマップを返します。 input_stringは解析済みの値を除去するために変更されます。
While input_string is not empty:
If the first character of input_string is "=":
input_stringが空でない間:
input_stringの最初の文字が"="である場合:
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.
ASCII文字列をinput_stringとして与え、キーを返します。 input_stringは解析済みの値を除去するために変更されます。
While input_string is not empty:
input_stringが空でない間:
Given an ASCII string as input_string, return an Integer or Decimal. input_string is modified to remove the parsed value.
ASCII文字列をinput_stringとして与え、整数または小数を返します。 input_stringは解析済みの値を除去するために変更されます。
NOTE: This algorithm parses both Integers (Section 3.3.1) and Decimals (Section 3.3.2), and returns the corresponding structure.
注：このアルゴリズムは、整数(Section 3.3.1)と小数(Section 3.3.2)の両方を解析し、対応する構造を返します。
While input_string is not empty:
Else, if type is "integer" and char is ".":
If type is "integer":
Otherwise:
input_stringが空でない間:
また、typeが「integer」で、charが「.」の場合:
typeが「integer」の場合:
それ以外の場合:
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は解析済みの値を除去するために変更されます。
While input_string is not empty:
If char is a backslash ("\"):
input_stringが空でない間:
charがバックスラッシュ（「\」）の場合：
Given an ASCII string as input_string, return a Token. input_string is modified to remove the parsed value.
ASCII文字列をinput_stringとして与え、Tokenを返します。 input_stringは解析済みの値を除去するために変更されます。
While input_string is not empty:
input_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は解析済みの値を除去するために変更されます。
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の実装によっては、適切に"="パディングされていないエンコードされたデータを拒否することができないため([RFC4648], Section 3.2 参照)、パーサーは"="パディングが存在しない場合、そう設定できない場合を除いて、失敗すべきではありません（SHOULD NOT）。
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の実装によっては、0以外のパッドビットを持つエンコードされたデータを拒否することができないため([RFC4648], Section 3.5 参照)、パーサーは0以外のパッドビットが存在する場合、そのように設定できない場合を除いて、失敗すべきではありません（SHOULD NOT）。
Given an ASCII string as input_string, return a Boolean. input_string is modified to remove the parsed value.
ASCII文字列をinput_stringとして与え、真偽値を返します。 input_stringは解析済みの値を除去するために変更されます。
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.
Structured Fields で定義されるほとんどの型のサイズは制限されていません。その結果、極端に大きなフィールドは攻撃のベクトル (リソースの消費など) となる可能性があります。 ほとんどの 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フィールドを注入する能力を持つ当事者が、構造化フィールドの意味を変更することは可能です。 状況によってはパースに失敗しますが、そのような状況すべてにおいて確実に失敗することは不可能です。
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.
また、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.
この仕様の汎用実装は、トップレベルのシリアライズ(Section 4.1)とパース(Section 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>.
相互運用のためには、汎用的な実装が完全であり、アルゴリズムに忠実であることが重要です（Section 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.
実装者は、DictionariesとParameterが順序を保持するマップであることに注意する必要があります。いくつかのフィールドは、これらのデータ型の順序で意味を伝えないかもしれませんが、それを使用する必要があるアプリケーションが利用できるように、まだ公開されるべきです。
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.
シリアライズアルゴリズムは、あらゆる場合にSection 3 で定義されたデータ型に厳密には限定されないように定義されています。たとえば、Decimalsはより広い入力を取り、許容される値に丸めるように設計されています。
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.
実装は、各タイプに定義された最小値にしたがって、さまざまな構造体のサイズを制限することが許されています。構造体が実装上の制限を超えた場合、その構造体はパースやシリアライズに失敗します。
Many thanks to Matthew Kerwin for his detailed feedback and careful consideration during the development of this specification.
本仕様書の作成にあたり、詳細なフィードバックと慎重な検討をいただいたMatthew Kerwin 様に深く感謝いたします。
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,Anne van Kesteren,Kazuho Oku,Evert Pot,Julian Reschke,Martin Thomson,Mike West, およびJeffrey Yasskin の方々にもご協力をいただきました。