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



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


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 ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント(に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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
1. Introduction
1. はじめに

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を介して送信されたメッセージのペイロードには適用されません。

2. Notational Conventions

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を参照)を使用することに注意してください。より正確な用語は「文字エンコーディング」(オクテット配列にコードポイントのマッピング)であろう。

3. Comparison to and Definition of the Encoding

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 Character Set and Language Information are useful, therefore a simple subset is specified (Section 3.2), and


o Language Specifications in Encoded Words aren't needed (Section 3.3).


3.1. Parameter Continuations
3.1. パラメータの継続は

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).


Thus, parameter continuations are not part of the encoding defined by this specification.


3.2. Parameter Value Character Set and Language Information
3.2. パラメータ値の文字セットと言語の情報

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.


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は、文字セット情報が取り残さすることができます。この仕様で定義されたエンコーディングはそれを許可していません。

3.2.1. Definition
3.2.1. 定義

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).


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).


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]を参照してください)。実際には、その文字を使用して文字セット名は、この記事の執筆時点で登録されていません。

3.2.2. Examples
3.2.2. 例

Non-extended notation, using "token":


foo: bar; title=Economy


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は、両方とも大文字と小文字を許可すること、および文字セットではありませんしながら、言語情報は、オプションであることに注意してください。

3.3. Language Specification in Encoded Words
3.3. エンコードされた言葉で言語仕様

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 <> 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.


4. Guidelines for Usage in HTTP Header Field Definitions

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.


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との互換性のため、このケースを禁止することをお勧めします。

4.1. When to Use the Extension
4.1. 拡張を使用する場合

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.


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).


4.2. Error Handling
4.2. エラー処理

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.




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.


5. Security Considerations

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.


Furthermore, there are known attack scenarios relating to decoding UTF-8.


See Section 10 of [RFC3629] for more information on both topics.


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.


6. Acknowledgements

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へ。

7. References
7.1. Normative References
7.1. 引用規格

[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]米国規格協会、。

7.2. Informative References
7.2. 参考文献

[Err1912] RFC Errata, Errata ID 1912, RFC 2978, <>.

【Err1912] RFCエラッタ、エラッタのID 1912、RFC 2978、<>。

[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: URI:

電子メール URI: