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.
この文書は、「構造化フィールド」、「構造化ヘッダー」、または「構造化トレーラー」として知られるHTTPヘッダーおよびトレーラーフィールドを定義および処理することを容易かつ安全にするための一連のデータ型および関連するアルゴリズムについて説明します。これは、新しいHTTPフィールドの仕様で使用することを意図しています。
This document obsoletes RFC 8941.
この文書はRFC 8941を廃止します。
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/rfc9651.
この文書の現在の状態、正誤表、それに対するフィードバックの提供方法に関する情報は、 https://www.rfc-editor.org/info/rfc9651 で入手できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2024 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、この文書の発行日に有効なBCP 78およびIETFトラストの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 16.3.2 of [HTTP], there are many decisions -- and pitfalls -- for a prospective HTTP field author.
新しいHTTPヘッダー（とトレーラー）フィールドの構文を指定するのは大変な作業です。[HTTP]のSection 16.3.2のガイダンスがあったとしても、 これから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 [HTTP] header and trailer fields.
この文書ではこれらの問題に対処するために、 新しいHTTPフィールド値の定義で使用するための一連の共通データ構造を導入します。とくに、HTTP [HTTP] のヘッダーとトレーラーフィールドで、 そのモデルを表現するための具体的なシリアライズとともに、それらのための一般的で抽象的なモデルを定義しています。
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 entire 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. When parsing from HTTP fields, implementations MUST have behavior that is indistinguishable from following the algorithms.
この文書では、解析およびシリアル化の動作を指定するためにアルゴリズムを使用します。HTTPフィールドから解析する場合、実装はアルゴリズムに従うのと区別がつかない動作をしなければなりません（MUST）。
For serialization to HTTP fields, 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フィールドへのシリアル化については、アルゴリズムはそれらを生成する推奨方法を定義します。実装は、Section 4.2で説明されている解析アルゴリズムによって出力が正しく処理される限り、指定された動作から変化してもよいです（MAY）。
To specify an HTTP field as a Structured Field, its authors need to:
HTTP フィールドを Structured Field として指定するために、その作者は以下のことを行う必要があります。
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).
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.
本仕様書を規範的に参照する。現場の受信者及び生成者は、この文書の要求事項が有効であることを知る必要があります。
そのフィールドが Structured Header (すなわち、ヘッダーセクションでのみ使用可能。一般的なケース)、 Structured Trailer (トレーラーセクションのみ)、または Structured Field (両方)のいずれであるかを特定する。
フィールド値の型を指定する。 リスト(Section 3.1)、辞書(Section 3.2)、アイテム(Section 3.3)のいずれかです。
フィールド値のセマンティクスを定義する。
フィールド値に対する追加制約を指定する。同様に制約に違反した場合の結果も指定します。
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) は、 フィールド定義で明示的に許可されている場合にのみ有効です。
Fields that use the Display String type are advised to carefully specify their allowable Unicode code points; for example, specifying the use of a profile from [PRECIS].
表示文字列タイプを使用するフィールドは、許可されるUnicodeコードポイントを慎重に指定することが推奨されます。例えば、[PRECIS]のプロファイルの使用を指定することが考えられます。
Field definitions can only use this specification for the entire field value, not a portion thereof.
フィールド定義は、フィールド値全体に対してのみこの仕様を使用でき、一部に対しては使用できません。
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.
仕様書では、フィールド名を必要に応じて 「構造化ヘッダー名（structured header name）」、「構造化トレーラー名（structured trailer name）」、 「構造化フィールド名（structured field name）」と表記することができます。 同様に必要に応じて、そのフィールド値を「構造化ヘッダー値（structured header value）」、 「構造化トレーラー値（structured trailer value）」または「構造化フィールド値（structured field value）」として参照することができます。
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の実装では個々のフィールドのサイズやフィールドの総数、 ヘッダーやトレーラーセクション全体のサイズに様々な制限があることを、作者は知っておくべきです。
A fictitious Foo-Example header field might be specified as:
架空のFoo-Exampleヘッダーフィールドは次のように指定されるかもしれません。
42. Foo-Example Header Field
The Foo-Example HTTP header field conveys information about how much Foo the message has.
Foo-Example is an Item Structured Header Field [RFC9651]. Its value MUST be an Integer (Section 3.3.1 of [RFC9651]).
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 [RFC9651]), 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 は構造化ヘッダーのアイテム [RFC9651] です。その値は整数(Integer)である必要があります（MUST） ([RFC9651] の Section 3.3.1 参照)。
その値はメッセージ中のFooの量を表し、0から10の間（両端を含む）である必要があります（MUST）。 他の値は、ヘッダーフィールド全体を無視する必要があります（MUST）。
以下のパラメーターが定義されています。
- キー「foourl」を持つパラメーターの値は文字列（String）([RFC9651] の 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/"
When parsing fails, the entire field is ignored (see Section 4.2). Field definitions cannot override this 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).
パースに失敗すると、フィールド全体が無視されます (Section 4.2参照)。フィールド定義はこれを上書きすることはできません。なぜなら、それを行うと汎用ソフトウェアによる処理ができなくなるからです。フィールド定義は追加の制約を加えることしかできません（例えば、整数や小数の数値範囲、文字列やトークンの形式、辞書の値に許可される型、リスト内の項目数など）。
When field-specific constraints are violated, the entire field is also ignored, unless the field definition defines other handling requirements. For example, if a header field is defined as an Item and required to be an Integer, but a String is received, it should be ignored unless that field's definition explicitly specifies otherwise.
フィールド固有の制約が違反された場合、フィールド定義が他の処理要件を定義していない限り、フィールド全体も無視されます。例えば、ヘッダーフィールドがアイテムとして定義され、整数であることが要求されているが、文字列が受信された場合、そのフィールドの定義が明示的に他の処理を指定していない限り、それは無視されるべきです。
Structured Fields are designed to be extensible because experience has shown that, even when it is not foreseen, it is often necessary to modify and add to the allowable syntax and semantics of a field in a controlled fashion.
構造化フィールドは、経験上、予見されていない場合でも、フィールドの許容される構文と意味を制御された方法で変更および追加する必要があることが多いため、拡張可能に設計されています。
Both Items and Inner Lists allow Parameters as an extensibility mechanism; this means that their 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.
アイテムと内部リストの両方が拡張メカニズムとしてパラメーターを許可します。これは、必要に応じて後でその値を拡張してより多くの情報を収容できることを意味します。将来の互換性を維持するために、フィールド仕様では認識されないパラメーターの存在をエラー条件として定義することは推奨されません。
Field specifications are required to be either an Item, List, or Dictionary to preserve extensibility. Fields that erroneously defined as another type (e.g., Integer) are assumed to be Items (i.e., they allow Parameters).
フィールド仕様は、拡張性を保持するために、アイテム、リスト、または辞書のいずれかである必要があります。誤って他のタイプ（例：整数）として定義されたフィールドは、アイテムと見なされます（つまり、パラメーターを許可します）。
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 keys be ignored. Subsequent specifications can then add additional keys, 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.
構造化フィールドの拡張は、定義された値の制約が満たされない場合に、そのフィールド値全体を理解する受信者によって無視することを要求できます。
Because a field definition needs to reference a specific RFC for Structured Fields, the types available for use in its value are limited to those defined in that RFC. For example, a field whose definition references this document can have a value that uses the Date type (Section 3.3.7), whereas a field whose definition references RFC 8941 cannot because it will be treated as invalid (and therefore discarded) by implementations of that specification.
フィールド定義が構造化フィールドの特定のRFCを参照する必要があるため、その値に使用できるタイプはそのRFCで定義されたものに限定されます。例えば、この文書を参照するフィールド定義は、Dateタイプ（Section 3.3.7）を使用する値を持つことができますが、RFC 8941を参照するフィールド定義は、その仕様の実装によって無効（したがって破棄）と見なされるため、使用できません。
This limitation also applies to future extensions to a field; for example, a field that is defined with a reference to RFC 8941 cannot use the Date type because some recipients might still be using a parser based on RFC 8941 to process it.
この制限は、フィールドの将来の拡張にも適用されます。例えば、RFC 8941を参照して定義されたフィールドは、Dateタイプを使用できません。なぜなら、一部の受信者は依然としてRFC 8941に基づいたパーサーを使用してそれを処理している可能性があるからです。
However, this document is designed to be backward compatible with RFC 8941; a parser that implements the requirements here can also parse valid Structured Fields whose definitions reference RFC 8941.
ただし、この文書はRFC 8941との後方互換性を持つように設計されています。ここでの要件を実装するパーサーは、RFC 8941を参照する定義の有効な構造化フィールドも解析できます。
Upgrading a Structured Fields implementation to support a newer revision of the specification (such as this document) brings the possibility that some field values that were invalid according to the earlier RFC might become valid when processed.
構造化フィールドの実装を新しい改訂版の仕様（この文書など）に対応するようにアップグレードすると、以前のRFCでは無効とされていたフィールド値が処理時に有効になる可能性があります。
For example, a field instance might contain a syntactically valid Date (Section 3.3.7), even though that field's definition does not accommodate Dates. An implementation based on RFC 8941 would fail parsing such a field instance because it is not defined in that specification. If that implementation were upgraded to this specification, parsing would now succeed. In some cases, the resulting Date value will be rejected by field-specific logic, but values in fields that are otherwise ignored (such as extension parameters) might not be detected, and the field might subsequently be accepted and processed.
例えば、フィールドインスタンスが構文的に有効なDate（Section 3.3.7）を含む場合、そのフィールドの定義がDateを受け入れないにもかかわらずです。RFC 8941に基づく実装は、その仕様で定義されていないため、そのようなフィールドインスタンスの解析に失敗します。その実装がこの仕様にアップグレードされた場合、解析は成功します。一部のケースでは、結果として得られるDate値はフィールド固有のロジックによって拒否されますが、拡張パラメーターなどの他のフィールドで無視される値は検出されず、そのフィールドが受け入れられ処理される可能性があります。
This section provides an overview of the abstract types that Structured Fields use and gives a brief description and examples of how each of those types are serialized into textual HTTP fields. Section 4 specifies the details of how they are parsed from and serialized into textual HTTP fields.
このセクションでは、構造化フィールドが使用する抽象型の概要を示し、それぞれの型がテキストHTTPフィールドにシリアル化される方法の簡単な説明と例を示します。Section 4では、それらがテキストHTTPフィールドから解析され、シリアル化される方法の詳細を指定しています。
In summary:
まとめると
There are three top-level types that an HTTP field can be defined as: Lists, Dictionaries, and Items.
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.
HTTPフィールドが定義できるトップレベルの型は3つあります。リスト、ディクショナリ、そしてアイテムです。
リストとディクショナリはコンテナであり、そのメンバはアイテムまたはインナーリスト（それ自体がアイテムの配列である）であることができます。
アイテムもインナーリストも、キーと値のペアでパラメーター化することができます。
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)することが可能です。
An empty List is denoted by not serializing the field at all. This implies that fields defined as Lists have a default empty value.
空のリストは、フィールドを全くシリアライズしないことで示されます。 これは、リストとして定義されたフィールドは、デフォルトで空の値を持つことを意味します。
When serialized as a textual HTTP field, 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:
テキストHTTPフィールドとしてシリアル化されると、各メンバーはカンマとオプションの空白で区切られます。例えば、値がトークンのリストとして定義されているフィールドは次のようになります:
Example-List: sugar, tea, rum
Example-List: sugar, tea, rum
Note that Lists can have their members split across multiple lines of the same header or trailer section, as per Section 5.3 of [HTTP]; for example, the following are equivalent:
リストは、[HTTP]のSection 5.3のように， そのメンバを同じヘッダーやトレーラーセクション内の複数の行に、分割することができることに注意してください。たとえば、以下は等価です:
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）からなる配列です。
When serialized in a textual HTTP field, 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:
テキストHTTPフィールドとしてシリアル化されると、内部リストは括弧で囲まれ、その値は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）。
Note that parameters are ordered, and parameter keys cannot contain uppercase letters.
パラメーターはシリアライズされた順番で順序付けされ、 パラメーターのキーに大文字を含めることができないことに注意してください。
When serialized in a textual HTTP field, a Parameter is separated from its Item or Inner List and other Parameters by a semicolon. For example:
テキストHTTPフィールドとしてシリアル化されると、パラメーターはそのアイテムまたは内部リストおよび他のパラメーターとセミコロンで区切られます。例えば:
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）。
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 are undefined or unknown, unless the field's specification specifically disallows them.
一般的に、フィールド仕様は、キーによって個々のメンバーに許可される型と、 その存在が必須か任意かを指定することによって、辞書のセマンティクスを定義します。 受信者は、フィールドの仕様でとくに禁止されていない限り、キーが未定義または不明のメンバーを無視しなければなりません（MUST）。
When serialized as a textual HTTP field, 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:
テキストHTTPフィールドとしてシリアル化されると、メンバーはシリアル化された順序で並べられ、カンマとオプションの空白で区切られます。メンバーキーには大文字を含めることはできません。キーと値は"="（空白なし）で区切られます。例えば:
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
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), a Boolean (Section 3.3.6), or a Date (Section 3.3.7). 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.3.7)のいずれかを表します。また、関連するパラメーター(Section 3.1.2)を持つことも可能です。
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桁、符号あり）を持ちます。
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桁です。
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 field 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 の範囲）です。 タブ、改行、キャリッジリターンなどは含まれないことに注意してください。
Non-ASCII characters are not directly supported in Strings because they cause a number of interoperability issues, and -- with few exceptions -- field values do not require them.
非ASCII文字は、いくつかの相互運用性の問題を引き起こすため、文字列では直接サポートされていません。そして、いくつかの例外を除いて、フィールド値はそれらを必要としません。
When it is necessary for a field value to convey non-ASCII content, a Display String (Section 3.3.8) can be specified.
フィールド値が非ASCIIコンテンツを伝える必要がある場合、表示文字列（Section 3.3.8)を指定できます。
When serialized in a textual HTTP field, Strings are delimited with double quotes, using a backslash ("\") to escape double quotes and backslashes. For example:
テキストHTTPフィールドとしてシリアル化されると、文字列は二重引用符で区切られ、バックスラッシュ（"\"）を使用して二重引用符とバックスラッシュをエスケープします。例えば:
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）
Parsers MUST support Strings (after any decoding) with at least 1024 characters.
パーサーは、少なくとも1024文字の文字列（デコード後）をサポートしなければなりません（MUST）。
Tokens are short textual words that begin with an alphabetic character or "*", followed by zero to many token characters, which are the same as those allowed by the "token" ABNF rule defined in [HTTP] plus the ":" and "/" characters.
トークンは、アルファベット文字または"*"で始まり、その後にゼロ個以上のトークン文字が続く短いテキスト単語です。トークン文字は、[HTTP]で定義された"token" ABNFルールで許可される文字に加えて、":"および"/"文字も含まれます。
For example:
例えば:
Example-Token: foo123/456
Example-Token: foo123/456
Parsers MUST support Tokens with at least 512 characters.
パーサーは少なくとも512文字のトークンをサポートしなければなりません（MUST）。
Note that Tokens are defined largely for compatibility with the data model of existing HTTP fields and may require additional steps to use in some implementations. As a result, new fields are encouraged to use Strings.
トークンは、既存のHTTPフィールドのデータモデルとの互換性のために定義されており、一部の実装では使用するために追加の手順が必要になる場合があります。その結果、新しいフィールドは文字列を使用することが推奨されます。
Byte Sequences can be conveyed in Structured Fields.
バイト列（Byte Sequence）を、構造化フィールドで伝えることができます。
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）を構造化フィールドで伝えることができます。
When serialized in a textual HTTP field, a Boolean is indicated with a leading "?" character followed by a "1" for a true value or "0" for false. For example:
テキストHTTPフィールドとしてシリアル化されると、ブール値は先頭に"?"文字が付き、trueの場合は"1"、falseの場合は"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)の値では、 ブール値の真は値を省略することで表されます。
Date values can be conveyed in Structured Fields.
日付（Date）を構造化フィールドで伝えることができます。
Dates have a data model that is similar to Integers, representing a (possibly negative) delta in seconds from 1970-01-01T00:00:00Z, excluding leap seconds. Accordingly, their serialization in textual HTTP fields is similar to that of Integers, distinguished from them with a leading "@".
日付は整数に似たデータモデルを持ち、1970-01-01T00:00:00Zからの秒単位の（場合によっては負の）差分を表し、うるう秒を除きます。したがって、テキストHTTPフィールドでのシリアル化は整数に似ていますが、先頭に"@"が付いていることで区別されます。
For example:
たとえば：
Example-Date: @1659578233
Example-Date: @1659578233
Parsers MUST support Dates whose values include all days in years 1 to 9999 (i.e., -62,135,596,800 to 253,402,214,400 delta seconds from 1970-01-01T00:00:00Z).
パーサーは、値が1年から9999年のすべての日を含む日付をサポートしなければなりません（MUST）（つまり、1970-01-01T00:00:00Zからのデルタ秒が-62,135,596,800から253,402,214,400まで）。
Display Strings are similar to Strings, in that they consist of zero or more characters, but they allow Unicode scalar values (i.e., all Unicode code points except for surrogates), unlike Strings.
表示文字列は文字列に似ており、ゼロ個以上の文字で構成されますが、文字列とは異なり、Unicodeスカラー値（つまり、サロゲートを除くすべてのUnicodeコードポイント）を許可します。
Display Strings are intended for use in cases where a value is displayed to end users and therefore may need to carry non-ASCII content. It is NOT RECOMMENDED that they be used in situations where a String (Section 3.3.3) or Token (Section 3.3.4) would be adequate because Unicode has processing considerations (e.g., normalization) and security considerations (e.g., homograph attacks) that make it more difficult to handle correctly.
表示文字列は、値がエンドユーザーに表示される場合に使用されることを意図しており、非ASCIIコンテンツを含む必要がある場合があります。文字列（Section 3.3.3)やトークン（Section 3.3.4)で十分な場合には、表示文字列を使用することは推奨されません（NOT RECOMMENDED）。なぜなら、Unicodeには処理上の考慮事項（例：正規化）やセキュリティー上の考慮事項（例：同形異義攻撃）があり、正しく処理するのが難しいからです。
Note that Display Strings do not indicate the language used in the value; that can be done separately if necessary (e.g., with a parameter).
表示文字列は、値に使用されている言語を示すものではないことに注意してください。必要に応じて、別途（例えば、パラメーターで）行うことができます。
In textual HTTP fields, Display Strings are represented in a manner similar to Strings, except that non-ASCII characters are percent-encoded; there is a leading "%" to distinguish them from Strings.
テキストHTTPフィールドでは、表示文字列は文字列と同様に表現されますが、非ASCII文字はパーセントエンコードされます。文字列と区別するために先頭に"%"が付きます。
For example:
たとえば：
Example-DisplayString: %"This is intended for display to %c3%bcsers."
Example-DisplayString: %"This is intended for display to %c3%bcsers."
Given a structure defined in this specification, return an ASCII string suitable for use in an HTTP field value.
本仕様書で定義された構造体が与えられた場合、HTTPフィールド値として使用するのに適したASCII文字列を返します。
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).
If the structure is a List, let output_string be the result of running Serializing a List (Section 4.1.1) with the structure.
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.
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.
Else, fail serialization.
Return output_string converted into an array of bytes, using ASCII encoding [RFC0020].
構造体が辞書またはリストであり、その値が空である場合（つまり、メンバーを持たない場合）、 そのフィールドは一切シリアライズしません（つまりfield-nameとfield-valueの両方を省略します）。
構造体がリストの場合、 その構造体に対して、リストのシリアライズ（Section 4.1.1）を実行した結果を、output_stringとします。
構造体が辞書の場合、 その構造体に対して、辞書のシリアライズ（Section 4.1.2）を実行した結果を、output_stringとします。
構造体がアイテムの場合、 その構造体に対して、アイテムのシリアライズ（Section 4.1.3）を実行した結果を、output_stringとします。
それ以外の場合は失敗します。
output_stringをASCIIエンコーディング[RFC0020]を用いて、 バイト配列に変換した結果を返します。
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文字列を返します。
Let output be an empty string.
For each (member_value, parameters) of input_list:
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.
Otherwise, append the result of running Serializing an Item (Section 4.1.3) with (member_value, parameters) to output.
If more member_values remain in input_list:
Append "," to output.
Append a single SP to output.
Return output.
outputに空文字列を代入します。
input_list の各（member_value, parameters）に対して：
member_valueが配列の場合、 (member_value, parameters)に対して、インナーリストのシリアライズ（Section 4.1.1.1） を実行した結果を、outputに追加します。
それ以外の場合、 (member_value, parameters)に対して、アイテムのシリアライズ（Section 4.1.3） を実行した結果を、outputに追加します。
input_list にさらに member_value が残っている場合：
「,」をoutputに追加します。
ひとつのSPをoutput追加します。
outputを返します。
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文字列を返します。
Let output be the string "(".
For each (member_value, parameters) of inner_list:
Append the result of running Serializing an Item (Section 4.1.3) with (member_value, parameters) to output.
If more values remain in inner_list, append a single SP to output.
Append ")" to output.
Append the result of running Serializing Parameters (Section 4.1.1.2) with list_parameters to output.
Return output.
outputに「(」を代入します。
inner_listの各(member_value, parameters)に対して：
(member_value, parameters)に対して、 アイテムのシリアライズ（Section 4.1.3）を実行した結果を、 outputに追加します。
まだinner_listに要素が残っている場合、outputにSPをひとつ追加します。
outputに「)」を追加します。
list_parametersに対して、 パラメーターのシリアライズ（Section 4.1.1.2）を実行した結果を、 outputに追加します。
outputを返します。
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 文字列を返します。
Let output be an empty string.
For each param_key with a value of param_value in input_parameters:
Append ";" to output.
Append the result of running Serializing a Key (Section 4.1.1.3) with param_key to output.
If param_value is not Boolean true:
Append "=" to output.
Append the result of running Serializing a bare Item (Section 4.1.3.1) with param_value to output.
Return output.
outputに空文字列を代入します。
input_parameters中でparam_keyの値がparam_valueであるものについて：
「;」をoutputに追加します。
param_keyに対して、 キーのシリアライズ（Section 4.1.1.3）を実行した結果を、 outputに追加します。
param_valueが真偽値の真でない場合：
「=」をoutputに追加します。
param_valueに対して、 裸のアイテムのシリアライズ（Section 4.1.3.1）を実行した結果を、 outputに追加します。
outputを返します。
Given a key as input_key, return an ASCII string suitable for use in an HTTP field value.
キーをinput_keyとして渡すと、HTTPフィールドの値として適切なASCII文字列を返します。
Convert input_key into a sequence of ASCII characters; if conversion fails, fail serialization.
If input_key contains characters not in lcalpha, DIGIT, "_", "-", ".", or "*", fail serialization.
If the first character of input_key is not lcalpha or "*", fail serialization.
Let output be an empty string.
Append input_key to output.
Return output.
input_keyをASCII文字の列に変換します；この変換が失敗した場合、シリアライズも失敗します。
input_keyがlcalpha、DIGIT、「_」、「-」、「.」、「*」に含まれない文字を含んでいる場合、シリアライズに失敗します。
input_keyの最初の文字がlcalphaまたは「*」でない場合、シリアライズに失敗します。
outputに空文字列を代入します。
input_keyをoutputに代入します。
outputを返します。
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文字列を返します。
Let output be an empty string.
For each member_key with a value of (member_value, parameters) in input_dictionary:
Append the result of running Serializing a Key (Section 4.1.1.3) with member's member_key to output.
If member_value is Boolean true:
Append the result of running Serializing Parameters (Section 4.1.1.2) with parameters to output.
Otherwise:
Append "=" to output.
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.
Otherwise, append the result of running Serializing an Item (Section 4.1.3) with (member_value, parameters) to output.
If more members remain in input_dictionary:
Append "," to output.
Append a single SP to output.
Return output.
outputに空文字列を代入します。
input_dictionary の、値が (member_value, parameters) である member_key について、その値を取得します。
メンバーのmember_keyに対して、 キーのシリアライズ（Section 4.1.1.3）を実行した結果を、 outputに追加します。
member_value が真偽値の真の場合：
parametersに対して、 パラメーターのシリアライズ（Section 4.1.1.2）を実行した結果を、 outputに追加します。
それ以外の場合：
outputに「=」を追加します。
もしmember_valueが配列ならば、 (member_value, parameters)に対して、 インナーリストのシリアライズ（Section 4.1.1.1）を実行した結果を、 outputに追加します。
配列でなければ、 (member_value, parameters)に対して、 アイテムのシリアライズ（Section 4.1.3）を実行した結果を、 outputに追加します。
input_dictionary にさらにメンバーが残っている場合：
outputに「,」を追加します。
outputにSPをひとつ追加します。
outputを返します。
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文字列を返します。
Let output be an empty string.
Append the result of running Serializing a Bare Item (Section 4.1.3.1) with bare_item to output.
Append the result of running Serializing Parameters (Section 4.1.1.2) with item_parameters to output.
Return output.
outputに空文字列を代入します。
bare_itemに対して、 裸のアイテムのシリアライズ（Section 4.1.3.1）を実行した結果を、 outputに追加します。
item_parametersに対して、 パラメーターのシリアライズ（Section 4.1.1.2）を実行した結果を、 outputに追加します。
outputを返します。
Given an Item as input_item, return an ASCII string suitable for use in an HTTP field value.
input_itemとしてアイテムを与えられたとき、 HTTPフィールドの値として使用するのに適したASCII文字列を返します。
If input_item is an Integer, return the result of running Serializing an Integer (Section 4.1.4) with input_item.
If input_item is a Decimal, return the result of running Serializing a Decimal (Section 4.1.5) with input_item.
If input_item is a String, return the result of running Serializing a String (Section 4.1.6) with input_item.
If input_item is a Token, return the result of running Serializing a Token (Section 4.1.7) with input_item.
If input_item is a Byte Sequence, return the result of running Serializing a Byte Sequence (Section 4.1.8) with input_item.
If input_item is a Boolean, return the result of running Serializing a Boolean (Section 4.1.9) with input_item.
If input_item is a Date, return the result of running Serializing a Date (Section 4.1.10) with input_item.
If input_item is a Display String, return the result of running Serializing a Display String (Section 4.1.11) with input_item.
Otherwise, fail serialization.
もしinput_itemが整数ならば、input_itemに対して、 整数のシリアライズ（Section 4.1.4）を実行した結果を返します。
もしinput_itemが小数ならば、input_itemに対して、 小数のシリアライズ（Section 4.1.5）を実行した結果を返します。
もしinput_itemが文字列ならば、input_itemに対して、 文字列のシリアライズ（Section 4.1.6）を実行した結果を返します。
もしinput_itemがトークンならば、input_itemに対して、 トークンのシリアライズ（Section 4.1.7）を実行した結果を返します。
もしinput_itemがバイト列ならば、input_itemに対して、 バイト列のシリアライズ（Section 4.1.8）を実行した結果を返します。
もしinput_itemが真偽値ならば、input_itemに対して、 真偽値のシリアライズ（Section 4.1.9）を実行した結果を返します。
もしinput_itemが日付ならば、input_itemに対して、 日付のシリアライズ（Section 4.1.10）を実行した結果を返します。
もしinput_itemが表示文字列ならば、input_itemに対して、 表示文字列のシリアライズ（Section 4.1.11）を実行した結果を返します。
それ以外の場合は、シリアライズに失敗します。
Given an Integer as input_integer, return an ASCII string suitable for use in an HTTP field value.
整数をinput_integerとして与えると、HTTPフィールドの値として使用するのに適したASCII文字列を返します。
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.
Let output be an empty string.
If input_integer is less than (but not equal to) 0, append "-" to output.
Append input_integer's numeric value represented in base 10 using only decimal digits to output.
Return output.
もしinput_integerが-999,999,999,999,999から999,999,999,999,999までの両端を含む範囲の整数でなければ、 シリアライズに失敗します。
outputに空文字を代入します。
もしinput_integerが0未満（0は除く）の場合、outputに「-」を追加します。
0から9までの数字だけをもちいて、input_integerを10進数で表現した結果を、outputに追加します。
outputを返します。
Given a decimal number as input_decimal, return an ASCII string suitable for use in an HTTP field value.
小数をinput_decimalとして与えると、HTTP フィールドの値として使用するのに適したASCII文字列を返します。
If input_decimal is not a decimal number, fail serialization.
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.
If input_decimal has more than 12 significant digits to the left of the decimal point after rounding, fail serialization.
Let output be an empty string.
If input_decimal is less than (but not equal to) 0, append "-" to output.
Append input_decimal's integer component represented in base 10 (using only decimal digits) to output; if it is zero, append "0".
Append "." to output.
If input_decimal's fractional component is zero, append "0" to output.
Otherwise, append the significant digits of input_decimal's fractional component represented in base 10 (using only decimal digits) to output.
Return output.
input_decimalが小数でない場合、シリアライズに失敗します。
input_decimalの小数点以下の桁数が3桁より多い場合、もっとも近い3桁に丸めます。 等距離の場合は偶数へ丸めます。
丸めを行ったあとに、小数点の右側に12桁より多くの桁がある場合は、シリアライズに失敗します。
outputに空文字列を代入します。
もしinput_decimalが0未満（0は除く）の場合、outputに「-」を追加します。
input_decimalの整数部を10進数で表した結果（0から9までの数字のみを使います）をoutputに追加します； つまり整数部がゼロの場合は「0」を追加します。
「.」をoutputに追加します。
input_decimalの小数部がゼロの場合、「0」をoutputに追加します。
そうでない場合、input_decimalの小数部をoutputに追加します（0から9までの数字のみを使います）。
outputを返します。
Given a String as input_string, return an ASCII string suitable for use in an HTTP field value.
文字列をinput_stringとして与えると、HTTPフィールドの値として使用するのに適したASCII文字列を返します。
Convert input_string into a sequence of ASCII characters; if conversion fails, fail serialization.
If input_string contains characters in the range %x00-1f or %x7f-ff (i.e., not in VCHAR or SP), fail serialization.
Let output be the string DQUOTE.
For each character char in input_string:
If char is "\" or DQUOTE:
Append "\" to output.
Append char to output.
Append DQUOTE to output.
Return output.
文字列をinput_stringとして与えると、HTTPフィールドの値として使用するのに適したASCII文字列を返します。
input_stringが%x00-1fまたは%x7f-ffの範囲の文字を含んでいる場合（つまり、VCHARやSPは含みません）、シリアライズに失敗します。
outputに文字列DQUOTEを代入します。
input_stringの各文字charについて：
charが「\」またはDQUOTEの場合
「\」をoutputに追加します。
charをoutputに追加します。
DQUOTEをoutputに追加します。
outputを返します。
Given a Token as input_token, return an ASCII string suitable for use in an HTTP field value.
トークンをinput_tokenとして与えると、HTTPフィールドの値として使用するのに適したASCII文字列を返します。
Convert input_token into a sequence of ASCII characters; if conversion fails, fail serialization.
If the first character of input_token is not ALPHA or "*", or the remaining portion contains a character not in tchar, ":", or "/", fail serialization.
Let output be an empty string.
Append input_token to output.
Return output.
input_tokenをASCII文字の列に変換します。変換に失敗した場合、シリアライズに失敗します。
input_tokenの最初の文字がALPHAまたは「*」でない場合、シリアライズに失敗します。 残りの文字がtchar、「:」「/」でない場合、シリアライズに失敗します。
outputに空文字列を代入します。
outputにinput_tokenを追加します。
outputを返します。
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文字列を返します。
If input_boolean is not a boolean, fail serialization.
Let output be an empty string.
Append "?" to output.
If input_boolean is true, append "1" to output.
If input_boolean is false, append "0" to output.
Return output.
input_booleanが真偽値でない場合、シリアライズに失敗します。
outputに空文字列を代入します。
「?」をoutputに追加します。
もしinput_booleanが真であれば、「1」をoutputに追加します。
もしinput_booleanが偽であれば、「0」をoutputに追加します。
outputを返します。
Given a Date as input_date, return an ASCII string suitable for use in an HTTP field value.
日付をinput_dateとして与えると、HTTPフィールドの値として使用するのに適したASCII文字列を返します。
Let output be "@".
Append to output the result of running Serializing an Integer with input_date (Section 4.1.4).
Return output.
outputに「@」を代入します。
input_dateを使用して整数のシリアライズ (Section 4.1.4)を実行した結果を出力に追加します。
outputを返します。
Given a sequence of Unicode code points as input_sequence, return an ASCII string suitable for use in an HTTP field value.
Unicodeコードポイント列をinput_sequenceとして与えると、HTTPフィールドの値として使用するのに適したASCII文字列を返します
If input_sequence is not a sequence of Unicode code points, fail serialization.
Let byte_array be the result of applying UTF-8 encoding (Section 3 of [UTF8]) to input_sequence. If encoding fails, fail serialization.
Let encoded_string be a string containing "%" followed by DQUOTE.
For each byte in byte_array:
If byte is %x25 ("%"), %x22 (DQUOTE), or in the ranges %x00-1f or %x7f-ff:
Otherwise, decode byte as an ASCII character and append the result to encoded_string.
Append DQUOTE to encoded_string.
Return encoded_string.
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 field value.
選択されたフィールドのフィールド値（そのフィールドが存在しない場合は空）と field_type（dictionary, list, item のいずれか）を表すバイト列を input_bytes として与え、 解析されたヘッダー値を返します。
Convert input_bytes into an ASCII string input_string; if conversion fails, fail parsing.
Discard any leading SP characters from input_string.
If field_type is "list", let output be the result of running Parsing a List (Section 4.2.1) with input_string.
If field_type is "dictionary", let output be the result of running Parsing a Dictionary (Section 4.2.2) with input_string.
If field_type is "item", let output be the result of running Parsing an Item (Section 4.2.3) with input_string.
Discard any leading SP characters from input_string.
If input_string is not empty, fail parsing.
Otherwise, return output.
input_bytesをASCII文字列input_stringに変換します。変換に失敗した場合、パースに失敗します。
input_stringの先頭のSPを無視します。.
もしfield_typeが「リスト」の場合、input_stringについて、 リストのパース（Section 4.2.1）を実行した結果を、outputに代入します。
もしfield_typeが「辞書」の場合、input_stringについて、 辞書のパース（Section 4.2.2）を実行した結果を、outputに代入します。
もしfield_typeが「アイテム」の場合、input_stringについて、 アイテムのパース（Section 4.2.3）を実行した結果を、outputに代入します。
input_stringの先頭のSPを無視します。.
もし、input_stringが空文字列でない場合は、パースに失敗します。
そうでなければ、outputを返します。
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 Section 5.2 of [HTTP]; this assures that the entire field value is processed correctly.
input_bytesを生成するとき、パーサーは、[HTTP]のSection 5.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 field 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, either the entire field value MUST be ignored (i.e., treated as if the field were not present in the section), or alternatively the complete HTTP message MUST be treated as malformed. This is intentionally strict to improve interoperability and safety, and field specifications that use Structured Fields are not allowed to loosen this requirement.
解析に失敗した場合、フィールド値全体を無視（つまり、セクションにフィールドが存在しないかのように扱う）しなければなりません（MUST）。あるいは、完全なHTTPメッセージを不正な形式として扱う必要があります（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は解析済みの値を除去するために変更されます。
Let members be an empty array.
While input_string is not empty:
Append the result of running Parsing an Item or Inner List (Section 4.2.1.1) with input_string to members.
Discard any leading OWS characters from input_string.
If input_string is empty, return members.
Consume the first character of input_string; if it is not ",", fail parsing.
Discard any leading OWS characters from input_string.
If input_string is empty, there is a trailing comma; fail parsing.
No structured data has been found; return members (which is empty).
membersに空の配列を代入します。
input_stringが空でない間:
input_stringに対して、アイテムまたはインナーリストのパース（Section 4.2.1.1）を実行した結果を、 membersに追加します。
input_stringの先頭のOWSを無視します。
もしinput_stringが空なら、membersを返します。
input_stringの最初の一文字を取り除きます。 取り除いた文字が「,」でない場合、パースに失敗します。
input_stringの先頭のOWSを無視します。
もしinput_stringが空なら、末尾にカンマがあります。その場合、パースに失敗します。
構造化データが見つからない場合、（空の）membersを返します。
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) タプルの配列のいずれかです。
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.
Return the result of running Parsing an Item (Section 4.2.3) with input_string.
もしinput_stringの先頭一文字が「(」の場合、 input_stringに対して、インナーリストのパース（Section 4.2.1.2）を実行した結果を返します。
input_stringに対して、 アイテムのパース(Section 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.
ASCII文字列をinput_stringとして与え、inner_listを(bare_item, parameters)の配列としたタプルを返します。 input_stringは解析済みの値を除去するために変更されます。
Consume the first character of input_string; if it is not "(", fail parsing.
Let inner_list be an empty array.
While input_string is not empty:
Discard any leading SP characters from input_string.
If the first character of input_string is ")":
Consume the first character of input_string.
Let parameters be the result of running Parsing Parameters (Section 4.2.3.2) with input_string.
Return the tuple (inner_list, parameters).
Let item be the result of running Parsing an Item (Section 4.2.3) with input_string.
Append item to inner_list.
If the first character of input_string is not SP or ")", fail parsing.
The end of the Inner List was not found; fail parsing.
input_stringの最初の一文字を取り除きます。 取り除いた文字が「(」でない場合、パースに失敗します。
inner_listに空配列を代入します。
input_stringが空でない間:
input_stringの先頭のSPを無視します。
もしinput_stringの先頭一文字が「)」である場合:
input_stringの最初の文字を取り除きます。
input_stringに対して、 パラメーターのパース（Section 4.2.3.2）を実行した結果を、parametersに代入します。
タプル(inner_list, parameters)を返します。
input_stringに対して、 アイテムのパース（Section 4.2.3）を実行した結果を、 itemに代入します。
itemをinner_listに追加します。
もしinput_stringの先頭一文字がSPまたは「)」でない場合、パースに失敗します。
インナーリストの終わりを見つけられなかったため、パースに失敗します。
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は解析済みの値を除去するために変更されます。
Let dictionary be an empty, ordered map.
While input_string is not empty:
Let this_key be the result of running Parsing a Key (Section 4.2.3.3) with input_string.
If the first character of input_string is "=":
Consume the first character of input_string.
Let member be the result of running Parsing an Item or Inner List (Section 4.2.1.1) with input_string.
Otherwise:
Let value be Boolean true.
Let parameters be the result of running Parsing Parameters (Section 4.2.3.2) with input_string.
Let member be the tuple (value, parameters).
If dictionary already contains a key this_key (comparing character for character), overwrite its value with member.
Otherwise, append key this_key with value member to dictionary.
Discard any leading OWS characters from input_string.
If input_string is empty, return dictionary.
Consume the first character of input_string; if it is not ",", fail parsing.
Discard any leading OWS characters from input_string.
If input_string is empty, there is a trailing comma; fail parsing.
No structured data has been found; return dictionary (which is empty).
dictionaryに空の順序付きマップを代入します。
input_stringが空でない間:
input_stringに対して、 キーのパース（Section 4.2.3.3）を実行した結果を、this_keyに代入します。
input_stringの最初の文字が"="である場合:
input_stringの最初の一文字を取り除きます。
input_stringに対して、 アイテムまたはインナーリストのパース（Section 4.2.1.1）を実行した結果を、 memberに代入します。
それ以外の場合:
valueに真偽値のtrueを代入します。
input_stringに対して、 パラメーターのパース（Section 4.2.3.2）を実行した結果を、 parametersに代入します。
タプル(value, parameters)をmemberに代入します。
dictionaryがすでにキーthis_keyを含んでいる場合（一文字ずつ比較）、その値をmemberで上書きします。
そうでなければ、キーthis_key値memberをdictionaryに追加します。
input_stringの先頭のOWSを無視します。
もしinput_stringが空ならdictionaryを返します。
input_stringの最初の一文字を取り除きます。 取り除いた文字が「,」でない場合、パースに失敗します。
input_stringの先頭のOWSを無視します。
もしinput_stringが空なら、末尾にカンマがあります。その場合、パースに失敗します。
構造化データが見つからない場合、（空の）dictionaryを返します。
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は解析済みの値を除去するために変更されます。
Let bare_item be the result of running Parsing a Bare Item (Section 4.2.3.1) with input_string.
Let parameters be the result of running Parsing Parameters (Section 4.2.3.2) with input_string.
Return the tuple (bare_item, parameters).
input_stringに対して、 裸のアイテムのパース（Section 4.2.3.1）を実行した結果を、 bare_itemに代入します。
input_stringに対して、 パラメーターのパース（Section 4.2.3.2）を実行した結果を、 parametersに代入します。
タプル(bare_item, parameters)を返します。
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は解析済みの値を除去するために変更されます。
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.
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.
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.
If the first character of input_string is ":", return the result of running Parsing a Byte Sequence (Section 4.2.7) with input_string.
If the first character of input_string is "?", return the result of running Parsing a Boolean (Section 4.2.8) with input_string.
If the first character of input_string is "@", return the result of running Parsing a Date (Section 4.2.9) with input_string.
If the first character of input_string is "%", return the result of running Parsing a Display String (Section 4.2.10) with input_string.
Otherwise, the item type is unrecognized; fail parsing.
もしinput_stringの最初の文字が「-」またはDIGITならば、 input_stringに対して、 整数または小数のパース（Section 4.2.4）を実行した結果を返します。
もしinput_stringの最初の文字がDQUOTEならば、 input_stringに対して、 文字列のパース（Section 4.2.5）を実行した結果を返します。
もしinput_stringの最初の文字がALPHAまたは「*」ならば、 input_stringに対して、 トークンのパース（Section 4.2.6 ）を実行した結果を返します。
もしinput_stringの最初の文字が「:」ならば、 input_stringに対して、 バイト列のパース（Section 4.2.7）を実行した結果を返します。
もしinput_stringの最初の文字が「?」ならば、 input_stringに対して、 真偽値のパース（Section 4.2.8）を実行した結果を返します。
もしinput_stringの最初の文字が「@」ならば、input_stringに対して、日付のパース（Section 4.2.9）を実行した結果を返します。
もしinput_stringの最初の文字が「%」ならば、input_stringに対して、表示文字列のパース（Section 4.2.10）を実行した結果を返します。
れ以外の場合アイテムの型を認識できないため、パースに失敗します。
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は解析済みの値を除去するために変更されます。
Let parameters be an empty, ordered map.
While input_string is not empty:
If the first character of input_string is not ";", exit the loop.
Consume the ";" character from the beginning of input_string.
Discard any leading SP characters from input_string.
Let param_key be the result of running Parsing a Key (Section 4.2.3.3) with input_string.
Let param_value be Boolean true.
If the first character of input_string is "=":
Consume the "=" character at the beginning of input_string.
Let param_value be the result of running Parsing a Bare Item (Section 4.2.3.1) with input_string.
If parameters already contains a key param_key (comparing character for character), overwrite its value with param_value.
Otherwise, append key param_key with value param_value to parameters.
Return parameters.
parametersに空の順序付きマップを代入します。
input_stringが空でない間:
もしinput_stringの最初の文字が「;」でなければ、ループを抜けます。
input_stringの先頭から「;」を取り除きます。
input_stringの先頭のSPを無視します。
input_stringに対して、 キーのパース（Section 4.2.3.3）を実行した結果を、param_keyに代入します。
param_valueに真偽値のtrueを代入します。
input_stringの最初の文字が"="である場合:
input_stringの先頭から「=」を取り除きます。
input_stringに対して、 裸のアイテムのパース（Section 4.2.3.1）を実行した結果を、param_valueに代入します。
parametersがすでにキーparam_keyを含んでいる場合（一文字ずつ比較）、その値をparam_valueで上書きします。
そうでなければ、キーparam_key値param_valueをparametersに追加します。
parametersを返します。
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は解析済みの値を除去するために変更されます。
If the first character of input_string is not lcalpha or "*", fail parsing.
Let output_string be an empty string.
While input_string is not empty:
If the first character of input_string is not one of lcalpha, DIGIT, "_", "-", ".", or "*", return output_string.
Let char be the result of consuming the first character of input_string.
Append char to output_string.
Return output_string.
もしinput_stringの先頭一文字がlcaphaまたは「*」でない場合、パースに失敗します。
output_stringに空文字列を代入します。
input_stringが空でない間:
もしinput_stringの先頭一文字がlcapha、DIGIT、「_」、「-」、「.」、「*」でない場合、output_stringを返します。
input_stringの先頭の文字を取り出した結果を、charに代入します。
charをoutput_stringに追加します。
output_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)の両方を解析し、対応する構造を返します。
Let type be "integer".
Let sign be 1.
Let input_number be an empty string.
If the first character of input_string is "-", consume it and set sign to -1.
If input_string is empty, there is an empty integer; fail parsing.
If the first character of input_string is not a DIGIT, fail parsing.
While input_string is not empty:
Let char be the result of consuming the first character of input_string.
If char is a DIGIT, append it to input_number.
Else, if type is "integer" and char is ".":
If input_number contains more than 12 characters, fail parsing.
Otherwise, append char to input_number and set type to "decimal".
Otherwise, prepend char to input_string, and exit the loop.
If type is "integer" and input_number contains more than 15 characters, fail parsing.
If type is "decimal" and input_number contains more than 16 characters, fail parsing.
If type is "integer":
Let output_number be an Integer that is the result of parsing input_number as an integer.
Otherwise:
If the final character of input_number is ".", fail parsing.
If the number of characters after "." in input_number is greater than three, fail parsing.
Let output_number be a Decimal that is the result of parsing input_number as a decimal number.
Let output_number be the product of output_number and sign.
Return output_number.
typeに「integer」を代入します。
signに1を代入します。
input_numberに空文字列を代入します。
もしinput_stringの先頭一文字が「-」の場合、「-」を取り除いて、signに-1を代入します。
もしinput_stringが空の場合、空の整数なので、パースに失敗します。
もしinput_stringの先頭一文字がDIGITでない場合、パースに失敗します。
input_stringが空でない間:
input_stringの最初の一文字を取り除き、charに代入します。
もし、charがDIGITの場合、input_numberにcharを追加します。
また、typeが「integer」で、charが「.」の場合:
もし、input_numberが12文字より長ければ、パースに失敗します。
そうでなければ、input_numberにcharを追加し、typeに「decimal」をセットします。
そうでない場合、input_stringの先頭にcharを追加し、ループを抜けます。
もしtypeが「integer」で、input_numberが15文字より長ければ、パースに失敗します。
もしtypeが「decimal」で、input_numberが16文字より長ければ、パースに失敗します。
typeが「integer」の場合:
input_numberを整数としてパースし、output_numberに代入します。
Otherwise:
もしinput_numberの最後の文字が「.」なら、パースに失敗します。
input_numberの「.」以降の文字数が3文字より長ければ、パースに失敗します。
input_numberを小数としてパースし、output_numberに代入します。
output_numberにoutput_numberとsignの積を代入します。
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は解析済みの値を除去するために変更されます。
Let output_string be an empty string.
If the first character of input_string is not DQUOTE, fail parsing.
Discard the first character of input_string.
While input_string is not empty:
Let char be the result of consuming the first character of input_string.
If char is a backslash ("\"):
If input_string is now empty, fail parsing.
Let next_char be the result of consuming the first character of input_string.
If next_char is not DQUOTE or "\", fail parsing.
Append next_char to output_string.
Else, if char is DQUOTE, return output_string.
Else, if char is in the range %x00-1f or %x7f-ff (i.e., it is not in VCHAR or SP), fail parsing.
Else, append char to output_string.
Reached the end of input_string without finding a closing DQUOTE; fail parsing.
output_stringに空文字列を代入します。
もしinput_stringの最初の文字がDQUOTEでなければ、パースに失敗します。
input_stringの最初の文字を取り除きます。
input_stringが空でない間:
input_stringの最初の一文字を取り除き、charに代入します。
charがバックスラッシュ（「\」）の場合：
もしinput_stringが空なら、パースに失敗します。
input_stringの最初の一文字を取り除き、next_charに代入します。
next_charがDQUOTEとバックスラッシュ（「\」）のどちらでもない場合、パースに失敗します。
output_stringにnext_charを追加します。
もしcharがDQUOTEなら、output_stringを返します。
もしcharが%00-1fまたは%7f-ffの範囲内にある場合（つまり、VCHARまたはSPの範囲外の場合）、パースに失敗します。
それ以外の場合、output_stringにcharを追加します。
DQUOTEが見つからないままinput_stringが空になった場合、パースに失敗します。
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は解析済みの値を除去するために変更されます。
If the first character of input_string is not ALPHA or "*", fail parsing.
Let output_string be an empty string.
While input_string is not empty:
If the first character of input_string is not in tchar, ":", or "/", return output_string.
Let char be the result of consuming the first character of input_string.
Append char to output_string.
Return output_string.
もしinput_stringの先頭一文字がALPHAまたは"*"でなければ、パースに失敗します。
output_stringに空文字列を代入します。
input_stringが空でない間:
input_stringの先頭一文字がtchar、「:」、または「/」でなければ、output_stringを返します。
input_stringの先頭の文字を取り出した結果を、charに代入します。
output_stringにcharを追加します。
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は解析済みの値を除去するために変更されます。
If the first character of input_string is not ":", fail parsing.
Discard the first character of input_string.
If there is not a ":" character before the end of input_string, fail parsing.
Let b64_content be the result of consuming content of input_string up to but not including the first instance of the character ":".
Consume the ":" character at the beginning of input_string.
If b64_content contains a character not included in ALPHA, DIGIT, "+", "/", and "=", fail parsing.
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.
Return binary_content.
もしinput_stringの最初の文字が「:」でない場合、パースに失敗します。
input_stringの最初の文字を取り除きます。
input_stringの終わりまでに「:」が見つからない場合、パースに失敗します。
input_stringの最初の「:」までを取り除き、その結果をb64_contentに代入します。ただし、「:」自体は含みません。
input_stringの最初の「:」を取り除きます。
もしb64_contentがALPHA、DIGIT、"+"、"/"、または"="以外の文字を含む場合、パースに失敗します。
必要に応じてパディングを合成しながら、b64_contentをbase64デコード[RFC4648]した結果をbinary_contentに代入します（以下の受信者の動作に関する要件に注意してください）。base64デコードに失敗した場合、解析は失敗します。
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の実装によっては、適切に"="パディングされていないエンコードされたデータを拒否することができないため([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は解析済みの値を除去するために変更されます。
If the first character of input_string is not "?", fail parsing.
Discard the first character of input_string.
If the first character of input_string matches "1", discard the first character, and return true.
If the first character of input_string matches "0", discard the first character, and return false.
No value has matched; fail parsing.
もしinput_stringの先頭一文字が「?」でない場合、パースに失敗します。
input_stringの最初の一文字を取り除きます。
もし、input_stringの先頭一文字が「1」である場合、input_stringの最初の一文字を取り除き、真を返します。
もし、input_stringの先頭一文字が「0」である場合、input_stringの最初の一文字を取り除き、偽を返します。
いずれの値にもマッチしない場合、パースに失敗します。
Given an ASCII string as input_string, return a Date. input_string is modified to remove the parsed value.
ASCII文字列をinput_stringとして与え、日付を返します。 input_stringは解析済みの値を除去するために変更されます。
If the first character of input_string is not "@", fail parsing.
Discard the first character of input_string.
Let output_date be the result of running Parsing an Integer or Decimal (Section 4.2.4) with input_string.
If output_date is a Decimal, fail parsing.
Return output_date.
もしinput_stringの先頭一文字が「@」でない場合、パースに失敗します。
input_stringの最初の一文字を取り除きます。
input_stringに対して、整数または小数のパース（Section 4.2.4）を実行した結果を、output_dateに代入します。
output_dateが小数の場合、パースに失敗します。
output_dateを返します。
Given an ASCII string as input_string, return a sequence of Unicode code points. input_string is modified to remove the parsed value.
ASCII文字列をinput_stringとして与え、Unicodeコードポイントの列を返します。 input_stringは解析済みの値を除去するために変更されます。
If the first two characters of input_string are not "%" followed by DQUOTE, fail parsing.
Discard the first two characters of input_string.
Let byte_array be an empty byte array.
While input_string is not empty:
Let char be the result of consuming the first character of input_string.
If char is in the range %x00-1f or %x7f-ff (i.e., it is not in VCHAR or SP), fail parsing.
If char is "%":
Let octet_hex be the result of consuming two characters from input_string. If there are not two characters, fail parsing.
If octet_hex contains characters outside the range %x30-39 or %x61-66 (i.e., it is not in 0-9 or lowercase a-f), fail parsing.
Let octet be the result of hex decoding octet_hex (Section 8 of [RFC4648]).
Append octet to byte_array.
If char is DQUOTE:
Otherwise, if char is not "%" or DQUOTE:
Let byte be the result of applying ASCII encoding to char.
Append byte to byte_array.
Reached the end of input_string without finding a closing DQUOTE; fail parsing.
input_stringの最初の2文字が"%"とそれに続くDQUOTEでない場合、解析に失敗します。
input_stringの最初の二文字を取り除きます。
byte_arrayに空のバイト配列を代入します。
input_stringが空でない間:
charをinput_stringの最初の文字を消費した結果とします。
charが%x00-1fまたは%x7f-ffの範囲内にある場合（つまり、VCHARまたはSPに含まれていない場合）、パースに失敗します。
もしcharが「%」ならば：
charがDQUOTEの場合:
それ以外の場合、charが"%"またはDQUOTEでない場合:
byteをcharにASCIIエンコーディングを適用した結果とします。
byteをbyte_arrayに追加します。
input_stringの終わりに達しても閉じるDQUOTEが見つからなかった場合、解析に失敗します。
IANA has added the following note to the "Hypertext Transfer Protocol (HTTP) Field Name Registry":
IANAは「Hypertext Transfer Protocol (HTTP) Field Name Registry」に次の注記を追加しました:
The "Structured Type" column indicates the type of the field (per RFC 9651), if any, and may be "Dictionary", "List", or "Item".
Note that field names beginning with characters other than ALPHA or "*" will not be able to be represented as a Structured Fields Token and therefore may be incompatible with being mapped into field values that refer to it.
「Structured Type」列は、フィールドのタイプ（RFC 9651に準拠）を示し、「Dictionary」、「List」、または「Item」のいずれかです。
ALPHAまたは"*"以外の文字で始まるフィールド名は、構造化フィールドトークンとして表現できないため、それに言及するフィールド値にマッピングすることと互換性がない可能性があることに注意してください。
A new column, "Structured Type", has been added to the registry.
新しい列「Structured Type」がレジストリに追加されました。
The indicated Structured Type for each existing registry entry listed in Table 1 has also been added.
また、Table 1に記載されている既存のレジストリエントリごとに示されたStructured Typeも追加されました。
| Field Name | Structured Type |
|---|---|
| Accept-CH | List |
| Cache-Status | List |
| CDN-Cache-Control | Dictionary |
| Cross-Origin-Embedder-Policy | Item |
| Cross-Origin-Embedder-Policy-Report-Only | Item |
| Cross-Origin-Opener-Policy | Item |
| Cross-Origin-Opener-Policy-Report-Only | Item |
| Origin-Agent-Cluster | Item |
| Priority | Dictionary |
| Proxy-Status | List |
| フィールド名 | 構造化型 |
|---|---|
| Accept-CH | List |
| Cache-Status | List |
| CDN-Cache-Control | Dictionary |
| Cross-Origin-Embedder-Policy | Item |
| Cross-Origin-Embedder-Policy-Report-Only | Item |
| Cross-Origin-Opener-Policy | Item |
| Cross-Origin-Opener-Policy-Report-Only | Item |
| Origin-Agent-Cluster | Item |
| Priority | Dictionary |
| Proxy-Status | List |
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フィールドを挿入する能力を持つ者が、構造化フィールドの意味を変更する可能性があります。場合によっては、これにより解析が失敗しますが、すべての状況で確実に失敗するわけではありません。
The Display String type can convey any possible Unicode code point without sanitization; for example, they might contain unassigned code points, control points (including NUL), or noncharacters. Therefore, applications consuming Display Strings need to consider strategies such as filtering or escaping untrusted content before displaying it. See [PRECIS] and [UNICODE-SECURITY].
表示文字列タイプは、未割り当てのコードポイント、制御ポイント（NULを含む）、または非文字を含む可能性があるため、サニタイズなしで任意のUnicodeコードポイントを伝えることができます。したがって、表示文字列を消費するアプリケーションは、表示する前に信頼できないコンテンツをフィルタリングまたはエスケープするなどの戦略を検討する必要があります。[PRECIS]および[UNICODE-SECURITY]を参照してください。
Earlier proposals for Structured Fields were based upon JSON [RFC8259]. However, constraining its use to make it suitable for HTTP 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.
実装者は、辞書とパラメーターが順序を保持するマップであることに注意する必要があります。一部のフィールドはこれらのデータタイプの順序に意味を持たないかもしれませんが、それを使用する必要があるアプリケーションで利用できるようにするために、順序を公開する必要があります。
Likewise, implementations should note that it's important to preserve the distinction between Tokens and Strings. While most programming languages have built-in 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 で定義されたデータタイプに厳密に限定されないように定義されています。例えば、10進数はより広範な入力を受け入れ、許可された値に丸めるように設計されています。
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.
実装は、各タイプに定義された最小値に従って、異なる構造のサイズを制限することが許可されています。構造が実装の制限を超える場合、その構造の解析またはシリアル化は失敗します。
This section uses the Augmented Backus-Naur Form (ABNF) notation [RFC5234] to illustrate the expected syntax of Structured Fields. However, it cannot be used to validate their syntax because it does not capture all requirements.
このセクションでは、拡張バッカス・ナウア形式（ABNF）表記 [RFC5234] を使用して構造化フィールドの期待される構文を示します。ただし、すべての要件を捉えていないため、その構文を検証するために使用することはできません。
This section is non-normative. If there is disagreement between the parsing algorithms and ABNF, the specified algorithms take precedence.
このセクションは規範的ではありません。解析アルゴリズムとABNFの間に不一致がある場合、指定されたアルゴリズムが優先されます。
sf-list = list-member *( OWS "," OWS list-member )
list-member = sf-item / inner-list
inner-list = "(" *SP [ sf-item *( 1*SP sf-item ) *SP ] ")"
parameters
parameters = *( ";" *SP parameter )
parameter = param-key [ "=" param-value ]
param-key = key
key = ( lcalpha / "*" )
*( lcalpha / DIGIT / "_" / "-" / "." / "*" )
lcalpha = %x61-7A ; a-z
param-value = bare-item
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-item = bare-item parameters
bare-item = sf-integer / sf-decimal / sf-string / sf-token
/ sf-binary / sf-boolean / sf-date / sf-displaystring
sf-integer = ["-"] 1*15DIGIT
sf-decimal = ["-"] 1*12DIGIT "." 1*3DIGIT
sf-string = DQUOTE *( unescaped / "%" / bs-escaped ) DQUOTE
sf-token = ( ALPHA / "*" ) *( tchar / ":" / "/" )
sf-binary = ":" base64 ":"
sf-boolean = "?" ( "0" / "1" )
sf-date = "@" sf-integer
sf-displaystring = "%" DQUOTE *( unescaped / "\" / pct-encoded )
DQUOTE
base64 = *( ALPHA / DIGIT / "+" / "/" ) *"="
unescaped = %x20-21 / %x23-24 / %x26-5B / %x5D-7E
bs-escaped = "\" ( DQUOTE / "\" )
pct-encoded = "%" lc-hexdig lc-hexdig
lc-hexdig = DIGIT / %x61-66 ; 0-9, a-f
sf-list = list-member *( OWS "," OWS list-member )
list-member = sf-item / inner-list
inner-list = "(" *SP [ sf-item *( 1*SP sf-item ) *SP ] ")"
parameters
parameters = *( ";" *SP parameter )
parameter = param-key [ "=" param-value ]
param-key = key
key = ( lcalpha / "*" )
*( lcalpha / DIGIT / "_" / "-" / "." / "*" )
lcalpha = %x61-7A ; a-z
param-value = bare-item
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-item = bare-item parameters
bare-item = sf-integer / sf-decimal / sf-string / sf-token
/ sf-binary / sf-boolean / sf-date / sf-displaystring
sf-integer = ["-"] 1*15DIGIT
sf-decimal = ["-"] 1*12DIGIT "." 1*3DIGIT
sf-string = DQUOTE *( unescaped / "%" / bs-escaped ) DQUOTE
sf-token = ( ALPHA / "*" ) *( tchar / ":" / "/" )
sf-binary = ":" base64 ":"
sf-boolean = "?" ( "0" / "1" )
sf-date = "@" sf-integer
sf-displaystring = "%" DQUOTE *( unescaped / "\" / pct-encoded )
DQUOTE
base64 = *( ALPHA / DIGIT / "+" / "/" ) *"="
unescaped = %x20-21 / %x23-24 / %x26-5B / %x5D-7E
bs-escaped = "\" ( DQUOTE / "\" )
pct-encoded = "%" lc-hexdig lc-hexdig
lc-hexdig = DIGIT / %x61-66 ; 0-9, a-f
This revision of the "Structured Field Values for HTTP" specification has made the following changes:
この「HTTPのための構造化フィールド値」仕様の改訂版では、以下の変更が行われました:
Added the Date Structured Type. (Section 3.3.7)
Stopped encouraging use of ABNF in definitions of new Structured Fields. (Section 2)
Moved ABNF to an informative appendix. (Appendix C)
Added a "Structured Type" column to the "Hypertext Transfer Protocol (HTTP) Field Name Registry". (Section 5)
Refined parse failure handling. (Section 4.2)
Added the Display String Structured Type. (Section 3.3.8)
Date構造化タイプを追加しました。(Section 3.3.7)
新しい構造化フィールドの定義にABNFの使用を推奨しなくなりました。(Section 2)
ABNFを情報提供の付録に移動しました。(Appendix C)
「Hypertext Transfer Protocol (HTTP) Field Name Registry」に「Structured Type」列を追加しました。(Section 5)
解析失敗の処理を改良しました。(Section 4.2)
Display String構造化タイプを追加しました。(Section 3.3.8)
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にも感謝します。