Internet Engineering Task Force (IETF) M. Nottingham
Request for Comments: 9651 Cloudflare
Obsoletes: 8941 P-H. Kamp
Category: Standards Track The Varnish Cache Project
ISSN: 2070-1721 September 2024
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.
これは、インターネット標準トラックドキュメントです。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9651で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Intentionally Strict Processing
1.2. Notational Conventions
2. Defining New Structured Fields
2.1. Example
2.2. Error Handling
2.3. Preserving Extensibility
2.4. Using New Structured Types in Extensions
3. Structured Data Types
3.1. Lists
3.1.1. Inner Lists
3.1.2. Parameters
3.2. Dictionaries
3.3. Items
3.3.1. Integers
3.3.2. Decimals
3.3.3. Strings
3.3.4. Tokens
3.3.5. Byte Sequences
3.3.6. Booleans
3.3.7. Dates
3.3.8. Display Strings
4. Working with Structured Fields in HTTP
4.1. Serializing Structured Fields
4.1.1. Serializing a List
4.1.2. Serializing a Dictionary
4.1.3. Serializing an Item
4.1.4. Serializing an Integer
4.1.5. Serializing a Decimal
4.1.6. Serializing a String
4.1.7. Serializing a Token
4.1.8. Serializing a Byte Sequence
4.1.9. Serializing a Boolean
4.1.10. Serializing a Date
4.1.11. Serializing a Display String
4.2. Parsing Structured Fields
4.2.1. Parsing a List
4.2.2. Parsing a Dictionary
4.2.3. Parsing an Item
4.2.4. Parsing an Integer or Decimal
4.2.5. Parsing a String
4.2.6. Parsing a Token
4.2.7. Parsing a Byte Sequence
4.2.8. Parsing a Boolean
4.2.9. Parsing a Date
4.2.10. Parsing a Display String
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Frequently Asked Questions
A.1. Why Not JSON?
Appendix B. Implementation Notes
Appendix C. ABNF
Appendix D. Changes from RFC 8941
Acknowledgements
Authors' Addresses
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]のセクション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 2 describes how to specify a Structured Field.
セクション2では、構造化されたフィールドを指定する方法について説明します。
Section 3 defines a number of abstract data types that can be used in Structured Fields.
セクション3では、構造化されたフィールドで使用できる多くの抽象データ型を定義します。
Those abstract types can be serialized into and parsed from HTTP field values using the algorithms described in Section 4.
これらの抽象型は、セクション4で説明されているアルゴリズムを使用して、HTTPフィールド値にシリアル化および解析できます。
This specification intentionally defines strict parsing and serialization behaviors using step-by-step algorithms; the only error handling defined is to fail the 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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This document uses the VCHAR, SP, DIGIT, ALPHA, and DQUOTE rules from [RFC5234] to specify characters and/or their corresponding ASCII bytes, depending on context. It uses the tchar and OWS rules from [HTTP] for the same purpose.
このドキュメントでは、[RFC5234]のVCHAR、SP、DIGIT、ALPHA、およびDQUOTEルールを使用して、コンテキストに応じて文字および/または対応するASCIIバイトを指定します。同じ目的で[http]のtcharおよびowsルールを使用します。
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フィールドから解析する場合、実装には、アルゴリズムに従うことと見分けがつかない動作が必要です。
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フィールドへのシリアル化の場合、アルゴリズムはそれらを生成する推奨される方法を定義します。実装は、セクション4.2で説明されている解析アルゴリズムによって出力がまだ正しく処理される限り、指定された動作によって異なる場合があります。
To specify an HTTP field as a Structured Field, its authors need to:
HTTPフィールドを構造化されたフィールドとして指定するには、著者は以下を行う必要があります。
* Normatively reference this specification. Recipients and generators of the field need to know that the requirements of this document are in effect.
* この仕様を参照してください。フィールドの受信者とジェネレーターは、このドキュメントの要件が有効であることを知る必要があります。
* Identify whether the field is a Structured Header (i.e., it can only be used in the header section -- the common case), a Structured Trailer (only in the trailer section), or a Structured Field (both).
* フィールドが構造化されたヘッダーであるかどうか（つまり、ヘッダーセクション（一般的なケース）でのみ使用できます）、構造化されたトレーラー（トレーラーセクションでのみ）、または構造化されたフィールド（両方）を特定します。
* Specify the type of the field value; either List (Section 3.1), Dictionary (Section 3.2), or Item (Section 3.3).
* フィールド値のタイプを指定します。リスト（セクション3.1）、辞書（セクション3.2）、またはアイテム（セクション3.3）。
* Define the semantics of the field value.
* フィールド値のセマンティクスを定義します。
* Specify any additional constraints upon the field value, as well as the consequences when those constraints are violated.
* フィールド値に追加の制約を指定し、それらの制約が違反された場合の結果を指定します。
Typically, this means that a field definition will specify the top-level type -- List, Dictionary, or Item -- and then define its allowable types and constraints upon them. For example, a header defined as a List might have all Integer members, or a mix of types; a header defined as an Item might allow only Strings, and additionally only strings beginning with the letter "Q", or strings in lowercase. Likewise, Inner Lists (Section 3.1.1) are only valid when a field definition explicitly allows them.
通常、これは、フィールド定義がトップレベルのタイプ、リスト、辞書、またはアイテムを指定し、その許容型とそれらに制約を定義することを意味します。たとえば、リストとして定義されたヘッダーには、すべての整数メンバー、またはタイプの組み合わせがある場合があります。アイテムとして定義されたヘッダーは、文字列のみを許可し、さらに「Q」または小文字の文字列から始まる文字列のみを可能にする場合があります。同様に、内側のリスト（セクション3.1.1）は、フィールド定義がそれらを明示的に許可する場合にのみ有効です。
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].
表示文字列タイプを使用するフィールドは、許容可能なユニコードコードポイントを慎重に指定することをお勧めします。たとえば、[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.
仕様は、フィールド名を「構造化されたヘッダー名」、「構造化されたトレーラー名」、または「構造化されたフィールド名」と呼ぶことができます。同様に、必要に応じて、そのフィールド値を「構造化されたヘッダー値」、「構造化されたトレーラー値」、または「構造化されたフィールド値」と呼ぶことができます。
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
42. foo-exampleヘッダーフィールド
The Foo-Example HTTP header field conveys information about how much Foo the message has.
Foo-example HTTPヘッダーフィールドは、メッセージがどれだけのfooを持っているかについての情報を伝えます。
Foo-Example is an Item Structured Header Field [RFC9651]. Its value MUST be an Integer (Section 3.3.1 of [RFC9651]).
foo-exampleは、アイテム構造ヘッダーフィールド[RFC9651]です。その値は整数でなければなりません（[RFC9651]のセクション3.3.1）。
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.
その値はメッセージ内のFOOの量を示し、包括的0〜10の間でなければなりません。他の値は、ヘッダーフィールド全体を無視する必要があります。
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.
* キーが「foorl」であり、その値が文字列であるパラメーター（[rfc9651]のセクション3.3.3）は、メッセージのためにfoo urlを伝えます。処理要件については、以下を参照してください。
"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.
「foorl」には、uri-referenceが含まれています（[RFC3986]のセクション4.1）。その値が有効なURI参照でない場合、ヘッダーフィールド全体を無視する必要があります。その値が相対的な参照（[RFC3986]のセクション4.2）である場合、使用する前に解決する必要があります（[RFC3986]セクション5）。
For example:
例えば：
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).
解析が失敗すると、フィールド全体が無視されます（セクション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で定義されているものに限定されます。たとえば、定義がこのドキュメントを参照するフィールドは、日付タイプ（セクション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への参照で定義されたフィールドは、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.
たとえば、フィールドインスタンスには、そのフィールドの定義が日付に対応していない場合でも、構文的に有効な日付（セクション3.3.7）を含む場合があります。RFC 8941に基づく実装は、その仕様で定義されていないため、このようなフィールドインスタンスの解析に失敗します。その実装がこの仕様にアップグレードされた場合、解析は成功するようになります。場合によっては、結果の日付値はフィールド固有のロジックによって拒否されますが、それ以外の場合は無視されるフィールドの値（拡張パラメーターなど）は検出されず、その後フィールドが受け入れられ処理される場合があります。
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フィールドにシリアル化されている方法の簡単な説明と例を示している抽象型の概要を説明します。セクション4では、それらがどのように解析され、テキストHTTPフィールドにシリアル化されているかの詳細を指定します。
In summary:
要約すれば：
* There are three top-level types that an HTTP field can be defined as: Lists, Dictionaries, and Items.
* HTTPフィールドがリスト、辞書、およびアイテムとして定義できる3つのトップレベルのタイプがあります。
* Lists and Dictionaries are containers; their members can be Items or Inner Lists (which are themselves arrays of Items).
* リストと辞書はコンテナです。メンバーは、アイテムまたは内部リスト（それ自体がアイテムの配列です）にすることができます。
* Both Items and Inner Lists can be Parameterized with key/value pairs.
* アイテムと内部リストの両方を、キー/値のペアでパラメーター化できます。
Lists are arrays of zero or more members, each of which can be an Item (Section 3.3) or an Inner List (Section 3.1.1), both of which can be Parameterized (Section 3.1.2).
リストはゼロ以上のメンバーの配列であり、それぞれがアイテム（セクション3.3）または内部リスト（セクション3.1.1）であり、どちらもパラメーター化できます（セクション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
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]のセクション5.3に従って、同じヘッダーまたはトレーラーセクションの複数の行にメンバーを分割できることに注意してください。たとえば、以下は同等です。
Example-List: sugar, tea, rum
and
そしてと及びアンド並びに且つ兼又共それですると亦だからそれからはたまた
Example-List: sugar, tea
Example-List: rum
However, individual members of a List cannot be safely split between lines; see Section 4.2 for details.
ただし、リストの個々のメンバーをライン間で安全に分割することはできません。詳細については、セクション4.2を参照してください。
Parsers MUST support Lists containing at least 1024 members. Field specifications can constrain the types and cardinality of individual List values as they require.
パーサーは、少なくとも1024人のメンバーを含むリストをサポートする必要があります。フィールド仕様は、必要に応じて個々のリスト値のタイプとカーディナリティを制約することができます。
An Inner List is an array of zero or more Items (Section 3.3). Both the individual Items and the Inner List itself can be Parameterized (Section 3.1.2).
内側のリストは、ゼロ以上のアイテムの配列です（セクション3.3）。個々のアイテムと内部リスト自体の両方をパラメーター化できます（セクション3.1.2）。
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"), ()
Note that the last member in this example is an empty Inner List.
この例の最後のメンバーは空の内側リストであることに注意してください。
A header field whose value is defined as a List of Inner Lists with Parameters at both levels could look like:
両方のレベルでパラメーターを持つ内部リストのリストとして値が定義されているヘッダーフィールドは次のようになります。
Example-List: ("foo"; a=1;b=2);lvl=5, ("bar" "baz");lvl=1
Parsers MUST support Inner Lists containing at least 256 members. Field specifications can constrain the types and cardinality of individual Inner List members as they require.
パーサーは、少なくとも256人のメンバーを含む内部リストをサポートする必要があります。フィールド仕様は、必要に応じて個々の内部リストメンバーのタイプとカーディナリティを制約できます。
Parameters are an ordered map of key-value pairs that are associated with an Item (Section 3.3) or Inner List (Section 3.1.1). The keys are unique within the scope of the Parameters they occur within, and the values are bare items (i.e., they themselves cannot be parameterized; see Section 3.3).
パラメーターは、アイテム（セクション3.3）または内部リスト（セクション3.1.1）に関連付けられているキー価値ペアの順序付けられたマップです。キーは、内部で発生するパラメーターの範囲内で一意であり、値は裸のアイテムです（つまり、パラメーター化することはできません。セクション3.3を参照）。
Implementations MUST provide access to Parameters both by index and by key. Specifications MAY use either means of accessing them.
実装は、インデックスとキーの両方でパラメーターへのアクセスを提供する必要があります。仕様は、それらにアクセスする手段のいずれかを使用する場合があります。
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
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:
値がブール値であるパラメーター（セクション3.3.6を参照）Trueは、シリアル化されたときにその値を省略する必要があります。たとえば、ここでの「A」パラメーターは真であり、「B」パラメーターはfalseです。
Example-Integer: 1; a; b=?0
Note that this requirement is only on serialization; parsers are still required to correctly handle the true value when it appears in a parameter.
この要件はシリアル化のみにあることに注意してください。パーサーは、パラメーターに表示されるときに真の値を正しく処理するために必要です。
Parsers MUST support at least 256 parameters on an Item or Inner List, and support parameter keys with at least 64 characters. Field specifications can constrain the order of individual parameters, as well as their values' types as required.
パーサーは、アイテムまたは内部リストで少なくとも256のパラメーターをサポートし、少なくとも64文字のパラメーターキーをサポートする必要があります。フィールド仕様は、個々のパラメーターの順序と、必要に応じてその値のタイプを制約することができます。
Dictionaries are ordered maps of key-value pairs, where the keys are short textual strings and the values are Items (Section 3.3) or arrays of Items, both of which can be Parameterized (Section 3.1.2). There can be zero or more members, and their keys are unique in the scope of the Dictionary they occur within.
辞書は、キーと値が短いテキスト文字列であり、値はアイテム（セクション3.3）またはアイテムの配列であり、どちらもパラメーター化できます（セクション3.1.2）であるキー値ペアの順序付けられたマップです。ゼロ以上のメンバーが存在する場合があり、そのキーは、内部で発生する辞書の範囲でユニークです。
Implementations MUST provide access to Dictionaries both by index and by key. Specifications MAY use either means of accessing the members.
実装は、インデックスとキーの両方で辞書へのアクセスを提供する必要があります。仕様は、メンバーへのアクセス手段のいずれかを使用する場合があります。
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.
通常、フィールド仕様は、個々のメンバーの許可されたタイプをキーで指定することと、その存在が必要かオプションであるかを指定することにより、辞書のセマンティクスを定義します。受信者は、フィールドの仕様が具体的に許可されない限り、キーが未定義または不明のメンバーを無視する必要があります。
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フィールドとしてシリアル化されると、メンバーはシリアル化として注文され、オプションの白人を備えたコンマによって分離されます。メンバーキーには大文字の文字が含まれていません。キーと値は "="（Whitespaceなし）で区切られています。例えば：
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.
この例では、最終的な「=」はバイトシーケンスが含まれているためであることに注意してください。セクション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:
値がブール値であるメンバー（セクション3.3.6を参照）Trueは、シリアル化されたときにその値を省略する必要があります。たとえば、ここでは「b」と「c」の両方が真です。
Example-Dict: a=?0, b, c; foo=bar
Note that this requirement is only on serialization; parsers are still required to correctly handle the true Boolean value when it appears in Dictionary values.
この要件はシリアル化のみにあることに注意してください。パーサーは、辞書値に表示されるときに真のブール値を正しく処理するために必要です。
A Dictionary with a member whose value is an Inner List of Tokens:
価値がトークンの内側リストであるメンバーの辞書：
Example-Dict: rating=1.5, feelings=(joy sadness)
A Dictionary with a mix of Items and Inner Lists, some with parameters:
アイテムと内側のリストが組み合わされた辞書、パラメーターのあるものもあります。
Example-Dict: a=(1 2), b=3, c=4;aa=bb, d=(5 6);valid
Note that Dictionaries can have their members split across multiple lines of the same header or trailer section; for example, the following are equivalent:
辞書は、同じヘッダーまたはトレーラーセクションの複数の行にメンバーを分割できることに注意してください。たとえば、以下は同等です。
Example-Dict: foo=1, bar=2
and
そしてと及びアンド並びに且つ兼又共それですると亦だからそれからはたまた
Example-Dict: foo=1
Example-Dict: bar=2
However, individual members of a Dictionary cannot be safely split between lines; see Section 4.2 for details.
ただし、辞書の個々のメンバーは、ライン間で安全に分割することはできません。詳細については、セクション4.2を参照してください。
Parsers MUST support Dictionaries containing at least 1024 key/value pairs and keys with at least 64 characters. Field specifications can constrain the order of individual Dictionary members, as well as their values' types as required.
パーサーは、少なくとも1024個のキー/値のペアと少なくとも64文字のキーを含む辞書をサポートする必要があります。フィールド仕様は、個々の辞書メンバーの順序と、必要に応じて値のタイプを制約することができます。
An Item can be an Integer (Section 3.3.1), a Decimal (Section 3.3.2), a String (Section 3.3.3), a Token (Section 3.3.4), a Byte Sequence (Section 3.3.5), a Boolean (Section 3.3.6), or a Date (Section 3.3.7). It can have associated parameters (Section 3.1.2).
アイテムは、整数（セクション3.3.1）、小数（セクション3.3.2）、文字列（セクション3.3.3）、トークン（セクション3.3.4）、バイトシーケンス（セクション3.3.5）です。ブール（セクション3.3.6）、または日付（セクション3.3.7）。関連するパラメーターを持つことができます（セクション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
or with parameters:
またはパラメーターを使用して：
Example-Integer: 5; foo=bar
Integers have a range of -999,999,999,999,999 to 999,999,999,999,999 inclusive (i.e., up to fifteen digits, signed), for IEEE 754 compatibility [IEEE754].
整数は、IEEE 754適合性[IEEE754]の場合、-999,999,999,999から999,99,99,99,99,999（つまり、最大15桁、署名、署名）を持っています。
For example:
例えば：
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桁を超える整数は、さまざまな方法でサポートできます。たとえば、文字列（セクション3.3.3）、バイトシーケンス（セクション3.3.5）、またはスケーリング係数として機能する整数のパラメーターを使用します。
While it is possible to serialize Integers with leading zeros (e.g., "0002", "-01") and signed zero ("-0"), these distinctions may not be preserved by implementations.
主要なゼロ（「0002」、「-01」など）で整数をシリアル化し、ゼロ（「-0」）に署名することは可能ですが、これらの区別は実装によって保存されない場合があります。
Note that commas in Integers are used in this section's prose only for readability; they are not valid in the wire format.
このセクションの散文では、読みやすさのためにのみ使用されることに注意してください。それらはワイヤ形式では無効です。
Decimals are numbers with an integer and a fractional component. The integer component has at most 12 digits; the fractional component has at most three digits.
デシマルは、整数と分数コンポーネントを持つ数値です。整数コンポーネントには、最大12桁があります。分数コンポーネントには、最大3桁があります。
For example, a header whose value is defined as a Decimal could look like:
たとえば、値が小数として定義されているヘッダーは次のようになります。
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.
シリアル化アルゴリズム（セクション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.
文字列は、ゼロ以上の印刷可能な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コンテンツを伝達する必要がある場合、ディスプレイ文字列（セクション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"
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と「\」のみを逃れることができます。「\」の後の他の文字は、解析を失敗させる必要があります。
Parsers MUST support Strings (after any decoding) with at least 1024 characters.
パーサーは、少なくとも1024文字の文字列（任意のデコード後）をサポートする必要があります。
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.
トークンは、アルファベットの文字または「*」で始まる短いテキスト語であり、その後にゼロから多くのトークン文字が続きます。/"文字。
For example:
例えば：
Example-Token: foo123/456
Parsers MUST support Tokens with at least 512 characters.
パーサーは、少なくとも512文字のトークンをサポートする必要があります。
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.
バイトシーケンスは、構造化されたフィールドで伝達できます。
When serialized in a textual HTTP field, a Byte Sequence is delimited with colons and encoded using base64 ([RFC4648], Section 4). For example:
テキストHTTPフィールドでシリアル化すると、バイトシーケンスがコロンで区切られ、Base64（[RFC4648]、セクション4）を使用してエンコードされます。例えば：
Example-ByteSequence: :cHJldGVuZCB0aGlzIGlzIGJpbmFyeSBjb250ZW50Lg==:
Parsers MUST support Byte Sequences with at least 16384 octets after decoding.
パーサーは、デコード後少なくとも16384オクテットのバイトシーケンスをサポートする必要があります。
Boolean values can be conveyed in Structured Fields.
ブール値は、構造化されたフィールドで伝達できます。
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フィールドでシリアル化すると、ブール値は主要な「？」で示されています。キャラクターに続いて、真の値の「1」またはfalseの「0」が続きます。例えば：
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.
辞書（セクション3.2）およびパラメーター（セクション3.1.2）値では、boolean trueは値を省略することで示されることに注意してください。
Date values can be conveyed in Structured Fields.
日付値は、構造化されたフィールドで伝達できます。
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
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年のすべての日を含む日付をサポートする必要があります（すなわち、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.
文字列はゼロ以上の文字で構成されているという点で、文字列に似ていますが、文字列とは異なり、ユニコードスカラー値（つまり、サロゲートを除くすべてのユニコードコードポイント）を許可します。
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以外のコンテンツを携帯する必要がある場合があります。Unicodeには処理の考慮事項（正規化など）とセキュリティの考慮事項（例：ホモグラフ攻撃）があるため、文字列（セクション3.3.3）またはトークン（セクション3.3.4）が適切である状況で使用することはお勧めしません。正しく処理するのをより困難にします。
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."
See Section 6 for additional security considerations when handling Display Strings.
ディスプレイ文字列を処理する際の追加のセキュリティに関する考慮事項については、セクション6を参照してください。
This section defines how to serialize and parse the abstract types defined by Section 3 into textual HTTP field values and other encodings compatible with them (e.g., in HTTP/2 [HTTP/2] before compression with HPACK [HPACK]).
このセクションでは、セクション3で定義された抽象型をテキストHTTPフィールド値とそれらと互換性のあるその他のエンコーディングにシリアル化して解析する方法を定義します（例：HPACK [HPACK]）と圧縮する前に、HTTP/2 [HTTP/2]）。
Given a structure defined in this specification, return an ASCII string suitable for use in an HTTP field value.
この仕様で定義された構造が与えられた場合、HTTPフィールド値で使用するのに適したASCII文字列を返します。
1. If the structure is a Dictionary or List and its value is empty (i.e., it has no members), do not serialize the field at all (i.e., omit both the field-name and field-value).
1. 構造が辞書またはリストであり、その値が空である場合（つまり、メンバーがいません）、フィールドをまったくシリアル化しないでください（つまり、フィールド名とフィールド値の両方を省略します）。
2. If the structure is a List, let output_string be the result of running Serializing a List (Section 4.1.1) with the structure.
2. 構造がリストの場合、output_stringを構造を使用してリスト（セクション4.1.1）をシリアル化する結果とします。
3. Else, if the structure is a Dictionary, let output_string be the result of running Serializing a Dictionary (Section 4.1.2) with the structure.
3. それ以外の場合、構造が辞書の場合、output_stringを構造で辞書（セクション4.1.2）をシリアル化して実行した結果とします。
4. Else, if the structure is an Item, let output_string be the result of running Serializing an Item (Section 4.1.3) with the structure.
4. それ以外の場合、構造がアイテムである場合、output_stringを構造を使用してアイテム（セクション4.1.3）をシリアル化する結果とします。
5. Else, fail serialization.
5. それ以外の場合、シリアル化に失敗します。
6. Return output_string converted into an array of bytes, using ASCII encoding [RFC0020].
6. Return 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.
（member_value、パラメーター）のタプルの配列がinput_listとしてタプルを与えられている場合、HTTPフィールド値での使用に適したASCII文字列を返します。
1. Let output be an empty string.
1. 出力を空の文字列とします。
2. For each (member_value, parameters) of input_list:
2. input_listの各（member_value、パラメーター）：
1. If member_value is an array, append the result of running Serializing an Inner List (Section 4.1.1.1) with (member_value, parameters) to output.
1. member_valueが配列の場合、（member_value、パラメーター）を使用して内側リスト（セクション4.1.1.1）をシリアル化して出力を実行した結果を追加します。
2. Otherwise, append the result of running Serializing an Item (Section 4.1.3) with (member_value, parameters) to output.
2. それ以外の場合は、（Member_Value、パラメーター）を使用してアイテム（セクション4.1.3）をシリアル化した結果を出力に追加します。
3. If more member_values remain in input_list:
3. より多くのmember_valuesがinput_listに残っている場合：
1. Append "," to output.
1. "、"、outputを追加します。
2. Append a single SP to output.
2. 1つのSPを出力に追加します。
3. Return output.
3. 返品出力。
Given an array of (member_value, parameters) tuples as inner_list, and parameters as list_parameters, return an ASCII string suitable for use in an HTTP field value.
（member_value、パラメーター）のアレイがinner_listとしてタプル、およびlist_parametersとしてパラメーターの配列が与えられている場合、HTTPフィールド値で使用するのに適したASCII文字列を返します。
1. Let output be the string "(".
1. 出力を文字列 "（"とします。
2. For each (member_value, parameters) of inner_list:
2. inner_listの各（member_value、パラメーター）：
1. Append the result of running Serializing an Item (Section 4.1.3) with (member_value, parameters) to output.
1. （Member_Value、パラメーター）を使用してアイテム（セクション4.1.3）を実行した結果を出力します。
2. If more values remain in inner_list, append a single SP to output.
2. より多くの値がinner_listに残っている場合は、1つのspを出力に追加します。
3. Append ")" to output.
3. 出力に "）"を追加します。
4. Append the result of running Serializing Parameters (Section 4.1.1.2) with list_parameters to output.
4. List_Parametersを使用してシリアル化パラメーター（セクション4.1.1.2）を実行した結果を出力します。
5. Return output.
5. 返品出力。
Given an ordered Dictionary as input_parameters (each member having a param_key and a param_value), return an ASCII string suitable for use in an HTTP field value.
input_parametersとして順序付けられた辞書（各メンバーがparam_keyとparam_valueを持っている）が与えられた場合、HTTPフィールド値で使用するのに適したASCII文字列を返します。
1. Let output be an empty string.
1. 出力を空の文字列とします。
2. For each param_key with a value of param_value in input_parameters:
2. input_parametersのparam_valueの値を持つ各param_keyについて：
1. Append ";" to output.
1. append ";"出力へ。
2. Append the result of running Serializing a Key (Section 4.1.1.3) with param_key to output.
2. キー（セクション4.1.1.3）をシリアル化してPARAM_KEYを使用して出力を実行した結果を追加します。
3. If param_value is not Boolean true:
3. param_valueがブールのtrueでない場合：
1. Append "=" to output.
1. "="を出力に追加します。
2. Append the result of running Serializing a bare Item (Section 4.1.3.1) with param_value to output.
2. Param_Valueを出力して、ベアアイテム（セクション4.1.3.1）をシリアル化した結果を追加します。
3. Return output.
3. 返品出力。
Given a key as input_key, return an ASCII string suitable for use in an HTTP field value.
input_keyとしてキーが与えられた場合、HTTPフィールド値で使用するのに適したASCII文字列を返します。
1. Convert input_key into a sequence of ASCII characters; if conversion fails, fail serialization.
1. input_keyをASCII文字のシーケンスに変換します。変換が失敗した場合、シリアル化に失敗します。
2. If input_key contains characters not in lcalpha, DIGIT, "_", "-", ".", or "*", fail serialization.
2. input_keyがlcalpha、digit、 "_"、 " - "、 "、"、または "*"にない文字が含まれている場合、フェイルシリアル化。
3. If the first character of input_key is not lcalpha or "*", fail serialization.
3. input_keyの最初の文字がlcalphaまたは "*"でない場合は、シリアル化に失敗します。
4. Let output be an empty string.
4. 出力を空の文字列とします。
5. Append input_key to output.
5. input_keyを出力に追加します。
6. Return output.
6. 返品出力。
Given an ordered Dictionary as input_dictionary (each member having a member_key and a tuple value of (member_value, parameters)), return an ASCII string suitable for use in an HTTP field value.
input_dictionaryとして順序付けられた辞書（各メンバーがmember_keyを持ち、（member_value、パラメーター、パラメーター）のタプル値を持つ）を与えられ、HTTPフィールド値で使用するのに適したASCII文字列を返します。
1. Let output be an empty string.
1. 出力を空の文字列とします。
2. For each member_key with a value of (member_value, parameters) in input_dictionary:
2. input_dictionaryの（member_value、パラメーター）の値を持つ各member_key：
1. Append the result of running Serializing a Key (Section 4.1.1.3) with member's member_key to output.
1. メンバーのMember_Keyを使用してキー（セクション4.1.1.3）をシリアル化して実行した結果を出力します。
2. If member_value is Boolean true:
2. member_valueがboolean trueの場合：
1. Append the result of running Serializing Parameters (Section 4.1.1.2) with parameters to output.
1. シリアル化パラメーターを実行した結果（セクション4.1.1.2）を出力のパラメーターで追加します。
3. Otherwise:
3. さもないと：
1. Append "=" to output.
1. "="を出力に追加します。
2. If member_value is an array, append the result of running Serializing an Inner List (Section 4.1.1.1) with (member_value, parameters) to output.
2. member_valueが配列の場合、（member_value、パラメーター）を使用して内側リスト（セクション4.1.1.1）をシリアル化して出力を実行した結果を追加します。
3. Otherwise, append the result of running Serializing an Item (Section 4.1.3) with (member_value, parameters) to output.
3. それ以外の場合は、（Member_Value、パラメーター）を使用してアイテム（セクション4.1.3）をシリアル化した結果を出力に追加します。
4. If more members remain in input_dictionary:
4. より多くのメンバーがinput_dictionaryに残っている場合：
1. Append "," to output.
1. "、"、outputを追加します。
2. Append a single SP to output.
2. 1つのSPを出力に追加します。
3. Return output.
3. 返品出力。
Given an Item as bare_item and Parameters as item_parameters, return an ASCII string suitable for use in an HTTP field value.
bare_itemとしての項目とitem_parametersとしてパラメーターを与えられると、HTTPフィールド値での使用に適したASCII文字列を返します。
1. Let output be an empty string.
1. 出力を空の文字列とします。
2. Append the result of running Serializing a Bare Item (Section 4.1.3.1) with bare_item to output.
2. BARE_ITEMを使用してBAREアイテム（セクション4.1.3.1）をシリアル化して出力を実行した結果を追加します。
3. Append the result of running Serializing Parameters (Section 4.1.1.2) with item_parameters to output.
3. Item_Parametersを使用してシリアル化パラメーター（セクション4.1.1.2）を実行した結果を出力します。
4. Return output.
4. 返品出力。
Given an Item as input_item, return an ASCII string suitable for use in an HTTP field value.
input_itemとしてアイテムを与えられた場合、HTTPフィールド値で使用するのに適したASCII文字列を返します。
1. If input_item is an Integer, return the result of running Serializing an Integer (Section 4.1.4) with input_item.
1. input_Itemが整数の場合、integer（セクション4.1.4）をinput_Itemでシリアル化した結果を返します。
2. If input_item is a Decimal, return the result of running Serializing a Decimal (Section 4.1.5) with input_item.
2. input_itemが小数点以下である場合、入力_ITEMを使用して小数（セクション4.1.5）をシリアル化した結果を返します。
3. If input_item is a String, return the result of running Serializing a String (Section 4.1.6) with input_item.
3. input_itemが文字列の場合、input_itemを使用して文字列（セクション4.1.6）をシリアル化した結果を返します。
4. If input_item is a Token, return the result of running Serializing a Token (Section 4.1.7) with input_item.
4. input_Itemがトークンの場合、input_itemを使用してトークン（セクション4.1.7）をシリアル化した結果を返します。
5. If input_item is a Byte Sequence, return the result of running Serializing a Byte Sequence (Section 4.1.8) with input_item.
5. input_Itemがバイトシーケンスの場合、input_itemを使用してバイトシーケンス（セクション4.1.8）をシリアル化した結果を返します。
6. If input_item is a Boolean, return the result of running Serializing a Boolean (Section 4.1.9) with input_item.
6. input_itemがブール値の場合、input_itemを使用してブール（セクション4.1.9）をシリアル化した結果を返します。
7. If input_item is a Date, return the result of running Serializing a Date (Section 4.1.10) with input_item.
7. input_itemが日付の場合、input_itemを使用して日付（セクション4.1.10）をシリアル化した結果を返します。
8. If input_item is a Display String, return the result of running Serializing a Display String (Section 4.1.11) with input_item.
8. input_Itemが表示文字列の場合、input_itemを使用してディスプレイ文字列（セクション4.1.11）をシリアル化した結果を返します。
9. Otherwise, fail serialization.
9. それ以外の場合は、シリアル化に失敗します。
Given an Integer as input_integer, return an ASCII string suitable for use in an HTTP field value.
input_integerとしての整数を考えると、HTTPフィールド値で使用するのに適したASCII文字列を返します。
1. If input_integer is not an integer in the range of -999,999,999,999,999 to 999,999,999,999,999 inclusive, fail serialization.
1. input_integerが-999,999,999,999,999〜999,999,999,99,999の範囲の範囲の整数でない場合、フェイルシリアル化。
2. Let output be an empty string.
2. 出力を空の文字列とします。
3. If input_integer is less than (but not equal to) 0, append "-" to output.
3. input_integerが0未満の場合（ただし等しくない）場合、「 - 」を出力に追加します。
4. Append input_integer's numeric value represented in base 10 using only decimal digits to output.
4. 入力_Integerの数値は、出力に10進数のみを使用して、ベース10で表される数値を追加します。
5. Return output.
5. 返品出力。
Given a decimal number as input_decimal, return an ASCII string suitable for use in an HTTP field value.
入力_Decimalとして10進数を与えられている場合、HTTPフィールド値で使用するのに適したASCII文字列を返します。
1. If input_decimal is not a decimal number, fail serialization.
1. input_decimalが10進数でない場合、シリアル化に失敗します。
2. If input_decimal has more than three significant digits to the right of the decimal point, round it to three decimal places, rounding the final digit to the nearest value, or to the even value if it is equidistant.
2. input_decimalが小数点の右側に3桁以上の数字を持っている場合、3つの小数点に丸め、最終桁を最も近い値に丸め、等距離の場合は偶数値に丸めます。
3. If input_decimal has more than 12 significant digits to the left of the decimal point after rounding, fail serialization.
3. input_decimalが丸め後に小数点の左側に12桁以上の有意桁を持っている場合、シリアル化に失敗します。
4. Let output be an empty string.
4. 出力を空の文字列とします。
5. If input_decimal is less than (but not equal to) 0, append "-" to output.
5. input_decimalが0未満（ただし等しくない）0の場合、「 - 」を出力に追加します。
6. Append input_decimal's integer component represented in base 10 (using only decimal digits) to output; if it is zero, append "0".
6. 入力_Decimalの整数コンポーネントをベース10（小数桁のみを使用して）に出力を追加します。ゼロの場合は、「0」を追加します。
7. Append "." to output.
7. append "。"。 "出力へ。
8. If input_decimal's fractional component is zero, append "0" to output.
8. input_decimalの分数コンポーネントがゼロの場合、出力に「0」を追加します。
9. Otherwise, append the significant digits of input_decimal's fractional component represented in base 10 (using only decimal digits) to output.
9. それ以外の場合、ベース10（小数桁のみを使用）に表されるinput_decimalの分数成分のかなりの数字を出力に追加します。
10. Return output.
10. 返品出力。
Given a String as input_string, return an ASCII string suitable for use in an HTTP field value.
input_stringとして文字列が与えられた場合、HTTPフィールド値で使用するのに適したASCII文字列を返します。
1. Convert input_string into a sequence of ASCII characters; if conversion fails, fail serialization.
1. input_stringをASCII文字のシーケンスに変換します。変換が失敗した場合、シリアル化に失敗します。
2. If input_string contains characters in the range %x00-1f or %x7f-ff (i.e., not in VCHAR or SP), fail serialization.
2. input_stringに範囲％x00-1fまたは％x7f-ff（つまり、vCharまたはspではない）の文字が含まれている場合、シリアル化に失敗します。
3. Let output be the string DQUOTE.
3. 出力を文字列dquoteとします。
4. For each character char in input_string:
4. input_stringの各文字charについて：
1. If char is "\" or DQUOTE:
1. charが「\」またはdquoteの場合：
1. Append "\" to output.
1. 出力に「\」を追加します。
2. Append char to output.
2. charを出力に追加します。
5. Append DQUOTE to output.
5. 出力にdquoteを追加します。
6. Return output.
6. 返品出力。
Given a Token as input_token, return an ASCII string suitable for use in an HTTP field value.
input_tokenとしてトークンを与えられた場合、HTTPフィールド値で使用するのに適したASCII文字列を返します。
1. Convert input_token into a sequence of ASCII characters; if conversion fails, fail serialization.
1. input_tokenをASCII文字のシーケンスに変換します。変換が失敗した場合、シリアル化に失敗します。
2. If the first character of input_token is not ALPHA or "*", or the remaining portion contains a character not in tchar, ":", or "/", fail serialization.
2. input_tokenの最初の文字がアルファまたは「*」ではない場合、または残りの部分にはtchar、 "、または「/」ではない文字が含まれている場合、シリアル化に失敗します。
3. Let output be an empty string.
3. 出力を空の文字列とします。
4. Append input_token to output.
4. input_tokenを出力に追加します。
5. Return output.
5. 返品出力。
Given a Byte Sequence as input_bytes, return an ASCII string suitable for use in an HTTP field value.
input_bytesとしてのバイトシーケンスを与えられた場合、HTTPフィールド値で使用するのに適したASCII文字列を返します。
1. If input_bytes is not a sequence of bytes, fail serialization.
1. input_bytesがバイトのシーケンスではない場合、シリアル化に失敗します。
2. Let output be an empty string.
2. 出力を空の文字列とします。
3. Append ":" to output.
3. append "："出力へ。
4. Append the result of base64-encoding input_bytes as per [RFC4648], Section 4, taking account of the requirements below.
4. 以下の要件を考慮して、セクション4の[RFC4648]、[RFC4648]に従ってBase64-Encoding input_bytesの結果を追加します。
5. Append ":" to output.
5. append "："出力へ。
6. Return output.
6. 返品出力。
The encoded data is required to be padded with "=", as per [RFC4648], Section 3.2.
エンコードされたデータは、[rfc4648]、セクション3.2に従って、「=」でパッドで埋める必要があります。
Likewise, encoded data SHOULD have pad bits set to zero, as per [RFC4648], Section 3.5, unless it is not possible to do so due to implementation constraints.
同様に、エンコードされたデータには、実装の制約のためにできない場合を除き、[RFC4648]、セクション3.5に従って、パッドビットをゼロに設定する必要があります。
Given a Boolean as input_boolean, return an ASCII string suitable for use in an HTTP field value.
input_booleanとしてのブール値を考えると、HTTPフィールド値で使用するのに適したASCII文字列を返します。
1. If input_boolean is not a boolean, fail serialization.
1. input_booleanがブールの場合は、シリアル化に失敗します。
2. Let output be an empty string.
2. 出力を空の文字列とします。
3. Append "?" to output.
3. 「？」を追加します出力へ。
4. If input_boolean is true, append "1" to output.
4. input_booleanがtrueの場合、「1」を出力に追加します。
5. If input_boolean is false, append "0" to output.
5. input_booleanがfalseの場合、出力に「0」を追加します。
6. Return output.
6. 返品出力。
Given a Date as input_date, return an ASCII string suitable for use in an HTTP field value.
input_dateとしての日付が与えられた場合、HTTPフィールド値で使用するのに適したASCII文字列を返します。
1. Let output be "@".
1. 出力を「@」とします。
2. Append to output the result of running Serializing an Integer with input_date (Section 4.1.4).
2. input_dateを使用して整数をシリアル化した結果（セクション4.1.4）の出力を出力するために追加します。
3. Return output.
3. 返品出力。
Given a sequence of Unicode code points as input_sequence, return an ASCII string suitable for use in an HTTP field value.
input_ sequenceとしての一連のユニコードコードポイントが与えられた場合、HTTPフィールド値で使用するのに適したASCII文字列を返します。
1. If input_sequence is not a sequence of Unicode code points, fail serialization.
1. input_sequenceがユニコードコードポイントのシーケンスではない場合、シリアル化に失敗します。
2. Let byte_array be the result of applying UTF-8 encoding (Section 3 of [UTF8]) to input_sequence. If encoding fails, fail serialization.
2. byte_arrayを、input_sequenceにutf-8エンコード（[utf8]のセクション3）を適用した結果とします。エンコーディングが失敗した場合、シリアル化に失敗します。
3. Let encoded_string be a string containing "%" followed by DQUOTE.
3. Encoded_Stringを「％」を含む文字列とdquoteを含む文字列とします。
4. For each byte in byte_array:
4. byte_arrayの各バイトについて：
1. If byte is %x25 ("%"), %x22 (DQUOTE), or in the ranges %x00-1f or %x7f-ff:
1. バイトが％x25（ "％"）、％x22（dquote）、または範囲で％x00-1fまたは％x7f-ffの場合：
1. Append "%" to encoded_string.
1. encoded_stringに「％」を追加します。
2. Let encoded_byte be the result of applying base16 encoding (Section 8 of [RFC4648]) to byte, with any alphabetic characters converted to lowercase.
2. encoded_byteを、base16エンコード（[rfc4648]のセクション8）をバイトに適用した結果とし、アルファベットの文字が小文字に変換されます。
3. Append encoded_byte to encoded_string.
3. encoded_byteをencoded_stringに追加します。
2. Otherwise, decode byte as an ASCII character and append the result to encoded_string.
2. それ以外の場合は、BYTEをASCII文字としてデコードし、結果をEncoded_Stringに追加します。
5. Append DQUOTE to encoded_string.
5. encoded_stringにdquoteを追加します。
6. Return encoded_string.
6. encoded_stringを返します。
Note that [UTF8] prohibits the encoding of code points between U+D800 and U+DFFF (surrogates); if they occur in input_sequence, serialization will fail.
[utf8]は、u+d800とu+dfff（surrogates）の間のコードポイントのエンコードを禁止することに注意してください。それらがinput_sequenceで発生すると、シリアル化は失敗します。
When a receiving implementation parses HTTP fields that are known to be Structured Fields, it is important that care be taken, as there are a number of edge cases that can cause interoperability or even security problems. This section specifies the algorithm for doing so.
実装が構造化されたフィールドであることが知られているHTTPフィールドを分析する場合、相互運用性やセキュリティの問題を引き起こす可能性のある多くのエッジケースがあるため、注意を払うことが重要です。このセクションでは、そのためのアルゴリズムを指定します。
Given an array of bytes as input_bytes that represent the chosen field's field-value (which is empty if that field is not present) and field_type (one of "dictionary", "list", or "item"), return the parsed field value.
選択したフィールドのフィールド値（そのフィールドが存在しない場合は空です）とfield_type（「辞書」、「リスト」、または「アイテム」のいずれか）を表すinput_bytesとしてのバイトの配列を考えると、解析されたフィールド値を返します。
1. Convert input_bytes into an ASCII string input_string; if conversion fails, fail parsing.
1. input_bytesをASCII文字列input_stringに変換します。変換が失敗した場合、解析に失敗します。
2. Discard any leading SP characters from input_string.
2. input_stringから主要なSP文字を破棄します。
3. If field_type is "list", let output be the result of running Parsing a List (Section 4.2.1) with input_string.
3. field_typeが「リスト」の場合、出力をinput_stringを使用してリスト（セクション4.2.1）を実行することの結果とします。
4. If field_type is "dictionary", let output be the result of running Parsing a Dictionary (Section 4.2.2) with input_string.
4. field_typeが「辞書」の場合、出力をinput_stringを使用して辞書（セクション4.2.2）を解析した結果とします。
5. If field_type is "item", let output be the result of running Parsing an Item (Section 4.2.3) with input_string.
5. field_typeが「アイテム」の場合、出力をinput_stringを使用してアイテムを解析する（セクション4.2.3）を実行した結果とします。
6. Discard any leading SP characters from input_string.
6. input_stringから主要なSP文字を破棄します。
7. If input_string is not empty, fail parsing.
7. input_stringが空でない場合は、解析に失敗します。
8. Otherwise, return output.
8. それ以外の場合は、出力を返します。
When generating input_bytes, parsers MUST combine all field lines in the same section (header or trailer) that case-insensitively match the field name into one comma-separated field-value, as per Section 5.2 of [HTTP]; this assures that the entire field value is processed correctly.
input_bytesを生成する場合、パーサーは、[http]のセクション5.2に従って、フィールド名を1つのコンマ分離されたフィールド値にケースを無知に一致させる同じセクション（ヘッダーまたはトレーラー）のすべてのフィールドラインを組み合わせる必要があります。これにより、フィールド値全体が正しく処理されることが保証されます。
For Lists and Dictionaries, this has the effect of correctly concatenating all of the field's lines, as long as individual members of the top-level data structure are not split across multiple field instances. The parsing algorithms for both types allow tab characters, since these might be used to combine field lines by some implementations.
リストと辞書の場合、これは、トップレベルのデータ構造の個々のメンバーが複数のフィールドインスタンスに分割されていない限り、フィールドのすべてのラインを正しく連結する効果があります。両方のタイプの解析アルゴリズムは、いくつかの実装でフィールドラインを組み合わせるために使用される可能性があるため、TAB文字を許可します。
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つまたは複数のコンマ（オプションのWhitespaceを使用して）がパーサーによる文字列出力の一部になるため、予測不可能な結果になります。連結は上流の仲介者によって行われる可能性があるため、結果は、両方とも同じ当事者の管理下にある場合でも、シリアナーまたはパーサーの制御下にありません。
Tokens, Integers, Decimals, and Byte Sequences cannot be split across multiple field lines because the inserted commas will cause parsing to fail.
トークン、整数、小数、およびバイトシーケンスは、挿入されたコンマが解析を故障させるため、複数のフィールドラインに分割することはできません。
Parsers MAY fail when processing a field value spread across multiple field lines, when one of those lines does not parse as that field. For example, a parsing handling an Example-String field that's defined as an sf-string is allowed to fail when processing this field section:
パーサーは、それらのラインの1つがそのフィールドとして解析しない場合、複数のフィールドラインにフィールド値を処理する場合に故障する可能性があります。たとえば、SFストリングとして定義された例弦フィールドを処理する解析は、このフィールドセクションを処理するときに故障することができます。
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.
解析が失敗した場合、フィールド値全体を無視する必要があります（つまり、セクションにフィールドが存在しないかのように扱われます）、あるいは完全なHTTPメッセージを奇形として扱う必要があります。これは、相互運用性と安全性を向上させるために意図的に厳格であり、構造化されたフィールドを使用するフィールド仕様はこの要件を緩めることができません。
Note that this requirement does not apply to an implementation that is not parsing the field; for example, an intermediary is not required to strip a failing field from a message before forwarding it.
この要件は、フィールドを解析しない実装には適用されないことに注意してください。たとえば、仲介者は、故障したフィールドをメッセージから転送する前に削除する必要はありません。
Given an ASCII string as input_string, return an array of (item_or_inner_list, parameters) tuples. input_string is modified to remove the parsed value.
input_stringとしてASCII文字列を与えられた場合、（item_or_inner_list、パラメーター）タプルの配列を返します。input_stringは、解析値を削除するように変更されています。
1. Let members be an empty array.
1. メンバーを空の配列にします。
2. While input_string is not empty:
2. input_stringが空ではありませんが：
1. Append the result of running Parsing an Item or Inner List (Section 4.2.1.1) with input_string to members.
1. Input_Stringを使用して、アイテムまたは内部リスト（セクション4.2.1.1）をメンバーに解析した結果を追加します。
2. Discard any leading OWS characters from input_string.
2. input_stringから主要なOWS文字を破棄します。
3. If input_string is empty, return members.
3. input_stringが空の場合は、メンバーを返します。
4. Consume the first character of input_string; if it is not ",", fail parsing.
4. input_stringの最初の文字を消費します。そうでない場合、「」、解析に失敗します。
5. Discard any leading OWS characters from input_string.
5. input_stringから主要なOWS文字を破棄します。
6. If input_string is empty, there is a trailing comma; fail parsing.
6. input_stringが空の場合、後続のコンマがあります。解析に失敗します。
3. No structured data has been found; return members (which is empty).
3. 構造化されたデータは見つかりませんでした。メンバーを返す（空）。
Given an ASCII string as input_string, return the tuple (item_or_inner_list, parameters), where item_or_inner_list can be either a single bare item or an array of (bare_item, parameters) tuples. input_string is modified to remove the parsed value.
input_stringとしてASCII文字列が与えられた場合、tuple（item_or_inner_list、パラメーター）を返します。ここで、item_or_inner_listは単一のベアアイテムまたは（bare_item、パラメーター）タプルの配列です。input_stringは、解析値を削除するように変更されています。
1. If the first character of input_string is "(", return the result of running Parsing an Inner List (Section 4.2.1.2) with input_string.
1. input_stringの最初の文字が "（"の場合、input_stringを使用して内部リスト（セクション4.2.1.2）を解析した結果を返します。
2. Return the result of running Parsing an Item (Section 4.2.3) with input_string.
2. Input_Stringを使用してアイテム（セクション4.2.3）を解析する結果を返します。
Given an ASCII string as input_string, return the tuple (inner_list, parameters), where inner_list is an array of (bare_item, parameters) tuples. input_string is modified to remove the parsed value.
input_stringとしてASCII文字列を与えられた場合、tuple（inner_list、パラメーター）を返します。ここで、inner_listは（bare_item、パラメーター）タプルの配列です。input_stringは、解析値を削除するように変更されています。
1. Consume the first character of input_string; if it is not "(", fail parsing.
1. input_stringの最初の文字を消費します。そうでない場合は、（」、解析を失敗させます。
2. Let inner_list be an empty array.
2. inner_listを空の配列とします。
3. While input_string is not empty:
3. input_stringが空ではありませんが：
1. Discard any leading SP characters from input_string.
1. input_stringから主要なSP文字を破棄します。
2. If the first character of input_string is ")":
2. input_stringの最初の文字が "）"の場合：
1. Consume the first character of input_string.
1. input_stringの最初の文字を消費します。
2. Let parameters be the result of running Parsing Parameters (Section 4.2.3.2) with input_string.
2. パラメーターを、input_stringを使用して解析パラメーター（セクション4.2.3.2）を実行した結果とします。
3. Return the tuple (inner_list, parameters).
3. タプル（inner_list、パラメーター）を返します。
3. Let item be the result of running Parsing an Item (Section 4.2.3) with input_string.
3. アイテムを、Input_Stringを使用してアイテムを解析する（セクション4.2.3）を実行した結果とします。
4. Append item to inner_list.
4. inner_listにアイテムを追加します。
5. If the first character of input_string is not SP or ")", fail parsing.
5. input_stringの最初の文字がspまたは "）"でない場合は、解析に失敗します。
4. The end of the Inner List was not found; fail parsing.
4. 内側のリストの終わりは見つかりませんでした。解析に失敗します。
Given an ASCII string as input_string, return an ordered map whose values are (item_or_inner_list, parameters) tuples. input_string is modified to remove the parsed value.
input_stringとしてASCII文字列を与えられた場合、値（item_or_inner_list、パラメーター）のタプルがある順序付けられたマップを返します。input_stringは、解析値を削除するように変更されています。
1. Let dictionary be an empty, ordered map.
1. 辞書を空の順序付けられたマップとします。
2. While input_string is not empty:
2. input_stringが空ではありませんが：
1. Let this_key be the result of running Parsing a Key (Section 4.2.3.3) with input_string.
1. this_keyを、input_stringを使用してキー（セクション4.2.3.3）を実行することの結果とします。
2. If the first character of input_string is "=":
2. input_stringの最初の文字が「=」の場合：
1. Consume the first character of input_string.
1. input_stringの最初の文字を消費します。
2. Let member be the result of running Parsing an Item or Inner List (Section 4.2.1.1) with input_string.
2. メンバーを、Input_Stringを使用してアイテムまたは内部リスト（セクション4.2.1.1）を解析した結果とします。
3. Otherwise:
3. さもないと：
1. Let value be Boolean true.
1. 値をブールとします。
2. Let parameters be the result of running Parsing Parameters (Section 4.2.3.2) with input_string.
2. パラメーターを、input_stringを使用して解析パラメーター（セクション4.2.3.2）を実行した結果とします。
3. Let member be the tuple (value, parameters).
3. メンバーをタプル（値、パラメーター）とします。
4. If dictionary already contains a key this_key (comparing character for character), overwrite its value with member.
4. 辞書に既にキーThis_key（文字のキャラクターを比較）が含まれている場合、その値をメンバーと上書きします。
5. Otherwise, append key this_key with value member to dictionary.
5. それ以外の場合は、Value Memberを辞書にkey_keyを追加します。
6. Discard any leading OWS characters from input_string.
6. input_stringから主要なOWS文字を破棄します。
7. If input_string is empty, return dictionary.
7. input_stringが空の場合は、辞書を返します。
8. Consume the first character of input_string; if it is not ",", fail parsing.
8. input_stringの最初の文字を消費します。そうでない場合、「」、解析に失敗します。
9. Discard any leading OWS characters from input_string.
9. input_stringから主要なOWS文字を破棄します。
10. If input_string is empty, there is a trailing comma; fail parsing.
10. input_stringが空の場合、後続のコンマがあります。解析に失敗します。
3. No structured data has been found; return dictionary (which is empty).
3. 構造化されたデータは見つかりませんでした。辞書（空です）。
Note that when duplicate Dictionary keys are encountered, all but the last instance are ignored.
辞書キーが複製した場合、最後のインスタンスを除くすべてが無視されることに注意してください。
Given an ASCII string as input_string, return a (bare_item, parameters) tuple. input_string is modified to remove the parsed value.
input_stringとしてASCII文字列を与えられた場合、a（bare_item、パラメーター）タプルを返します。input_stringは、解析値を削除するように変更されています。
1. Let bare_item be the result of running Parsing a Bare Item (Section 4.2.3.1) with input_string.
1. bare_itemを、input_stringを使用してベアアイテム（セクション4.2.3.1）を解析した結果とします。
2. Let parameters be the result of running Parsing Parameters (Section 4.2.3.2) with input_string.
2. パラメーターを、input_stringを使用して解析パラメーター（セクション4.2.3.2）を実行した結果とします。
3. Return the tuple (bare_item, parameters).
3. タプル（bare_item、パラメーター）を返します。
Given an ASCII string as input_string, return a bare Item. input_string is modified to remove the parsed value.
input_stringとしてASCII文字列を与えられた場合、むき出しのアイテムを返します。input_stringは、解析値を削除するように変更されています。
1. If the first character of input_string is a "-" or a DIGIT, return the result of running Parsing an Integer or Decimal (Section 4.2.4) with input_string.
1. input_stringの最初の文字が「 - 」または数字である場合、input_stringを使用して整数または小数（セクション4.2.4）を解析した結果を返します。
2. If the first character of input_string is a DQUOTE, return the result of running Parsing a String (Section 4.2.5) with input_string.
2. input_stringの最初の文字がdquoteの場合、input_stringを使用して文字列（セクション4.2.5）を解析する結果を返します。
3. If the first character of input_string is an ALPHA or "*", return the result of running Parsing a Token (Section 4.2.6) with input_string.
3. input_stringの最初の文字がアルファまたは「*」である場合、input_stringを使用してトークン（セクション4.2.6）を解析する結果を返します。
4. If the first character of input_string is ":", return the result of running Parsing a Byte Sequence (Section 4.2.7) with input_string.
4. input_stringの最初の文字が「：」の場合、input_stringを使用してバイトシーケンス（セクション4.2.7）を解析した結果を返します。
5. If the first character of input_string is "?", return the result of running Parsing a Boolean (Section 4.2.8) with input_string.
5. input_stringの最初の文字が「？」の場合、input_stringを使用してブール（セクション4.2.8）を解析した結果を返します。
6. If the first character of input_string is "@", return the result of running Parsing a Date (Section 4.2.9) with input_string.
6. input_stringの最初の文字が「@」の場合、input_stringを使用して日付を解析する（セクション4.2.9）を実行した結果を返します。
7. If the first character of input_string is "%", return the result of running Parsing a Display String (Section 4.2.10) with input_string.
7. input_stringの最初の文字が「％」の場合、input_stringを使用してディスプレイ文字列（セクション4.2.10）を解析した結果を返します。
8. Otherwise, the item type is unrecognized; fail parsing.
8. それ以外の場合、アイテムタイプは認識されていません。解析に失敗します。
Given an ASCII string as input_string, return an ordered map whose values are bare Items. input_string is modified to remove the parsed value.
input_stringとしてASCII文字列を与えられた場合、値が裸のアイテムである順序付けられたマップを返します。input_stringは、解析値を削除するように変更されています。
1. Let parameters be an empty, ordered map.
1. パラメーターを空の順序付けされたマップとします。
2. While input_string is not empty:
2. input_stringが空ではありませんが：
1. If the first character of input_string is not ";", exit the loop.
1. input_stringの最初の文字が ";"でない場合は、ループを終了します。
2. Consume the ";" character from the beginning of input_string.
2. 「;」を消費しますinput_stringの最初からのキャラクター。
3. Discard any leading SP characters from input_string.
3. input_stringから主要なSP文字を破棄します。
4. Let param_key be the result of running Parsing a Key (Section 4.2.3.3) with input_string.
4. PARAM_KEYを、input_stringを使用してキー（セクション4.2.3.3）を実行することの結果とします。
5. Let param_value be Boolean true.
5. param_valueをブールの真のものにします。
6. If the first character of input_string is "=":
6. input_stringの最初の文字が「=」の場合：
1. Consume the "=" character at the beginning of input_string.
1. input_stringの開始時に「=」文字を消費します。
2. Let param_value be the result of running Parsing a Bare Item (Section 4.2.3.1) with input_string.
2. PARAM_VALUEを、input_stringを使用して、裸のアイテム（セクション4.2.3.1）を解析した結果とします。
7. If parameters already contains a key param_key (comparing character for character), overwrite its value with param_value.
7. パラメーターに既にキーPARAM_KEY（文字の文字の比較）が含まれている場合、その値をPARAM_VALUEで上書きします。
8. Otherwise, append key param_key with value param_value to parameters.
8. それ以外の場合は、パラメーターに値param_valueを使用してキーparam_keyを追加します。
3. Return parameters.
3. パラメーターを返します。
Note that when duplicate parameter keys are encountered, all but the last instance are ignored.
重複したパラメーターキーに遭遇した場合、最後のインスタンスを除くすべてが無視されることに注意してください。
Given an ASCII string as input_string, return a key. input_string is modified to remove the parsed value.
input_stringとしてASCII文字列を与えられた場合、キーを返します。input_stringは、解析値を削除するように変更されています。
1. If the first character of input_string is not lcalpha or "*", fail parsing.
1. input_stringの最初の文字がlcalphaまたは "*"でない場合は、解析に失敗します。
2. Let output_string be an empty string.
2. output_stringを空の文字列とします。
3. While input_string is not empty:
3. input_stringが空ではありませんが：
1. If the first character of input_string is not one of lcalpha, DIGIT, "_", "-", ".", or "*", return output_string.
1. input_stringの最初の文字がlcalpha、digit、 "_"、 " - "、 "、"、または "*"の1つではない場合、return output_string。
2. Let char be the result of consuming the first character of input_string.
2. charは、input_stringの最初の文字を消費した結果とします。
3. Append char to output_string.
3. output_stringにcharを追加します。
4. Return output_string.
4. return output_string。
Given an ASCII string as input_string, return an Integer or Decimal. input_string is modified to remove the parsed value.
input_stringとしてASCII文字列を与えられた場合、整数または小数を返します。input_stringは、解析値を削除するように変更されています。
NOTE: This algorithm parses both Integers (Section 3.3.1) and Decimals (Section 3.3.2), and returns the corresponding structure.
注：このアルゴリズムは、整数（セクション3.3.1）と小数（セクション3.3.2）の両方を解析し、対応する構造を返します。
1. Let type be "integer".
1. タイプを「整数」とします。
2. Let sign be 1.
2. サインを1とします。
3. Let input_number be an empty string.
3. input_numberを空の文字列とします。
4. If the first character of input_string is "-", consume it and set sign to -1.
4. input_stringの最初の文字が「 - 」の場合、それを消費し、-1にサインを設定します。
5. If input_string is empty, there is an empty integer; fail parsing.
5. input_stringが空の場合、空の整数があります。解析に失敗します。
6. If the first character of input_string is not a DIGIT, fail parsing.
6. input_stringの最初の文字が数字でない場合は、解析に失敗します。
7. While input_string is not empty:
7. input_stringが空ではありませんが：
1. Let char be the result of consuming the first character of input_string.
1. charは、input_stringの最初の文字を消費した結果とします。
2. If char is a DIGIT, append it to input_number.
2. charが数字の場合は、input_numberに追加します。
3. Else, if type is "integer" and char is ".":
3. それ以外の場合、タイプが「整数」で、charが「」の場合。
1. If input_number contains more than 12 characters, fail parsing.
1. input_numberに12文字以上が含まれている場合、解析に失敗します。
2. Otherwise, append char to input_number and set type to "decimal".
2. それ以外の場合は、input_numberにcharを追加し、タイプを「小数」に設定します。
4. Otherwise, prepend char to input_string, and exit the loop.
4. それ以外の場合は、charをinput_stringにプレイエンドし、ループを終了します。
5. If type is "integer" and input_number contains more than 15 characters, fail parsing.
5. タイプが「整数」であり、input_numberに15文字以上が含まれている場合、解析に失敗します。
6. If type is "decimal" and input_number contains more than 16 characters, fail parsing.
6. タイプが「小数」であり、input_numberに16文字以上が含まれている場合、解析に失敗します。
8. If type is "integer":
8. タイプが「整数」の場合：
1. Let output_number be an Integer that is the result of parsing input_number as an integer.
1. output_numberを整数としてparsing _numberの結果である整数とします。
9. Otherwise:
9. さもないと：
1. If the final character of input_number is ".", fail parsing.
1. input_numberの最終文字が「。」である場合、解析に失敗します。
2. If the number of characters after "." in input_number is greater than three, fail parsing.
2. 後の文字の数の場合「」。input_numberでは3を超えているため、解析が失敗します。
3. Let output_number be a Decimal that is the result of parsing input_number as a decimal number.
3. output_numberを10進数で、入力_numberを小数点以下として解析した結果です。
10. Let output_number be the product of output_number and sign.
10. output_numberをoutput_numberとsignの製品とします。
11. Return output_number.
11. return output_number。
Given an ASCII string as input_string, return an unquoted String. input_string is modified to remove the parsed value.
input_stringとしてASCII文字列を与えられた場合、引用されていない文字列を返します。input_stringは、解析値を削除するように変更されています。
1. Let output_string be an empty string.
1. output_stringを空の文字列とします。
2. If the first character of input_string is not DQUOTE, fail parsing.
2. input_stringの最初の文字がdquoteでない場合は、解析に失敗します。
3. Discard the first character of input_string.
3. input_stringの最初の文字を破棄します。
4. While input_string is not empty:
4. input_stringが空ではありませんが：
1. Let char be the result of consuming the first character of input_string.
1. charは、input_stringの最初の文字を消費した結果とします。
2. If char is a backslash ("\"):
2. charがバックスラッシュの場合（ "\"）：
1. If input_string is now empty, fail parsing.
1. input_stringが空になった場合は、解析に失敗します。
2. Let next_char be the result of consuming the first character of input_string.
2. next_charをinput_stringの最初の文字を消費した結果とします。
3. If next_char is not DQUOTE or "\", fail parsing.
3. next_charがdquoteまたは "\"でない場合は、解析に失敗します。
4. Append next_char to output_string.
4. next_charをoutput_stringに追加します。
3. Else, if char is DQUOTE, return output_string.
3. それ以外の場合、charがdquoteの場合、return output_stringを返します。
4. Else, if char is in the range %x00-1f or %x7f-ff (i.e., it is not in VCHAR or SP), fail parsing.
4. それ以外の場合、charが％x00-1Fまたは％x7f-ffの範囲にある場合（つまり、vCharまたはspではありません）、解析が失敗します。
5. Else, append char to output_string.
5. それ以外の場合は、output_stringにcharを追加します。
5. Reached the end of input_string without finding a closing DQUOTE; fail parsing.
5. 閉じるdquoteを見つけることなく、input_stringの終わりに到達しました。解析に失敗します。
Given an ASCII string as input_string, return a Token. input_string is modified to remove the parsed value.
input_stringとしてASCII文字列を与えられた場合、トークンを返します。input_stringは、解析値を削除するように変更されています。
1. If the first character of input_string is not ALPHA or "*", fail parsing.
1. input_stringの最初の文字がアルファまたは「*」ではない場合は、解析に失敗します。
2. Let output_string be an empty string.
2. output_stringを空の文字列とします。
3. While input_string is not empty:
3. input_stringが空ではありませんが：
1. If the first character of input_string is not in tchar, ":", or "/", return output_string.
1. input_stringの最初の文字がtcharにない場合、 "："、または "/"、return output_string。
2. Let char be the result of consuming the first character of input_string.
2. charは、input_stringの最初の文字を消費した結果とします。
3. Append char to output_string.
3. output_stringにcharを追加します。
4. Return output_string.
4. return output_string。
Given an ASCII string as input_string, return a Byte Sequence. input_string is modified to remove the parsed value.
input_stringとしてASCII文字列を与えられた場合、バイトシーケンスを返します。input_stringは、解析値を削除するように変更されています。
1. If the first character of input_string is not ":", fail parsing.
1. input_stringの最初の文字が「：」でない場合、解析に失敗します。
2. Discard the first character of input_string.
2. input_stringの最初の文字を破棄します。
3. If there is not a ":" character before the end of input_string, fail parsing.
3. input_stringが終了する前に「：」文字がない場合は、解析に失敗します。
4. Let b64_content be the result of consuming content of input_string up to but not including the first instance of the character ":".
4. b64_contentを、input_stringのコンテンツを消費した結果としますが、キャラクターの最初のインスタンス "："を含めません。
5. Consume the ":" character at the beginning of input_string.
5. input_stringの開始時に「：」文字を消費します。
6. If b64_content contains a character not included in ALPHA, DIGIT, "+", "/", and "=", fail parsing.
6. b64_contentがアルファに含まれていない文字、桁、 "+"、 "/"、および "="が含まれている場合、解析に失敗します。
7. Let binary_content be the result of base64-decoding [RFC4648] b64_content, synthesizing padding if necessary (note the requirements about recipient behavior below). If base64 decoding fails, parsing fails.
7. binary_contentをbase64-decoding [rfc4648] b64_contentの結果とし、必要に応じてパディングを合成します（以下の受信者の動作に関する要件に注意してください）。base64デコードが失敗すると、解析が失敗します。
8. Return binary_content.
8. binary_contentを返します。
Because some implementations of base64 do not allow rejection of encoded data that is not properly "=" padded (see [RFC4648], Section 3.2), parsers SHOULD NOT fail when "=" padding is not present, unless they cannot be configured to do so.
base64のいくつかの実装では、適切に「=」パッド（[rfc4648]、セクション3.2を参照）を適切にしないエンコードされたデータの拒否を許可していないため、「=」パディングが存在しない場合、パーサーが存在しない場合、パーサーは失敗しないでください。それで。
Because some implementations of base64 do not allow rejection of encoded data that has non-zero pad bits (see [RFC4648], Section 3.5), parsers SHOULD NOT fail when non-zero pad bits are present, unless they cannot be configured to do so.
base64のいくつかの実装では、ゼロ以外のパッドビットを持つエンコードされたデータの拒否を許可していないため（[RFC4648]、セクション3.5を参照）、パーサーがゼロ以外のパッドビットが存在する場合、そうするように設定できない限り故障しないでください。
This specification does not relax the requirements in Sections 3.1 and 3.3 of [RFC4648]; therefore, parsers MUST fail on characters outside the base64 alphabet and on line feeds in encoded data.
この仕様では、[RFC4648]のセクション3.1および3.3の要件を緩和しません。したがって、パーサーは、base64アルファベットの外側の文字とエンコードされたデータのオンラインフィードで故障する必要があります。
Given an ASCII string as input_string, return a Boolean. input_string is modified to remove the parsed value.
input_stringとしてASCII文字列を与えられた場合、ブール値を返します。input_stringは、解析値を削除するように変更されています。
1. If the first character of input_string is not "?", fail parsing.
1. input_stringの最初の文字が「？」でない場合は、解析に失敗します。
2. Discard the first character of input_string.
2. input_stringの最初の文字を破棄します。
3. If the first character of input_string matches "1", discard the first character, and return true.
3. input_stringの最初の文字が「1」と一致する場合、最初の文字を破棄し、trueを返します。
4. If the first character of input_string matches "0", discard the first character, and return false.
4. input_stringの最初の文字が「0」と一致する場合、最初の文字を破棄し、falseを返します。
5. No value has matched; fail parsing.
5. 一致する値はありません。解析に失敗します。
Given an ASCII string as input_string, return a Date. input_string is modified to remove the parsed value.
input_stringとしてASCII文字列を与えられた場合、日付を返します。input_stringは、解析値を削除するように変更されています。
1. If the first character of input_string is not "@", fail parsing.
1. input_stringの最初の文字が「@」ではない場合は、解析に失敗します。
2. Discard the first character of input_string.
2. input_stringの最初の文字を破棄します。
3. Let output_date be the result of running Parsing an Integer or Decimal (Section 4.2.4) with input_string.
3. input_stringを使用して、整数または小数（セクション4.2.4）を解析する実行の結果とします。
4. If output_date is a Decimal, fail parsing.
4. output_dateが小数点以下である場合、解析に失敗します。
5. Return output_date.
5. return 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.
input_stringとしてASCII文字列を与えられた場合、Unicodeコードポイントのシーケンスを返します。input_stringは、解析値を削除するように変更されています。
1. If the first two characters of input_string are not "%" followed by DQUOTE, fail parsing.
1. input_stringの最初の2文字が「％」に続くDquoteが続く場合は、解析に失敗します。
2. Discard the first two characters of input_string.
2. input_stringの最初の2文字を破棄します。
3. Let byte_array be an empty byte array.
3. byte_arrayを空のバイト配列とします。
4. While input_string is not empty:
4. input_stringが空ではありませんが：
1. Let char be the result of consuming the first character of input_string.
1. charは、input_stringの最初の文字を消費した結果とします。
2. If char is in the range %x00-1f or %x7f-ff (i.e., it is not in VCHAR or SP), fail parsing.
2. charが範囲％x00-1fまたは％x7f-ff（つまり、vCharまたはspではない場合）にある場合、解析に失敗します。
3. If char is "%":
3. charが「％」の場合：
1. Let octet_hex be the result of consuming two characters from input_string. If there are not two characters, fail parsing.
1. Octet_hexを、input_stringの2つの文字を消費した結果とします。2つの文字がない場合は、解析に失敗します。
2. 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.
2. Octet_Hexに範囲％x30-39または％x61-66の外側の文字が含まれている場合（つまり、0-9または小文字A-Fではありません）、解析に失敗します。
3. Let octet be the result of hex decoding octet_hex (Section 8 of [RFC4648]).
3. Octetを、occet_hexを解読した結果とします（[RFC4648]のセクション8）。
4. Append octet to byte_array.
4. byte_arrayにオクテットを追加します。
4. If char is DQUOTE:
4. charがdquoteの場合：
1. Let unicode_sequence be the result of decoding byte_array as a UTF-8 string (Section 3 of [UTF8]). Fail parsing if decoding fails.
1. Unicode_sequenceを、byte_arrayをUTF-8文字列としてデコードした結果とします（[utf8]のセクション3）。デコードが失敗した場合、解析に失敗します。
2. Return unicode_sequence.
2. Unicode_sequenceを返します。
5. Otherwise, if char is not "%" or DQUOTE:
5. それ以外の場合、charが「％」またはdquoteでない場合：
1. Let byte be the result of applying ASCII encoding to char.
1. BYTEを、ASCIIエンコードをCHARに適用した結果とします。
2. Append byte to byte_array.
2. byte_arrayにバイトを追加します。
5. Reached the end of input_string without finding a closing DQUOTE; fail parsing.
5. 閉じるdquoteを見つけることなく、input_stringの終わりに到達しました。解析に失敗します。
IANA has added the following note to the "Hypertext Transfer Protocol (HTTP) Field Name Registry":
IANAは、「HyperText Transfer Protocol（HTTP）フィールド名レジストリ」に次のメモを追加しました。
The "Structured Type" column indicates the type of the field (per RFC 9651), if any, and may be "Dictionary", "List", or "Item".
「構造化されたタイプ」列は、フィールドのタイプ（RFC 9651ごと）を示し、「辞書」、「リスト」、または「アイテム」である場合があります。
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.
アルファまたは「*」以外の文字から始まるフィールド名は、構造化されたフィールドトークンとして表現できないため、それを参照するフィールド値にマッピングされることと互換性がない場合があることに注意してください。
A new column, "Structured Type", has been added to the registry.
新しい列「構造型」がレジストリに追加されました。
The indicated Structured Type for each existing registry entry listed in Table 1 has also been added.
表1にリストされている既存のレジストリエントリごとに示された構造化されたタイプも追加されています。
+==========================================+=================+
| 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 |
+------------------------------------------+-----------------+
Table 1: Existing Fields
表1：既存のフィールド
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を含む）、または非文字が含まれる場合があります。したがって、ディスプレイ文字列を消費するアプリケーションは、表示する前に信頼できないコンテンツのフィルタリングや脱出などの戦略を考慮する必要があります。[precis]および[unicode-security]を参照してください。
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for
HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
<https://www.rfc-editor.org/info/rfc7541>.
[HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
DOI 10.17487/RFC9113, June 2022,
<https://www.rfc-editor.org/info/rfc9113>.
[IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE
Std 754-2019, DOI 10.1109/IEEESTD.2019.8766229,
ISBN 978-1-5044-5924-2, July 2019,
<https://ieeexplore.ieee.org/document/8766229>.
[PRECIS] Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
Preparation, Enforcement, and Comparison of
Internationalized Strings in Application Protocols",
RFC 8264, DOI 10.17487/RFC8264, October 2017,
<https://www.rfc-editor.org/info/rfc8264>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
DOI 10.17487/RFC7493, March 2015,
<https://www.rfc-editor.org/info/rfc7493>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[UNICODE-SECURITY]
Davis, M. and M. Suignard, "Unicode Security
Considerations", Unicode Technical Report #36, 19
September 2014,
<https://www.unicode.org/reports/tr36/tr36-15.html>.
Latest version available at
<https://www.unicode.org/reports/tr36/>.
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文字列であり、潜在的な相互運用性の問題が多数あります（例：比較）。実装者は、不要な場合はASSASCII以外のコンテンツを避けるようにアドバイスできますが、これを実施することは困難です。
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.
この仕様の一般的な実装では、トップレベルのシリアル化（セクション4.1）と解析（セクション4.2）関数を公開する必要があります。それらは機能である必要はありません。たとえば、異なるトップレベルタイプのそれぞれのメソッドを使用して、オブジェクトとして実装できます。
For interoperability, it's important that generic implementations be complete and follow the algorithms closely; see Section 1.1. To aid this, a common test suite is being maintained by the community at <https://github.com/httpwg/structured-field-tests>.
相互運用性のために、一般的な実装が完了し、アルゴリズムに密接に従うことが重要です。セクション1.1を参照してください。これを支援するために、一般的なテストスイートが<https://github.com/httpwg/structured-field-tests>でコミュニティによって維持されています。
Implementers should note that Dictionaries and Parameters are order-preserving maps. Some fields may not convey meaning in the ordering of these data types, but it should still be exposed so that it will be available to applications that need to use it.
実装者は、辞書とパラメーターが注文販売マップであることに注意する必要があります。一部のフィールドは、これらのデータ型の順序において意味を伝えない場合がありますが、それを使用する必要があるアプリケーションが利用できるように、それを公開する必要があります。
Likewise, implementations should note that it's important to preserve the distinction between Tokens and Strings. While most programming languages have 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.
シリアル化アルゴリズムは、すべての場合にセクション3で定義されているデータ型に厳密に限定されないという方法で定義されます。たとえば、小数は、より広い入力とラウンドを許可された値をとるように設計されています。
Implementations are allowed to limit the size of different structures, subject to the minimums defined for each type. When a structure exceeds an implementation limit, that structure fails parsing or serialization.
実装では、各タイプで定義された最小値を条件として、異なる構造のサイズを制限できます。構造が実装の制限を超えると、その構造は解析またはシリアル化に失敗します。
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.
このセクションでは、構造化されたフィールドの予想される構文を説明するために、拡張されたBackus-Naurフォーム（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
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)
* 日付構造型を追加しました。（セクション3.3.7）
* Stopped encouraging use of ABNF in definitions of new Structured Fields. (Section 2)
* 新しい構造化されたフィールドの定義でABNFの使用を奨励するのを停止しました。（セクション2）
* Moved ABNF to an informative appendix. (Appendix C)
* ABNFを有益な付録に移動しました。（付録C）
* Added a "Structured Type" column to the "Hypertext Transfer Protocol (HTTP) Field Name Registry". (Section 5)
* 「HyperText Transfer Protocol（HTTP）フィールド名レジストリ」に「構造化されたタイプ」列を追加しました。（セクション5）
* Refined parse failure handling. (Section 4.2)
* 洗練された解析障害処理。（セクション4.2）
* Added the Display String Structured Type. (Section 3.3.8)
* ディスプレイ文字列構造タイプを追加しました。（セクション3.3.8）
Many thanks to Matthew Kerwin for his detailed feedback and careful consideration during the development of this specification.
この仕様の開発中に詳細なフィードバックと慎重な検討をしてくれたマシューカーウィンに感謝します。
Thanks also to Ian Clelland, Roy Fielding, Anne van Kesteren, Kazuho Oku, Evert Pot, Julian Reschke, Martin Thomson, Mike West, and Jeffrey Yasskin for their contributions.
また、イアン・クレランド、ロイ・フィールディング、アン・ヴァン・ケスターン、カズホ・オク、エバート・ポット、ジュリアン・レシュケ、マーティン・トムソン、マイク・ウェスト、ジェフリー・ヤスキンの貢献にも感謝します。
Mark Nottingham
Cloudflare
Prahran VIC
Australia
Email: mnot@mnot.net
URI: https://www.mnot.net/
Poul-Henning Kamp
The Varnish Cache Project
Email: phk@varnish-cache.org