[要約] RFC 8187は、HTTPヘッダーフィールドパラメータの文字エンコーディングと言語を示すための仕様です。このRFCの目的は、HTTP通信における文字エンコーディングと言語の正確な指定を可能にすることです。
Internet Engineering Task Force (IETF) J. Reschke
Request for Comments: 8187 greenbytes
Obsoletes: 5987 September 2017
Category: Standards Track
ISSN: 2070-1721
Indicating Character Encoding and Language for HTTP Header Field Parameters
HTTPヘッダーフィールドパラメータの文字エンコーディングと言語を示す
Abstract
概要
By default, header field values in Hypertext Transfer Protocol (HTTP) messages cannot easily carry characters outside the US-ASCII coded character set. RFC 2231 defines an encoding mechanism for use in parameters inside Multipurpose Internet Mail Extensions (MIME) header field values. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a simplified profile of the encoding defined in RFC 2231.
既定では、ハイパーテキスト転送プロトコル（HTTP）メッセージのヘッダーフィールド値は、US-ASCIIコード化文字セットの外の文字を簡単に運ぶことができません。 RFC 2231は、MIME（Multipurpose Internet Mail Extensions）ヘッダーフィールド値内のパラメーターで使用するエンコードメカニズムを定義しています。このドキュメントは、RFC 2231で定義されたエンコーディングの簡略化されたプロファイルと互換性のあるHTTPヘッダーフィールドでの使用に適したエンコーディングを指定します。
This document obsoletes RFC 5987.
このドキュメントはRFC 5987を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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/rfc8187.
このドキュメントの現在のステータス、正誤表、およびそれに関するフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8187で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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 Simplified BSD License text as described in Section 4.e of
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.eで説明されているSimplified BSD Licenseテキストが含まれている必要があります。
the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Trust Legal ProvisionsおよびSimplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3
3. Comparison to RFC 2231 and Definition of the Encoding . . . . 3
3.1. Parameter Continuations . . . . . . . . . . . . . . . . . 4
3.2. Parameter Value Character Encoding and Language
Information . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.1. Definition . . . . . . . . . . . . . . . . . . . . . 4
3.2.2. Historical Notes . . . . . . . . . . . . . . . . . . 6
3.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Language Specification in Encoded Words . . . . . . . . . 7
4. Guidelines for Usage in HTTP Header Field Definitions . . . . 7
4.1. When to Use the Extension . . . . . . . . . . . . . . . . 8
4.2. Error Handling . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Changes from RFC 5987 . . . . . . . . . . . . . . . 12
Appendix B. Implementation Report . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
Use of characters outside the US-ASCII coded character set ([RFC0020]) in HTTP header fields ([RFC7230]) is non-trivial:
US-ASCIIコード化文字セット（[RFC0020]）以外の文字をHTTPヘッダーフィールド（[RFC7230]）で使用することは重要です。
o The HTTP specification discourages use of non-US-ASCII characters in field values, placing them into the "obs-text" Augmented Backus-Naur Form (ABNF) production ([RFC7230], Section 3.2).
o HTTP仕様では、フィールド値にUS-ASCII以外の文字を使用しないようにして、「obs-text」拡張型バッカスナウアフォーム（ABNF）プロダクション（[RFC7230]、セクション3.2）に配置します。
o Furthermore, it stays silent about default character encoding schemes for field values, so any use of non-US-ASCII characters would need to be specific to the field definition or would require some other kind of out-of-band information.
o さらに、フィールド値のデフォルトの文字エンコードスキームについては通知されないため、US-ASCII以外の文字を使用する場合は、フィールド定義に固有であるか、他の種類の帯域外情報が必要になります。
o Finally, some APIs assume a default character encoding scheme in order to map from the octet sequences (obtained from the HTTP message) to character sequences: for instance, the XMLHttpRequest API ([XMLHttpRequest]) uses the Interface Definition Language type "ByteString", effectively resulting in the ISO-8859-1 character encoding scheme ([ISO-8859-1]) being used.
o 最後に、一部のAPIは、（HTTPメッセージから取得した）オクテットシーケンスを文字シーケンスにマップするために、デフォルトの文字エンコード方式を想定しています。たとえば、XMLHttpRequest API（[XMLHttpRequest]）は、インターフェイス定義言語タイプ「ByteString」を使用します。事実上、ISO-8859-1文字エンコードスキーム（[ISO-8859-1]）が使用されます。
On the other hand, RFC 2231 defines an encoding mechanism for parameters inside MIME header fields ([RFC2231]), which, as opposed to HTTP messages, do need to be sent over non-binary transports. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a simplified profile of the encoding defined in RFC 2231. It can be applied to any HTTP header field that uses the common "parameter" ("name=value") syntax.
一方、RFC 2231は、MIMEヘッダーフィールド（[RFC2231]）内のパラメーターのエンコードメカニズムを定義しています。これは、HTTPメッセージとは異なり、非バイナリトランスポート経由で送信する必要があります。このドキュメントでは、RFC 2231で定義されているエンコードの簡略化されたプロファイルと互換性のあるHTTPヘッダーフィールドでの使用に適したエンコードを指定します。一般的な「パラメーター」（「name = value」）を使用するすべてのHTTPヘッダーフィールドに適用できます。構文。
This document obsoletes [RFC5987] and moves it to "Historic" status; the changes are summarized in Appendix A.
このドキュメントは[RFC5987]を廃止し、それを "Historic"ステータスに移動します。変更は付録Aにまとめられています。
Note: In the remainder of this document, RFC 2231 is only referenced for the purpose of explaining the choice of features that were adopted; therefore, they are purely informative.
注：このドキュメントの残りの部分では、RFC 2231は、採用された機能の選択を説明する目的でのみ参照されています。したがって、それらは純粋に有益です。
Note: This encoding does not apply to message payloads transmitted over HTTP, such as when using the media type "multipart/form-data" ([RFC7578]).
注：このエンコードは、メディアタイプ「multipart / form-data」（[RFC7578]）を使用する場合など、HTTP経由で送信されるメッセージペイロードには適用されません。
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 [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
This specification uses the ABNF notation defined in [RFC5234]. The following core rules are included by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), DIGIT (decimal 0-9), HEXDIG (hexadecimal 0-9/A-F/a-f), and LWSP (linear whitespace).
この仕様では、[RFC5234]で定義されているABNF表記を使用しています。 [RFC5234]、付録B.1で定義されているように、次のコアルールが参照として含まれています：ALPHA（文字）、DIGIT（10進数の0-9）、HEXDIG（16進数の0-9 / AF / af）、およびLWSP（線形）空白）。
This specification uses terminology defined in [RFC6365], namely: "character encoding scheme" (abbreviated to "character encoding" below), "charset", and "coded character set".
この仕様では、[RFC6365]で定義されている用語、つまり「文字エンコーディングスキーム」（以下「文字エンコーディング」と略記）、「charset」、および「コード化文字セット」を使用しています。
Note that this differs from RFC 2231, which uses the term "character set" for "character encoding scheme".
これは、「文字エンコーディングスキーム」に「文字セット」という用語を使用するRFC 2231とは異なることに注意してください。
RFC 2231 defines several extensions to MIME. The sections below discuss if and how they apply to HTTP header fields.
RFC 2231は、MIMEに対するいくつかの拡張を定義しています。以下のセクションでは、それらがHTTPヘッダーフィールドに適用されるかどうかとその適用方法について説明します。
In short:
要するに：
o Parameter Continuations aren't needed (Section 3.1),
o パラメータの継続は必要ありません（セクション3.1）。
o Character Encoding and Language Information are useful, therefore a simple subset is specified (Section 3.2), and
o 文字エンコーディングと言語情報は有用であるため、簡単なサブセットを指定します（セクション3.2）。
o Language Specifications in Encoded Words aren't needed (Section 3.3).
o エンコードされた単語の言語指定は必要ありません（セクション3.3）。
Section 3 of [RFC2231] defines a mechanism that deals with the length limitations that apply to MIME headers. These limitations do not apply to HTTP ([RFC7231], Appendix A.6).
[RFC2231]のセクション3では、MIMEヘッダーに適用される長さの制限に対処するメカニズムを定義しています。これらの制限はHTTPには適用されません（[RFC7231]、付録A.6）。
Thus, parameter continuations are not part of the encoding defined by this specification.
したがって、パラメーターの継続は、この仕様で定義されているエンコードの一部ではありません。
Section 4 of [RFC2231] specifies how to embed language information into parameter values and also how to encode non-ASCII characters, dealing with restrictions both in MIME and HTTP header field parameters.
[RFC2231]のセクション4は、言語情報をパラメーター値に埋め込む方法、および非ASCII文字をエンコードする方法を指定し、MIMEおよびHTTPヘッダーフィールドパラメーターの制限に対処します。
However, RFC 2231 does not specify a mandatory-to-implement character encoding, making it hard for senders to decide which encoding to use. Thus, recipients implementing this specification MUST support the "UTF-8" character encoding [RFC3629].
ただし、RFC 2231では、必須の文字エンコーディングを指定していないため、送信者が使用するエンコーディングを決定するのは困難です。したがって、この仕様を実装する受信者は、「UTF-8」文字エンコーディング[RFC3629]をサポートする必要があります。
Furthermore, RFC 2231 allows the character encoding information to be left out. The encoding defined by this specification does not allow that.
さらに、RFC 2231では、文字エンコード情報を省略できます。この仕様で定義されているエンコーディングでは、これは許可されていません。
The presence of extended parameter values is usually indicated by a parameter name ending in an asterisk character. However, note that this is just a convention, and that the extended parameter values need to be explicitly specified in the definition of the header field using this extension (see Section 4).
拡張パラメーター値の存在は通常、アスタリスク文字で終わるパラメーター名によって示されます。ただし、これは単なる規則であり、拡張パラメーター値は、この拡張を使用するヘッダーフィールドの定義で明示的に指定する必要があることに注意してください（セクション4を参照）。
The ABNF for extended parameter values is specified below:
拡張パラメーター値のABNFを以下に示します。
ext-value = charset "'" [ language ] "'" value-chars
; like RFC 2231's <extended-initial-value>
; (see [RFC2231], Section 7)
charset = "UTF-8" / mime-charset
charset = "UTF-8" / mime-charset
mime-charset = 1*mime-charsetc
mime-charsetc = ALPHA / DIGIT
/ "!" / "#" / "$" / "%" / "&"
/ "+" / "-" / "^" / "_" / "`"
/ "{" / "}" / "~"
; as <mime-charset> in Section 2.3 of [RFC2978]
; except that the single quote is not included
; SHOULD be registered in the IANA charset registry
language = <Language-Tag, see [RFC5646], Section 2.1>
value-chars = *( pct-encoded / attr-char )
pct-encoded = "%" HEXDIG HEXDIG ; see [RFC3986], Section 2.1
pct-encoded = "％" HEXDIG HEXDIG; [RFC3986]、セクション2.1を参照
attr-char = ALPHA / DIGIT
/ "!" / "#" / "$" / "&" / "+" / "-" / "."
/ "^" / "_" / "`" / "|" / "~"
; token except ( "*" / "'" / "%" )
The value part of an extended parameter (ext-value) is a token that consists of three parts:
拡張パラメーター（ext-value）の値の部分は、次の3つの部分で構成されるトークンです。
1. the REQUIRED character encoding name (charset),
1. 必須の文字エンコーディング名（charset）、
2. the OPTIONAL language information (language), and
2. オプションの言語情報（言語）、および
3. a character sequence representing the actual value (value-chars), separated by single quote characters.
3. 一重引用符で区切られた実際の値（value-chars）を表す文字シーケンス。
Note that both character encoding names and language tags are restricted to the US-ASCII coded character set and are matched case-insensitively (see Section 2.3 of [RFC2978] and Section 2.1.1 of [RFC5646]).
文字エンコード名と言語タグはどちらもUS-ASCIIコード化文字セットに制限されており、大文字と小文字を区別せずに一致します（[RFC2978]のセクション2.3および[RFC5646]のセクション2.1.1を参照）。
Inside the value part, characters not contained in attr-char are encoded into an octet sequence using the specified character encoding. That octet sequence is then percent-encoded as specified in Section 2.1 of [RFC3986].
値の部分では、attr-charに含まれていない文字は、指定された文字エンコーディングを使用してオクテットシーケンスにエンコードされます。そのオクテットシーケンスは、[RFC3986]のセクション2.1で指定されているようにパーセントエンコードされます。
Producers MUST use the "UTF-8" ([RFC3629]) character encoding. Extension character encodings (mime-charset) are reserved for future use.
プロデューサーは、「UTF-8」（[RFC3629]）文字エンコードを使用する必要があります。拡張文字エンコーディング（mime-charset）は将来の使用のために予約されています。
Note: Recipients should be prepared to handle encoding errors, such as malformed or incomplete percent escape sequences, or non-decodable octet sequences, in a robust manner. This specification does not mandate any specific behavior; for instance, the following strategies are all acceptable:
注：受信者は、不正な形式または不完全なパーセントエスケープシーケンス、またはデコードできないオクテットシーケンスなどのエンコードエラーを確実に処理できるように準備する必要があります。この仕様は、特定の動作を義務付けるものではありません。たとえば、次の戦略はすべて受け入れられます。
* ignoring the parameter,
* パラメータを無視して、
* stripping a non-decodable octet sequence, and
* デコード不可能なオクテットシーケンスを除去する
* substituting a non-decodable octet sequence by a replacement character, such as the Unicode character U+FFFD (Replacement Character).
* デコード不可のオクテットシーケンスを、Unicode文字U + FFFD（置換文字）などの置換文字で置き換える。
The RFC 7230 token production ([RFC7230], Section 3.2.6) differs from the production used in RFC 2231 (imported from Section 5.1 of [RFC2045]) in that curly braces (i.e., "{" and "}") are excluded. Thus, these two characters are excluded from the attr-char production as well.
RFC 7230トークンの生成（[RFC7230]、セクション3.2.6）は、RFC 2231（[RFC2045]のセクション5.1からインポートされた）で使用されている生成とは異なり、中括弧（つまり、「{」と「}」）が除外されています。 。したがって、これらの2つの文字はattr-charの生成からも除外されます。
The <mime-charset> ABNF defined here differs from the one in Section 2.3 of [RFC2978] in that it does not allow the single quote character (see also RFC Errata ID 1912 [Err1912]). In practice, no character encoding names using that character have been registered at the time of this writing.
ここで定義されている<mime-charset> ABNFは、[RFC2978]のセクション2.3のものとは異なり、単一引用符を使用できません（RFC Errata ID 1912 [Err1912]も参照）。実際には、この執筆時点では、その文字を使用する文字エンコード名は登録されていません。
For backwards compatibility with RFC 2231, the encoding defined by this specification deviates from common parameter syntax in that the quoted-string notation is not allowed. Implementations using generic parser components might not be able to detect the use of quoted-string notation and thus might accept that format, although invalid, as well.
RFC 2231との下位互換性のために、この仕様で定義されているエンコーディングは、引用符付き文字列表記が許可されていないという点で、一般的なパラメータ構文から逸脱しています。汎用パーサーコンポーネントを使用した実装は、引用符付き文字列表記の使用を検出できない場合があり、したがって、無効でもフォーマットを受け入れる場合があります。
[RFC5987] did require support for ISO-8859-1 ([ISO-8859-1]), too; for compatibility with legacy code, recipients are encouraged to support this encoding as well.
[RFC5987]もISO-8859-1（[ISO-8859-1]）のサポートを必要としました。レガシーコードとの互換性のために、受信者もこのエンコーディングをサポートすることをお勧めします。
Non-extended notation, using "token":
「トークン」を使用した非拡張表記：
foo: bar; title=Economy
Non-extended notation, using "quoted-string":
「引用文字列」を使用した非拡張表記：
foo: bar; title="US-$ rates"
Extended notation, using the Unicode character U+00A3 ("£", POUND SIGN):
Unicode文字U + 00A3（ "£"、POUND SIGN）を使用した拡張表記：
foo: bar; title*=utf-8'en'%C2%A3%20rates
Note: The Unicode pound sign character U+00A3 was encoded into the octet sequence C2 A3 using the UTF-8 character encoding, and then percent-encoded. Also, note that the space character was encoded as %20, as it is not contained in attr-char.
注：Unicodeポンド記号文字U + 00A3は、UTF-8文字エンコードを使用してオクテットシーケンスC2 A3にエンコードされ、パーセントエンコードされました。また、スペース文字はattr-charに含まれていないため、％20としてエンコードされたことにも注意してください。
Extended notation, using the Unicode characters U+00A3 ("£", POUND SIGN) and U+20AC ("€", EURO SIGN):
Unicode文字U + 00A3（ "£"、POUND SIGN）およびU + 20AC（ "€"、EURO SIGN）を使用した拡張表記：
foo: bar; title*=UTF-8''%c2%a3%20and%20%e2%82%ac%20rates
Note: The Unicode pound sign character U+00A3 was encoded into the octet sequence C2 A3 using the UTF-8 character encoding, and then percent-encoded. Likewise, the Unicode euro sign character U+20AC was encoded into the octet sequence E2 82 AC, and then percent-encoded. Also note that HEXDIG allows both lowercase and uppercase characters, so recipients must understand both, and that the language information is optional, while the character encoding is not.
注：Unicodeポンド記号文字U + 00A3は、UTF-8文字エンコードを使用してオクテットシーケンスC2 A3にエンコードされ、パーセントエンコードされました。同様に、Unicodeユーロ記号文字U + 20ACはオクテットシーケンスE2 82 ACにエンコードされ、パーセントエンコードされました。また、HEXDIGは小文字と大文字の両方を使用できるため、受信者は両方を理解する必要があり、言語情報はオプションですが、文字エンコードはオプションではありません。
Section 5 of [RFC2231] extends the encoding defined in [RFC2047] to also support language specification in encoded words. RFC 2616, the now-obsolete HTTP/1.1 specification, did refer to RFC 2047 ([RFC2616], Section 2.2). However, it wasn't clear to which header field it applied. Consequently, the current revision of the HTTP/1.1 specification has deprecated use of the encoding forms defined in RFC 2047 (see Section 3.2.4 of [RFC7230]).
[RFC2231]のセクション5は、[RFC2047]で定義されたエンコードを拡張して、エンコードされた単語の言語仕様もサポートします。廃止されたHTTP / 1.1仕様であるRFC 2616は、RFC 2047（[RFC2616]、セクション2.2）を参照していました。ただし、どのヘッダーフィールドに適用するかは明確ではありませんでした。その結果、HTTP / 1.1仕様の現在のリビジョンでは、RFC 2047で定義されたエンコード形式の使用が非推奨になりました（[RFC7230]のセクション3.2.4を参照）。
Thus, this specification does not include this feature.
したがって、この仕様にはこの機能は含まれていません。
Specifications of HTTP header fields that use the extensions defined in Section 3.2 ought to clearly state that. A simple way to achieve this is to normatively reference this specification and to include the ext-value production into the ABNF for specific header field parameters.
セクション3.2で定義された拡張機能を使用するHTTPヘッダーフィールドの仕様は、それを明確に示す必要があります。これを実現する簡単な方法は、この仕様を規範的に参照し、特定のヘッダーフィールドパラメータのABNFに外部値生成を含めることです。
For instance:
例えば：
foo = token ";" LWSP title-param
title-param = "title" LWSP "=" LWSP value
/ "title*" LWSP "=" LWSP ext-value
ext-value = <see RFC 8187, Section 3.2>
Note: The Parameter Value Continuation feature defined in Section 3 of [RFC2231] makes it impossible to have multiple instances of extended parameters with identical names, as the processing of continuations would become ambiguous. Thus, specifications using this extension are advised to disallow this case for compatibility with RFC 2231.
注：[RFC2231]のセクション3で定義されているパラメーター値の継続機能では、継続の処理があいまいになるため、同じ名前の拡張パラメーターの複数のインスタンスを持つことはできません。したがって、この拡張機能を使用する仕様では、RFC 2231との互換性のためにこのケースを許可しないことをお勧めします。
Note: This specification does not automatically assign a new interpretation to parameter names ending in an asterisk. As pointed out above, it's up to the specification for the non-extended parameter to "opt in" to the syntax defined here. That being said, some existing implementations are known to automatically switch to using this notation when a parameter name ends with an asterisk; thus, using parameter names ending in an asterisk for something else is likely to cause interoperability problems.
注：この仕様では、アスタリスクで終わるパラメーター名に新しい解釈が自動的に割り当てられることはありません。上記で指摘したように、ここで定義されている構文に「オプトイン」するのは、非拡張パラメーターの仕様次第です。そうは言っても、パラメータ名がアスタリスクで終わる場合、一部の既存の実装はこの表記法の使用に自動的に切り替わることが知られています。そのため、アスタリスクで終わるパラメーター名を別のものに使用すると、相互運用性の問題が発生する可能性があります。
Section 4.2 of [RFC2277] requires that protocol elements containing human-readable text be able to carry language information. Thus, the ext-value production ought to always be used when the parameter value is of a textual nature and its language is known.
[RFC2277]のセクション4.2では、人間が読めるテキストを含むプロトコル要素が言語情報を伝達できる必要があります。したがって、ext-valueプロダクションは、パラメーター値がテキストの性質であり、その言語がわかっている場合は常に使用する必要があります。
Furthermore, the extension ought to also be used whenever the parameter value needs to carry characters not present in the US-ASCII coded character set ([RFC0020]); note that it would be unacceptable to define a new parameter that would be restricted to a subset of the Unicode character set.
さらに、パラメータ値がUS-ASCIIコード化文字セット（[RFC0020]）に存在しない文字を運ぶ必要がある場合は常に、拡張機能も使用する必要があります。 Unicode文字セットのサブセットに制限される新しいパラメーターを定義することは受け入れられないことに注意してください。
Header field specifications need to define whether multiple instances of parameters with identical names are allowed and how they should be processed. This specification suggests that a parameter using the extended syntax takes precedence. This would allow producers to use both formats without breaking recipients that do not understand the extended syntax yet.
ヘッダーフィールドの仕様では、同じ名前のパラメーターの複数のインスタンスを許可するかどうか、およびそれらの処理方法を定義する必要があります。この仕様は、拡張構文を使用するパラメーターが優先されることを示唆しています。これにより、プロデューサーは、拡張構文をまだ理解していない受信者を壊すことなく、両方のフォーマットを使用できます。
Example:
例：
foo: bar; title="EURO exchange rates";
title*=utf-8''%e2%82%ac%20exchange%20rates
In this case, the sender provides an ASCII version of the title for legacy recipients, but also includes an internationalized version for recipients understanding this specification -- the latter obviously ought to prefer the new syntax over the old one.
この場合、送信者はレガシー受信者にタイトルのASCIIバージョンを提供しますが、この仕様を理解する受信者のための国際化バージョンも含みます。後者は明らかに古い構文よりも新しい構文を優先するはずです。
The format described in this document makes it possible to transport non-ASCII characters, and thus enables character "spoofing" scenarios in which a displayed value appears to be something other than it is.
このドキュメントで説明する形式を使用すると、ASCII以外の文字を転送できるため、表示される値が実際の文字とは異なるものに見える文字の "なりすまし"シナリオが可能になります。
Furthermore, there are known attack scenarios related to decoding UTF-8.
さらに、UTF-8のデコードに関連する既知の攻撃シナリオがあります。
See Section 10 of [RFC3629] for more information on both topics.
両方のトピックの詳細については、[RFC3629]のセクション10を参照してください。
In addition, the extension specified in this document makes it possible to transport multiple language variants for a single parameter, and such use might allow spoofing attacks where different language versions of the same parameter are not equivalent. Whether this attack is effective as an attack depends on the parameter specified.
さらに、このドキュメントで指定されている拡張機能を使用すると、1つのパラメーターで複数の言語のバリアントを転送できます。このような使用により、同じパラメーターの異なる言語バージョンが同等でないスプーフィング攻撃が可能になる場合があります。この攻撃が攻撃として効果的であるかどうかは、指定されたパラメーターによって異なります。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <https://www.rfc-editor.org/info/rfc20>.
[RFC0020] Cerf、V。、「ネットワーク交換用のASCII形式」、STD 80、RFC 20、DOI 10.17487 / RFC0020、1969年10月、<https://www.rfc-editor.org/info/rfc20>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978, October 2000, <https://www.rfc-editor.org/info/rfc2978>.
[RFC2978] Freed、N。およびJ. Postel、「IANA Charset Registration Procedures」、BCP 19、RFC 2978、DOI 10.17487 / RFC2978、2000年10月、<https://www.rfc-editor.org/info/rfc2978> 。
[RFC3629] 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>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https://www.rfc-editor.org/info/ rfc3629>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：/ /www.rfc-editor.org/info/rfc3986>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC5646]フィリップス、A。、エド。 M.デイビス編、「言語を識別するためのタグ」、BCP 47、RFC 5646、DOI 10.17487 / RFC5646、2009年9月、<https://www.rfc-editor.org/info/rfc5646>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<https://www.rfc-editor.org/info/ rfc7230>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<https://www.rfc-editor.org/info/rfc7231 >。
[Err1912] RFC Errata, "Erratum ID 1912, RFC 2978", <https://www.rfc-editor.org/errata/eid1912>.
[Err1912] RFC Errata、「Erratum ID 1912、RFC 2978」、<https://www.rfc-editor.org/errata/eid1912>。
[ISO-8859-1] International Organization for Standardization, "Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1", ISO/ IEC 8859-1:1998, 1998.
[ISO-8859-1]国際標準化機構、「情報技術-8ビットシングルバイトコード化グラフィック文字セット-パート1：ラテンアルファベットNo. 1」、ISO / IEC 8859-1：1998、1998。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <https://www.rfc-editor.org/info/rfc2045>.
[RFC2045] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、DOI 10.17487 / RFC2045、1996年11月、<https：//www.rfc- editor.org/info/rfc2045>。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, DOI 10.17487/RFC2047, November 1996, <https://www.rfc-editor.org/info/rfc2047>.
[RFC2047]ムーアK。、「MIME（多目的インターネットメール拡張）パート3：非ASCIIテキストのメッセージヘッダー拡張」、RFC 2047、DOI 10.17487 / RFC2047、1996年11月、<https：//www.rfc-editor .org / info / rfc2047>。
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, DOI 10.17487/RFC2231, November 1997, <https://www.rfc-editor.org/info/rfc2231>.
[RFC2231] Freed、N。およびK. Moore、「MIMEパラメータ値とエンコードされたワード拡張：文字セット、言語、および継続」、RFC 2231、DOI 10.17487 / RFC2231、1997年11月、<https：//www.rfc- editor.org/info/rfc2231>。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277, January 1998, <https://www.rfc-editor.org/info/rfc2277>.
[RFC2277] Alvestrand、H。、「文字セットと言語に関するIETFポリシー」、BCP 18、RFC 2277、DOI 10.17487 / RFC2277、1998年1月、<https://www.rfc-editor.org/info/rfc2277>。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/RFC2616, June 1999, <https://www.rfc-editor.org/info/rfc2616>.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、DOI 10.17487 / RFC2616、1999年6月、<https://www.rfc-editor.org/info/rfc2616>。
[RFC5987] Reschke, J., "Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters", RFC 5987, DOI 10.17487/RFC5987, August 2010, <https://www.rfc-editor.org/info/rfc5987>.
[RFC5987] Reschke、J。、「ハイパーテキスト転送プロトコル（HTTP）ヘッダーフィールドパラメーターの文字セットと言語エンコード」、RFC 5987、DOI 10.17487 / RFC5987、2010年8月、<https://www.rfc-editor.org/ info / rfc5987>。
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/RFC5988, October 2010, <https://www.rfc-editor.org/info/rfc5988>.
[RFC5988]ノッティンガム、M。、「Webリンク」、RFC 5988、DOI 10.17487 / RFC5988、2010年10月、<https://www.rfc-editor.org/info/rfc5988>。
[RFC6266] Reschke, J., "Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)", RFC 6266, DOI 10.17487/RFC6266, June 2011, <https://www.rfc-editor.org/info/rfc6266>.
[RFC6266] Reschke、J。、「ハイパーテキスト転送プロトコル（HTTP）でのContent-Dispositionヘッダーフィールドの使用」、RFC 6266、DOI 10.17487 / RFC6266、2011年6月、<https://www.rfc-editor.org / info / rfc6266>。
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, DOI 10.17487/RFC6365, September 2011, <https://www.rfc-editor.org/info/rfc6365>.
[RFC6365] Hoffman、P。およびJ. Klensin、「IETFの国際化で使用される用語」、BCP 166、RFC 6365、DOI 10.17487 / RFC6365、2011年9月、<https://www.rfc-editor.org/info / rfc6365>。
[RFC7578] Masinter, L., "Returning Values from Forms: multipart/ form-data", RFC 7578, DOI 10.17487/RFC7578, July 2015, <https://www.rfc-editor.org/info/rfc7578>.
[RFC7578] Masinter、L。、「Returning Values from Forms：multipart / form-data」、RFC 7578、DOI 10.17487 / RFC7578、2015年7月、<https://www.rfc-editor.org/info/rfc7578>。
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <https://www.rfc-editor.org/info/rfc7616>.
[RFC7616] Shekh-Yusef、R.、Ed。、Ahrens、D。、およびS. Bremer、「HTTP Digest Access Authentication」、RFC 7616、DOI 10.17487 / RFC7616、2015年9月、<https：//www.rfc- editor.org/info/rfc7616>。
[RFC8053] Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, T., and Y. Ioku, "HTTP Authentication Extensions for Interactive Clients", RFC 8053, DOI 10.17487/RFC8053, January 2017, <https://www.rfc-editor.org/info/rfc8053>.
[RFC8053]大岩裕、渡辺博、高木宏、前田健、林孝、井奥裕、「インタラクティブクライアント用のHTTP認証拡張機能」、RFC 8053、DOI 10.17487 / RFC8053、 2017年1月、<https://www.rfc-editor.org/info/rfc8053>。
[XMLHttpRequest] WhatWG, "XMLHttpRequest", <https://xhr.spec.whatwg.org/>.
[XMLHttpRequest] WhatWG、「XMLHttpRequest」、<https://xhr.spec.whatwg.org/>。
This section summarizes the changes compared to [RFC5987]:
このセクションでは、[RFC5987]と比較した変更を要約します。
o The document title was changed to "Indicating Character Encoding and Language for HTTP Header Field Parameters".
o ドキュメントのタイトルが「HTTPヘッダーフィールドパラメータの文字エンコーディングと言語を示す」に変更されました。
o The introduction was rewritten to better explain the issues around non-ASCII characters in field values.
o 概要は、フィールド値の非ASCII文字に関する問題をより適切に説明するために書き直されました。
o The requirement to support the "ISO-8859-1" encoding was removed.
o 「ISO-8859-1」エンコーディングをサポートする要件は削除されました。
o This document no longer attempts to redefine a generic "parameter" ABNF (it turned out that there really isn't a generic definition of parameters in HTTP; for instance, there are subtle differences with respect to whitespace handling).
o このドキュメントでは、一般的な「パラメーター」ABNFを再定義することはもうありません（実際には、HTTPにはパラメーターの一般的な定義はありません。たとえば、空白の処理に関して微妙な違いがあります）。
o A note about defects in error handling in current implementations was removed, as it was no longer accurate.
o 現在の実装でのエラー処理の欠陥についてのメモは、正確でなくなったため削除されました。
The encoding defined in this document is currently used in four different HTTP header fields:
このドキュメントで定義されているエンコーディングは、現在4つの異なるHTTPヘッダーフィールドで使用されています。
o "Authentication-Control", defined in [RFC8053],
o [Authentication-Control]、[RFC8053]で定義、
o "Authorization" (as used in HTTP Digest Authentication, defined in [RFC7616]),
o 「承認」（[RFC7616]で定義されているHTTPダイジェスト認証で使用される）、
o "Content-Disposition", defined in [RFC6266], and
o [RFC6266]で定義されている「Content-Disposition」、および
o "Link", defined in [RFC5988].
o 「リンク」、[RFC5988]で定義されています。
As the encoding is a profile/clarification of the one defined in [RFC2231] in 1997, many user agents already supported it for use in "Content-Disposition" when [RFC5987] was published.
エンコーディングは1997年に[RFC2231]で定義されたもののプロファイル/明確化であるため、多くのユーザーエージェントは、[RFC5987]の公開時に「Content-Disposition」での使用をすでにサポートしています。
Since the publication of [RFC5987], three more popular desktop user agents have added support for this encoding; see <http://purl.org/NET/http/content-disposition-tests#encoding-2231-char> for details. At this time, the current versions of all major desktop user agents support it.
[RFC5987]の公開以来、さらに3つの人気のあるデスクトップユーザーエージェントがこのエンコーディングのサポートを追加しています。詳細については、<http://purl.org/NET/http/content-disposition-tests#encoding-2231-char>を参照してください。現時点では、すべての主要なデスクトップユーザーエージェントの現在のバージョンでサポートされています。
Note that the implementation in Internet Explorer 9 does not support the ISO-8859-1 character encoding; this document revision acknowledges that UTF-8 is sufficient for expressing all code points and removes the requirement to support ISO-8859-1.
Internet Explorer 9の実装はISO-8859-1文字エンコードをサポートしていないことに注意してください。このドキュメントの改訂では、UTF-8ですべてのコードポイントを表現するのに十分であることを認め、ISO-8859-1をサポートするための要件を削除します。
The "Link" header field, on the other hand, was more recently specified in [RFC5988]. At the time of this writing, no user agent except Firefox supported the "title*" parameter (starting with release 15).
一方、「Link」ヘッダーフィールドは、[RFC5988]で最近指定されました。この記事の執筆時点では、Firefox以外のユーザーエージェントは "title *"パラメーターをサポートしていません（リリース15以降）。
Section 3.4 of [RFC7616] defines the "username*" parameter for use in HTTP Digest Authentication. At the time of writing, no user agent implemented this extension.
[RFC7616]のセクション3.4は、HTTPダイジェスト認証で使用する「username *」パラメータを定義しています。執筆時点では、この拡張機能を実装したユーザーエージェントはありません。
Acknowledgements
謝辞
Thanks to Martin Dürst and Frank Ellermann for help figuring out ABNF details, to Graham Klyne and Alexey Melnikov for general review, to Chris Newman for pointing out an RFC 2231 incompatibility, and to Benjamin Carlyle, Roar Lauritzsen, Eric Lawrence, and James Manger for implementers feedback.
ABNFの詳細を理解するのを手伝ってくれたMartinDürstとFrank Ellermann、一般的なレビューをしてくれたGraham KlyneとAlexey Melnikov、RFC 2231の非互換性を指摘してくれたChris Newman、そしてベンジャミンカーライル、Roar Lauritzsen、Eric Lawrence、James Mangerに感謝します。実装者のフィードバック。
Furthermore, thanks to the members of the IETF HTTP Working Group for the feedback specific to this update of RFC 5987.
さらに、RFC 5987のこの更新に固有のフィードバックを提供したIETF HTTPワーキンググループのメンバーに感謝します。
Author's Address
著者のアドレス
Julian F. Reschke greenbytes GmbH Hafenweg 16 Münster, NW 48155 Germany
Julian F. Reschke greenbytes GmbH Hafenweg 16Münster、NW 48155 Germany
Email: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/