Internet Engineering Task Force (IETF) J. Reschke
Request for Comments: 5987 greenbytes
Category: Standards Track August 2010
ISSN: 2070-1721
Character Set and Language Encoding for
Hypertext Transfer Protocol (HTTP) Header Field Parameters
Abstract
抽象
By default, message header field parameters in Hypertext Transfer Protocol (HTTP) messages cannot carry characters outside the ISO-8859-1 character set. RFC 2231 defines an encoding mechanism for use in Multipurpose Internet Mail Extensions (MIME) headers. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a profile of the encoding defined in RFC 2231.
デフォルトでは、ハイパーテキスト転送プロトコル（HTTP）のメッセージヘッダフィールドのパラメータは、メッセージがISO-8859-1文字セット以外の文字を運ぶことができません。 RFC 2231は、多目的インターネットメール拡張（MIME）ヘッダーに使用するための符号化機構を定義します。この文書は、RFC 2231で定義されたエンコーディングのプロファイルと互換性のあるHTTPヘッダフィールドでの使用に適した符号化を指定します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5987.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5987で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................2
2. Notational Conventions ..........................................2
3. Comparison to RFC 2231 and Definition of the Encoding ...........3
3.1. Parameter Continuations ....................................3
3.2. Parameter Value Character Set and Language Information .....3
3.2.1. Definition ..........................................3
3.2.2. Examples ............................................6
3.3. Language Specification in Encoded Words ....................6
4. Guidelines for Usage in HTTP Header Field Definitions ...........7
4.1. When to Use the Extension ..................................7
4.2. Error Handling .............................................7
5. Security Considerations .........................................8
6. Acknowledgements ................................................8
7. References ......................................................8
7.1. Normative References .......................................8
7.2. Informative References .....................................9
By default, message header field parameters in HTTP ([RFC2616]) messages cannot carry characters outside the ISO-8859-1 character set ([ISO-8859-1]). RFC 2231 ([RFC2231]) defines an encoding mechanism for use in MIME headers. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a profile of the encoding defined in RFC 2231.
デフォルトでは、HTTPのメッセージヘッダフィールドパラメータ（[RFC2616]）によってメッセージがISO-8859-1文字セット（[ISO-8859-1]）以外の文字を運ぶことができません。 RFC 2231（[RFC2231]）はMIMEヘッダで使用するための符号化機構を定義します。この文書は、RFC 2231で定義されたエンコーディングのプロファイルと互換性のあるHTTPヘッダフィールドでの使用に適した符号化を指定します。
Note: in the remainder of this document, RFC 2231 is only referenced for the purpose of explaining the choice of features that were adopted; they are therefore 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" ([RFC2388]).
注：このエンコーディングは、（[RFC2388]）「multipart / form-data」をメディアタイプを使用する場合のようにHTTPを介して送信されたメッセージのペイロードには適用されません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This specification uses the ABNF (Augmented Backus-Naur Form) 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（文字）、数字（小数0-9）、HEXDIG（16進数0-9 / AF / AF）、及びLWSP（線形空白）。
Note that this specification uses the term "character set" for consistency with other IETF specifications such as RFC 2277 (see [RFC2277], Section 3). A more accurate term would be "character encoding" (a mapping of code points to octet sequences).
この仕様は、RFC 2277のような他のIETF仕様の整合性のために、用語「文字セット」（[RFC2277]、セクション3を参照）を使用することに注意してください。より正確な用語は「文字エンコーディング」（オクテット配列にコードポイントのマッピング）であろう。
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 Set 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 ([RFC2616], Section 19.4.7).
[RFC2231]のセクション3は、MIMEヘッダに適用される長さの制限を扱う機構を定義します。これらの制限は、HTTP（[RFC2616]、セクション19.4.7）には適用されません。
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 parameters.
[RFC2231]のセクション4は、パラメータ値に言語情報を埋め込む方法、また、MIMEの両方の制約とHTTPヘッダパラメータを扱う、非ASCII文字をエンコードする方法を指定します。
However, RFC 2231 does not specify a mandatory-to-implement character set, making it hard for senders to decide which character set to use. Thus, recipients implementing this specification MUST support the character sets "ISO-8859-1" [ISO-8859-1] and "UTF-8" [RFC3629].
しかし、RFC 2231は難しい送信者が使用する文字セットを決定するために作る、実装に必須の文字セットを指定していません。このように、文字をサポートしなければならないこの仕様を実装する受信者は、 "ISO-8859-1" [ISO-8859-1]および "UTF-8" [RFC3629]を設定します。
Furthermore, RFC 2231 allows the character set information to be left out. The encoding defined by this specification does not allow that.
さらに、RFC 2231は、文字セット情報が取り残さすることができます。この仕様で定義されたエンコーディングはそれを許可していません。
The syntax for parameters is defined in Section 3.6 of [RFC2616] (with RFC 2616 implied LWS translated to RFC 5234 LWSP):
パラメータの構文は（RFC 5234 LWSPに翻訳RFC 2616暗黙LWS付き）[RFC2616]のセクション3.6で定義されています。
parameter = attribute LWSP "=" LWSP value
パラメータ=属性LWSP "=" LWSP値
attribute = token value = token / quoted-string
属性=トークン値=トークン/引用符で囲まれた文字列
quoted-string = <quoted-string, defined in [RFC2616], Section 2.2> token = <token, defined in [RFC2616], Section 2.2>
引用符で囲まれた文字列= <[RFC2616]で定義された引用文字列、セクション2.2>トークン= <トークンで定義された[RFC2616]、セクション2.2>
In order to include character set and language information, this specification modifies the RFC 2616 grammar to be:
文字セットと言語の情報を含めるために、この仕様はRFC 2616を変更する文法：
parameter = reg-parameter / ext-parameter
パラメータ= REG-パラメータ/ EXT-パラメータ
reg-parameter = parmname LWSP "=" LWSP value
REG-パラメータ= parmname LWSP "=" LWSP値
ext-parameter = parmname "*" LWSP "=" LWSP ext-value
EXT-パラメータ= parmname "*" LWSP "=" LWSPのEXT-値
parmname = 1*attr-char
parmname = 1 *のattr-CHAR
ext-value = charset "'" [ language ] "'" value-chars ; like RFC 2231's <extended-initial-value> ; (see [RFC2231], Section 7)
EXT-値=文字セット「「」[言語]「」」値、文字。 RFC 2231の<拡張初期値>のような。 （[RFC2231]、セクション7を参照）
charset = "UTF-8" / "ISO-8859-1" / mime-charset
文字セット= "UTF-8" / "ISO-8859-1" / MIME-文字セット
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
MIME-のcharset = 1 * MIME-charsetc MIME-charsetc = ALPHA / DIGIT / "！" / "＃" / "$" / "％" / "＆" / "+" / " - " / "^" / "_" / "`"/ "{"/ "}"/ "〜"。 [RFC2978]のセクション2.3で<MIME-文字セット>として;単一引用符が含まれていないことを除いて、 IANA文字セットレジストリに登録する必要があります
language = <Language-Tag, defined in [RFC5646], Section 2.1>
言語= <[RFC5646]で定義された言語タグ、2.1節>
value-chars = *( pct-encoded / attr-char )
価値の文字= *（PCTエンコード/ ATTR-チャー）
pct-encoded = "%" HEXDIG HEXDIG ; see [RFC3986], Section 2.1
PCTエンコード= "％" HEXDIG HEXDIG。 [RFC3986]、セクション2.1を参照してください
attr-char = ALPHA / DIGIT / "!" / "#" / "$" / "&" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" ; token except ( "*" / "'" / "%" )
ATTR-CHAR = ALPHA / DIGIT / "！" / "＃" / "$" / "＆" / "+" / " - " / "" / "^" / "_" / "`"/ "|" / "〜"。 （ "*" / "'" / "％"）を除いてトークン
Thus, a parameter is either a regular parameter (reg-parameter), as previously defined in Section 3.6 of [RFC2616], or an extended parameter (ext-parameter).
以前に[RFC2616]のセクション3.6、または拡張パラメータ（EXTパラメータ）で定義されるようにこのように、パラメータは、定期的なパラメータ（REGパラメータ）のいずれかです。
Extended parameters are those where the left-hand side of the assignment ends with an asterisk character.
拡張パラメータは、割り当ての左側にアスタリスク文字で終わるあるものです。
The value part of an extended parameter (ext-value) is a token that consists of three parts: the REQUIRED character set name (charset), the OPTIONAL language information (language), and a character sequence representing the actual value (value-chars), separated by single quote characters. Note that both character set names and language tags are restricted to the US-ASCII character set, and are matched case-insensitively (see [RFC2978], Section 2.3 and [RFC5646], Section 2.1.1).
拡張パラメータ（EXT-値）の値の一部は、3つの部分から構成されたトークンである：必要な文字セット名（文字セット）、オプションの言語情報（言語）、及び（価値の文字を実際の値を表す文字列）、単一引用符で区切られています。両方の文字が名前を設定し、言語タグは、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 set. That octet sequence is then percent-encoded as specified in Section 2.1 of [RFC3986].
値の部分の内部では、ATTR-CHARに含まれない文字は、指定された文字セットを使用してオクテットシーケンスにエンコードされています。 [RFC3986]のセクション2.1で指定されるようにそのオクテット配列は、次いで、パーセントエンコードされています。
Producers MUST use either the "UTF-8" ([RFC3629]) or the "ISO-8859-1" ([ISO-8859-1]) character set. Extension character sets (mime-charset) are reserved for future use.
プロデューサーは、 "UTF-8"（[RFC3629]）または "ISO-8859-1"（[ISO-8859-1]）文字セットのいずれかを使用しなければなりません。拡張文字セット（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,
*非デコード可能なオクテットシーケンスを除去、
* substituting a non-decodable octet sequence by a replacement character, such as the Unicode character U+FFFD (Replacement Character).
*このようなユニコード文字U + FFFD（置換文字）として、置換文字によって非復号可能なオクテットシーケンスを置換します。
Note: the RFC 2616 token production ([RFC2616], Section 2.2) differs from the production used in RFC 2231 (imported from Section 5.1 of [RFC2045]) in that curly braces ("{" and "}") are excluded. Thus, these two characters are excluded from the attr-char production as well.
注：その中括弧内のRFC 2616トークン生産（[RFC2616]、セクション2.2）RFC 2231で使用される生産は異なる（[RFC2045]のセクション5.1からインポート）（ "{" および "}"）は除外されます。したがって、これら2つの文字は、同様のattr-char型の生産から除外されています。
Note: 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 set names using that character have been registered at the time of this writing.
注意：ここで定義された<MIME-文字セット> ABNFは、単一引用符文字を許可しないことで、[RFC2978]のセクション2.3に1と異なって（また、RFC正誤表のID 1912 [Err1912]を参照してください）。実際には、その文字を使用して文字セット名は、この記事の執筆時点で登録されていません。
Non-extended notation, using "token":
非拡張表記、「トークン」を使用します：
foo: bar; title=Economy
FOO：バー;タイトル=経済
Non-extended notation, using "quoted-string":
非拡張表記、「引用符で囲まれた文字列」を使用して：
foo: bar; title="US-$ rates"
FOO：バー;タイトル= "US- $料金"
Extended notation, using the Unicode character U+00A3 (POUND SIGN):
ユニコード文字U + 00A3（ポンド記号）を使用して、表記の拡張：
foo: bar; title*=iso-8859-1'en'%A3%20rates
FOO：バー;タイトル* = ISO-8859-1'en '％A3％20rates
Note: the Unicode pound sign character U+00A3 was encoded into the single octet A3 using the ISO-8859-1 character encoding, then percent-encoded. Also, note that the space character was encoded as %20, as it is not contained in attr-char.
注：ユニコードポンド記号文字U + 00A3は、ISO-8859-1文字エンコーディングを使用して、単一のオクテットA3にエンコードした後、パーセントエンコード。また、それはATTR-CHARに含まれていないとして、空白文字は、％20としてエンコードされたことに注意してください。
Extended notation, using the Unicode characters U+00A3 (POUND SIGN) and U+20AC (EURO SIGN):
ユニコード文字U + 00A3（ポンド記号）とU + 20AC（ユーロ記号）を使用して拡張表記：
foo: bar; title*=UTF-8''%c2%a3%20and%20%e2%82%ac%20rates
FOO：バー;タイトル* = UTF-8 '' ％C2％A3％20および％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, then percent-encoded. Likewise, the Unicode euro sign character U+20AC was encoded into the octet sequence E2 82 AC, 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 set is not.
注：ユニコードポンド記号文字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. Although the HTTP/1.1 specification does refer to RFC 2047 ([RFC2616], Section 2.2), it's not clear to which header field exactly it applies, and whether it is implemented in practice (see <http://tools.ietf.org/wg/httpbis/trac/ticket/111> for details).
[RFC2231]のセクション5はまた、符号化された単語に言語仕様をサポートするために、[RFC2047]で定義されたエンコーディングを拡張します。 HTTP / 1.1仕様は、RFC 2047（[RFC2616]、セクション2.2）を参照しないが、それは正確にそれが適用されるヘッダフィールドには明らかではない、それが実際に実装されているか否か（<http://tools.ietf.org参照します/ WG / httpbis詳細については、/ tracの/チケット/ 111>）。
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 that header field.
3.2節で定義された拡張機能を使用するHTTPヘッダフィールドの仕様は明らかにそれを述べるべきです。これを達成する簡単な方法は、規範的この仕様を参照すると、そのヘッダフィールドのABNFにEXT-値の生成を含むことです。
For instance:
例えば：
foo-header = "foo" LWSP ":" LWSP token ";" LWSP title-param title-param = "title" LWSP "=" LWSP value / "title*" LWSP "=" LWSP ext-value ext-value = <see RFC 5987, Section 3.2>
FOOヘッダ= "foo" というLWSP "：" LWSPトークン ";" LWSPタイトルのparamタイトルのparam = "タイトル" LWSP "=" LWSP値/ "タイトル*" LWSP "=" LWSP EXT-値EXT-値= <RFC 5987、セクション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 parmname components, 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で定義されたパラメータ値継続機能は、それが不可能同じparmname成分と拡張パラメータの複数のインスタンスを有することができます。このように、この拡張機能を使用して仕様はRFC 2231との互換性のため、このケースを禁止することをお勧めします。
Section 4.2 of [RFC2277] requires that protocol elements containing human-readable text are able to carry language information. Thus, the ext-value production ought to be always used when the parameter value is of textual nature and its language is known.
[RFC2277]のセクション4.2は、人間可読テキストを含むプロトコル要素は、言語情報を搬送することが可能であることを必要とします。このように、EXT-値の生産は、パラメータ値がテキストの性質のもので、その言語が知られているときは、常に使用されるべきです。
Furthermore, the extension ought to also be used whenever the parameter value needs to carry characters not present in the US-ASCII ([USASCII]) character set (note that it would be unacceptable to define a new parameter that would be restricted to a subset of the Unicode character set).
さらに、拡張はまた、パラメータ値がUSASCII（[USASCII]）文字セットに存在しない文字を搬送する必要があるときはいつでも使用されるべきである（部分集合に制限されることになる新たなパラメータを定義することが許容されないであろうことに注意してくださいUnicode文字セットの）。
Header field specifications need to define whether multiple instances of parameters with identical parmname components 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.
ヘッダーフィールド仕様は、同一のparmnameコンポーネントとパラメータの複数のインスタンスが許可され、そしてそれらがどのように処理されるべきかどうかを定義する必要があります。この仕様は、拡張構文を使用してパラメータが優先されることを示唆しています。これは、生産者がまだ拡張構文を理解していない受信者を壊すことなく、両方のフォーマットを使用することができるようになります。
Example:
例：
foo: bar; title="EURO exchange rates"; title*=utf-8''%e2%82%ac%20exchange%20rates
FOO：バー;タイトル=「EUROの為替レート」。タイトル* = 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バージョンを提供するだけでなく、この仕様を理解する受信者の国際化バージョンが含まれて - 後者は明らかに古いものの上に新しい構文を好むべきです。
Note: at the time of this writing, many implementations failed to ignore the form they do not understand, or prioritize the ASCII form although the extended syntax was present.
注：この記事の執筆時点では、多くの実装は、彼らが理解していないフォームを無視し、または拡張構文が存在していたものの、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 relating 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 useful as an attack depends on the parameter specified.
また、この文書で指定された拡張子は、単一のパラメータに対して複数の言語バリエーションを輸送することが可能となり、かつそのような使用同じパラメータの異なる言語バージョンは同等ではありませんスプーフィング攻撃を許す可能性があります。この攻撃は、攻撃として有用であるかどうかは、指定されたパラメータに依存します。
Thanks to Martin Duerst 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 and Roar Lauritzsen for implementer's feedback.
実装のフィードバックのためのABNFの詳細を考え出す助けのためのマーティンDuerstとフランクEllermannのおかげで、一般的なレビューのためにグラハムKlyneとアレクセイ・メルニコフに、RFC 2231の非互換性を指摘してクリス・ニューマンに、そしてベンジャミンカーライルと咆哮Lauritzsenへ。
[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部：ラテンアルファベット1号"、ISO / IEC 8859-1：1998、1998。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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, June 1999.
[RFC2616]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.
[RFC2978]フリード、N.とJ.ポステル、 "IANA文字セット登録手順"、BCP 19、RFC 2978、2000年10月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, STD 63, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、RFC 3629、STD 63、2003年11月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、RFC 3986、STD 66、2005年1月。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646]フィリップス、A.編。そして、M.デイヴィス、エド。、 "言語を識別するためのタグ"、BCP 47、RFC 5646、2009年9月。
[USASCII] American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
「 - 情報交換のための7ビットの米国標準コードコード化文字セット」、ANSI X3.4、1986 [USASCII]米国規格協会、。
[Err1912] RFC Errata, Errata ID 1912, RFC 2978, <http://www.rfc-editor.org>.
【Err1912] RFCエラッタ、エラッタのID 1912、RFC 2978、<http://www.rfc-editor.org>。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]ムーア、K.、 "MIME（多目的インターネットメール拡張）パート3：非ASCIIテキストのためのメッセージヘッダの拡張"、RFC 2047、1996年11月。
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
[RFC2231]解放され、N.とK.ムーア、 "MIMEパラメータ値およびエンコードされたWordの機能拡張：文字セット、言語、および継続の"、RFC 2231、1997年11月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、 "文字セットと言語のIETF方針"、BCP 18、RFC 2277、1998年1月。
[RFC2388] Masinter, L., "Returning Values from Forms: multipart/ form-data", RFC 2388, August 1998.
[RFC2388] Masinter、L.、 "フォームからの値返す：multipart / form-data" を、RFC 2388、1998年8月。
Author's Address
著者のアドレス
Julian F. Reschke greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany
ジュリアン・F. Reschke greenbytes社Hafenweg 16ミュンスター、NW 48155ドイツ
EMail: julian.reschke@greenbytes.de URI: http://greenbytes.de/tech/webdav/
電子メール：julian.reschke@greenbytes.de URI：http://greenbytes.de/tech/webdav/