Internet Engineering Task Force (IETF) J. Reschke
Request for Comments: 6266 greenbytes
Updates: 2616 June 2011
Category: Standards Track
ISSN: 2070-1721
Use of the Content-Disposition Header Field in the
Hypertext Transfer Protocol (HTTP)
Abstract
抽象
RFC 2616 defines the Content-Disposition response header field, but points out that it is not part of the HTTP/1.1 Standard. This specification takes over the definition and registration of Content-Disposition, as used in HTTP, and clarifies internationalization aspects.
RFC 2616は、コンテンツの廃棄応答ヘッダーフィールドを定義し、それはHTTP / 1.1規格の一部ではないことを指摘しています。この仕様は、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/rfc6266.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6266で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 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 ..........................................3
3. Conformance and Error Handling ..................................3
4. Header Field Definition .........................................3
4.1. Grammar ....................................................4
4.2. Disposition Type ...........................................5
4.3. Disposition Parameter: 'Filename' ..........................5
4.4. Disposition Parameter: Extensions ..........................6
4.5. Extensibility ..............................................7
5. Examples ........................................................7
6. Internationalization Considerations .............................8
7. Security Considerations .........................................8
8. IANA Considerations .............................................8
8.1. Registry for Disposition Values and Parameters .............8
8.2. Header Field Registration ..................................8
9. Acknowledgements ................................................9
10. References .....................................................9
10.1. Normative References ......................................9
10.2. Informative References ....................................9
Appendix A. Changes from the RFC 2616 Definition ..................11
Appendix B. Differences Compared to RFC 2183 ......................11
Appendix C. Alternative Approaches to Internationalization ........11
C.1. RFC 2047 Encoding ..........................................12
C.2. Percent Encoding ...........................................12
C.3. Encoding Sniffing ..........................................12
Appendix D. Advice on Generating Content-Disposition Header
Fields ................................................13
RFC 2616 defines the Content-Disposition response header field (Section 19.5.1 of [RFC2616]) but points out that it is not part of the HTTP/1.1 Standard (Section 15.5):
RFC 2616は、コンテンツディスポジションレスポンスヘッダフィールド（[RFC2616]のセクション19.5.1）を定義し、それはHTTP / 1.1規格（セクション15.5）の一部ではないことを指摘します。
Content-Disposition is not part of the HTTP standard, but since it is widely implemented, we are documenting its use and risks for implementers.
コンテンツ配置はHTTP標準の一部ではありませんが、それは広く実装されているので、我々は、実装のためのその使用とリスクを文書化しています。
This specification takes over the definition and registration of Content-Disposition, as used in HTTP. Based on interoperability testing with existing user agents (UAs), it fully defines a profile of the features defined in the Multipurpose Internet Mail Extensions (MIME) variant ([RFC2183]) of the header field, and also clarifies internationalization aspects.
この仕様は、HTTPで使用されるように、定義およびContent-処分の登録を引き継ぎます。既存のユーザエージェント（UAS）との相互運用性テストに基づいて、それが完全にヘッダフィールドの多目的インターネットメール拡張（MIME）変異体（[RFC2183]）で定義されたフィーチャのプロファイルを定義し、また、国際化の側面を明らかにしています。
Note: This document does not apply to Content-Disposition header fields appearing in payload bodies transmitted over HTTP, such as when using the media type "multipart/form-data" ([RFC2388]).
注：この文書は、（[RFC2388]）をメディアタイプ「multipart / form-data」を使用する場合のようにHTTPを介して送信ペイロード体に現れるのContent-Dispositionヘッダーフィールドには適用されません。
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 augmented BNF (ABNF) notation defined in Section 2.1 of [RFC2616], including its rules for implied linear whitespace (LWS).
この仕様は、暗黙の線形空白（LWS）のためにそのルールを含む[RFC2616]のセクション2.1で定義された拡張BNF（ABNF）の表記を使用します。
This specification defines conformance criteria for both senders (usually, HTTP origin servers) and recipients (usually, HTTP user agents) of the Content-Disposition header field. An implementation is considered conformant if it complies with all of the requirements associated with its role.
この仕様は、Content-Dispositionヘッダーフィールドの両方の送信者（通常、HTTP起源サーバ）と受信者（通常、HTTPユーザエージェント）のための適合性基準を定義しています。それはその役割に関連付けられている要件のすべてに適合していた場合に実装が準拠とみなされます。
This specification also defines certain forms of the header field value to be invalid, using both ABNF and prose requirements (Section 4), but it does not define special handling of these invalid field values.
本明細書はまた、ABNFと散文要件（セクション4）の両方を使用して、ヘッダフィールド値の特定の形態は無効であると定義され、それは、これらの無効なフィールド値の特別な処理を定義していません。
Senders MUST NOT generate Content-Disposition header fields that are invalid.
差出人は無効であるのContent-Dispositionヘッダーフィールドを生成してはなりません。
Recipients MAY take steps to recover a usable field value from an invalid header field, but SHOULD NOT reject the message outright, unless this is explicitly desirable behavior (e.g., the implementation is a validator). As such, the default handling of invalid fields is to ignore them.
受信者は、無効なヘッダフィールドから、使用可能なフィールド値を回復するための手順を取ることができるが、これは明示的に望ましい行動（例えば、実装はバリデータ）である場合を除き、完全メッセージを拒否すべきではありません。そのため、無効なフィールドのデフォルトの処理は、それらを無視することです。
The Content-Disposition response header field is used to convey additional information about how to process the response payload, and also can be used to attach additional metadata, such as the filename to use when saving the response payload locally.
コンテンツの廃棄レスポンスヘッダフィールドは、応答ペイロードを処理する方法についての追加情報を伝えるために使用され、また、局所的に応答ペイロードを保存するときに使用するファイル名として、追加のメタデータを取り付けるために使用することができます。
content-disposition = "Content-Disposition" ":"
disposition-type *( ";" disposition-parm )
disposition-type = "inline" | "attachment" | disp-ext-type ; case-insensitive disp-ext-type = token
処分型=「インライン」| 「添付ファイル」| DISP-EXT-タイプ。大文字と小文字を区別しないトークン= DISP-EXT-タイプ
disposition-parm = filename-parm | disp-ext-parm
処分-PARM =ファイル名-PARM | DISP-EXT-PARM
filename-parm = "filename" "=" value | "filename*" "=" ext-value
ファイル名-PARM = "ファイル名" "=" 値| "ファイル名*" "=" EXT-値
disp-ext-parm = token "=" value | ext-token "=" ext-value ext-token = <the characters in token, followed by "*">
DISP-EXT-PARM =トークン "=" 値| EXT-トークン "=" EXT-値EXT-トークン= <トークンの文字、 "*" に続きます>
Defined in [RFC2616]:
[RFC2616]で定義されています：
token = <token, defined in [RFC2616], Section 2.2> quoted-string = <quoted-string, defined in [RFC2616], Section 2.2> value = <value, defined in [RFC2616], Section 3.6> ; token | quoted-string
トークン= <トークン、[RFC2616]、セクション2.2で定義された>引用された文字列= <引用符で囲まれた文字列、[RFC2616]、セクション2.2で定義された> <[RFC2616]、セクション3.6で定義された値、>値=。トークン|引用符で囲まれた文字列
Defined in [RFC5987]:
[RFC5987]で定義されています：
ext-value = <ext-value, defined in [RFC5987], Section 3.2>
EXT-値= <EXT値、[RFC5987]で定義された、3.2節>
Content-Disposition header field values with multiple instances of the same parameter name are invalid.
同じパラメータ名の複数のインスタンスを有するコンテンツ-Dispositionヘッダーフィールドの値は無効です。
Note that due to the rules for implied linear whitespace (Section 2.1 of [RFC2616]), OPTIONAL whitespace can appear between words (token or quoted-string) and separator characters.
暗黙線形空白（[RFC2616]のセクション2.1）の規則になお、OPTIONAL空白は単語（トークンまたは引用文字列）と区切り文字の間に現れることができます。
Furthermore, note that the format used for ext-value allows specifying a natural language (e.g., "en"); this is of limited use for filenames and is likely to be ignored by recipients.
また、EXT-値に使用されるフォーマット（例えば、「EN」）自然言語を指定できることに注意してください。これは、ファイル名の限定使用のものであり、受信者によって無視される可能性が高いです。
If the disposition type matches "attachment" (case-insensitively), this indicates that the recipient should prompt the user to save the response locally, rather than process it normally (as per its media type).
気質タイプは「添付ファイルを」（大文字と小文字を区別せずに）一致した場合、これは、受信者がローカルに応答を保存するのではなく、通常のプロセス、それを（そのメディアタイプごとなど）を促す必要があることを示します。
On the other hand, if it matches "inline" (case-insensitively), this implies default processing. Therefore, the disposition type "inline" is only useful when it is augmented with additional parameters, such as the filename (see below).
それは「インライン」（大文字と小文字を区別せずに）一致する場合一方、これがデフォルトの処理を意味しています。それはそのようなファイル名などの追加のパラメータ（下記参照）で拡張されたときにそのため、配置タイプ「インライン」のみ有用です。
Unknown or unhandled disposition types SHOULD be handled by recipients the same way as "attachment" (see also [RFC2183], Section 2.8).
未知または未処理の配置タイプが受信者により「取付」（また、[RFC2183]を参照して、セクション2.8）と同じ方法で処理しなければなりません。
The parameters "filename" and "filename*", to be matched case-insensitively, provide information on how to construct a filename for storing the message payload.
パラメータ「ファイル名」と「ファイル名*」は、メッセージのペイロードを格納するためのファイル名を構築する方法についての情報を提供し、大文字と小文字を区別せずに照合します。
Depending on the disposition type, this information might be used right away (in the "save as..." interaction caused for the "attachment" disposition type), or later on (for instance, when the user decides to save the contents of the current page being displayed).
処分の種類に応じて、この情報は、ユーザーが内容を保存することを決定したときに、例えば、以降に（（相互作用は、「添付ファイル」気質のタイプのために生じた「...として保存」で）すぐに使用される可能性があります表示されている現在のページ）。
The parameters "filename" and "filename*" differ only in that "filename*" uses the encoding defined in [RFC5987], allowing the use of characters not present in the ISO-8859-1 character set ([ISO-8859-1]).
「ファイル名」と「ファイル名*が」だけで「ファイル名*」で異なるパラメータがISO-8859-1文字セットに存在しない文字の使用を可能にする、[RFC5987]で定義されたエンコーディングを使用して（[ISO-8859-1 ]）。
Many user agent implementations predating this specification do not understand the "filename*" parameter. Therefore, when both "filename" and "filename*" are present in a single header field value, recipients SHOULD pick "filename*" and ignore "filename". This way, senders can avoid special-casing specific user agents by sending both the more expressive "filename*" parameter, and the "filename" parameter as fallback for legacy recipients (see Section 5 for an example).
この仕様より以前の多くのユーザエージェントの実装は、「ファイル名*」パラメータを理解していません。 「ファイル名」と「ファイル名*」の両方が、単一のヘッダフィールド値に存在する場合したがって、受信者は、「ファイル名*」を選択し、「ファイル名」を無視するべきです。このように、送信者は、より表現「ファイル名*」パラメータ、およびレガシー受信者（例えば、セクション5を参照）のフォールバックとして、「ファイル名」パラメータの両方を送信することにより、特殊なケース、特定のユーザーエージェントを避けることができます。
It is essential that recipients treat the specified filename as advisory only, and thus be very careful in extracting the desired information. In particular:
受信者が唯一の顧問として指定されたファイル名を処理するため、必要な情報を抽出するには非常に注意することが不可欠です。特に：
o Recipients MUST NOT be able to write into any location other than one to which they are specifically entitled. To illustrate the problem, consider the consequences of being able to overwrite well-known system locations (such as "/etc/passwd"). One strategy to achieve this is to never trust folder name information in the filename parameter, for instance by stripping all but the last path segment and only considering the actual filename (where 'path segments' are the components of the field value delimited by the path separator characters "\" and "/").
O受信者は、彼らが具体的に権利を与えられたもの以外の任意の場所に書き込むことができてはなりません。問題を説明するために、（例えば、「/ etc / passwdファイル」など）のよく知られたシステムの場所を上書きすることができるという結果を考慮。これを達成するための1つの戦略は、すべてが、最後のパスセグメントだけ「パスセグメントが」パスで区切られたフィールドの値の構成要素である実際のファイル名を（検討をストリッピングすることにより、たとえば、filenameパラメータでフォルダ名の情報を信頼したことがないことです区切り文字 "\" と "/"）。
o Many platforms do not use Internet Media Types ([RFC2046]) to hold type information in the file system, but rely on filename extensions instead. Trusting the server-provided file extension could introduce a privilege escalation when the saved file is later opened (consider ".exe"). Thus, recipients that make use of file extensions to determine the media type MUST ensure that a file extension is used that is safe, optimally matching the media type of the received payload.
O、多くのプラットフォームでは、ファイルシステム内の型情報を保持するために、インターネットメディアタイプ（[RFC2046]）を使用しますが、代わりにファイル名の拡張子に依存しないでください。保存したファイルは、後で（「.EXE」を検討）開かれたときに、サーバが提供するファイルの拡張子を信頼する権限昇格をもたらす可能性があります。したがって、メディアタイプを決定するために、ファイル拡張子を利用する受信者は、ファイル拡張子が最適に受信したペイロードのメディアタイプと一致する、安全であることに使用されていることを確認しなければなりません。
o Recipients SHOULD strip or replace character sequences that are known to cause confusion both in user interfaces and in filenames, such as control characters and leading and trailing whitespace.
O受信者は、このような制御文字と先頭と末尾の空白として、ユーザーインターフェイスにとファイル名の両方で混乱を引き起こすことが知られている文字列を取り除くか、交換する必要があります。
o Other aspects recipients need to be aware of are names that have a special meaning in the file system or in shell commands, such as "." and "..", "~", "|", and also device names. Recipients SHOULD ignore or substitute names like these.
他の態様oを受信者は、次のようなファイルシステムまたはシェルコマンドで特別な意味を持つ名前、あるのに注意する必要があり、「」そして、 ".."、 "〜"、 "|"、ともデバイス名。受信者は、これらのような名前を無視するか、代替すべきです。
Note: Many user agents do not properly handle the escape character "\" when using the quoted-string form. Furthermore, some user agents erroneously try to perform unescaping of "percent" escapes (see Appendix C.2), and thus might misinterpret filenames containing the percent character followed by two hex digits.
注：多くのユーザーエージェントが適切にエスケープ文字を処理しない「\」引用符で囲まれた文字列の形式を使用している場合。さらに、一部のユーザーエージェントが誤って「パーセント」エスケープ（付録C.2参照）のアンエスケープを実行しようとするため、二桁の数字が続くパーセント文字を含むファイル名を誤って解釈する可能性があります。
To enable future extensions, recipients SHOULD ignore unrecognized parameters (see also [RFC2183], Section 2.8).
将来の拡張を有効にするには、受信者が認識できないパラメータを無視すべきである（また、[RFC2183]のセクション2.8を参照してください）。
Note that Section 9 of [RFC2183] defines IANA registries both for disposition types and disposition parameters. This registry is shared by different protocols using Content-Disposition, such as MIME and HTTP. Therefore, not all registered values may make sense in the context of HTTP.
[RFC2183]のセクション9に留意されたい配置の種類及び配置パラメータの両方IANAレジストリを定義します。このレジストリは、MIMEやHTTPなどのContent-処分を使用して、異なるプロトコルによって共有されています。したがって、すべての登録された値は、HTTPの文脈で意味を行うことができます。
Direct the UA to show "save as" dialog, with a filename of "example.html":
「example.html」のファイル名で、ダイアログ「名前を付けて保存」を示すためにUAに指示：
Content-Disposition: Attachment; filename=example.html
コンテンツディスポジション：添付ファイル;ファイル名= example.html
Direct the UA to behave as if the Content-Disposition header field wasn't present, but to remember the filename "an example.html" for a subsequent save operation:
Content-Dispositionヘッダーフィールドが存在しなかったかのように振る舞うようにUAを指示しますが、ファイル名、その後の保存操作のための「example.html」を覚えています：
Content-Disposition: INLINE; FILENAME= "an example.html"
コンテンツディスポジション：インライン; FILENAME = "example.html"
Note: This uses the quoted-string form so that the space character can be included.
注意：これは、空白文字を含めることができるように、引用符で囲まれた文字列の形式を使用しています。
Direct the UA to show "save as" dialog, with a filename containing the Unicode character U+20AC (EURO SIGN):
Unicode文字U + 20AC（ユーロ記号）を含むファイル名で、ダイアログ「名前を付けて保存」を示すためにUAに指示：
Content-Disposition: attachment; filename*= UTF-8''%e2%82%ac%20rates
コンテンツディスポジション：添付ファイル;ファイル名* = UTF-8 '' ％E2は％82％交流％の20rates
Here, the encoding defined in [RFC5987] is also used to encode the non-ISO-8859-1 character.
ここでは、[RFC5987]で定義されたエンコーディングは、非ISO-8859-1文字をエンコードするために使用されます。
This example is the same as the one above, but adding the "filename" parameter for compatibility with user agents not implementing RFC 5987:
この例では、上記のものと同じであるが、ユーザエージェントはRFC 5987を実装していないとの互換性のために、「ファイル名」パラメータを追加します。
Content-Disposition: attachment;
filename="EURO rates";
filename*=utf-8''%e2%82%ac%20rates
Note: Those user agents that do not support the RFC 5987 encoding ignore "filename*" when it occurs after "filename".
注：それは、「ファイル名」の後に発生したときに「*ファイル名」RFC 5987エンコーディング無視をサポートしていないユーザエージェント。
The "filename*" parameter (Section 4.3), using the encoding defined in [RFC5987], allows the server to transmit characters outside the ISO-8859-1 character set, and also to optionally specify the language in use.
[RFC5987]で定義されたエンコーディングを使用して「ファイル名*」パラメータ（セクション4.3）、サーバは、ISO-8859-1文字セット以外の文字を送信するために、また、使用中の言語を指定任意することを可能にします。
Future parameters might also require internationalization, in which case the same encoding can be used.
将来のパラメータが同じエンコーディングを使用することができ、その場合には、国際化をも必要となる場合があります。
Using server-supplied information for constructing local filenames introduces many risks. These are summarized in Section 4.3.
ローカルのファイル名を構築するために、サーバが提供する情報を使用すると、多くのリスクを紹介します。これらは、4.3節にまとめられています。
Furthermore, implementers ought to be aware of the security considerations applying to HTTP (see Section 15 of [RFC2616]), and also the parameter encoding defined in [RFC5987] (see Section 5).
さらに、実装は、（[RFC2616]のセクション15を参照）HTTPに適用するセキュリティ問題に注意するべきで、また、[RFC5987]（セクション5を参照）で定義されたパラメータの符号化。
This specification does not introduce any changes to the registration procedures for disposition values and parameters that are defined in Section 9 of [RFC2183].
この仕様は、[RFC2183]のセクション9で定義されている配置値とパラメータの登録手順の変更を導入しません。
This document updates the definition of the Content-Disposition HTTP header field in the permanent HTTP header field registry (see [RFC3864]).
この文書は、永久的なHTTPヘッダフィールドレジストリにコンテンツの廃棄HTTPヘッダフィールドの定義を更新する（参照[RFC3864]）。
Header field name: Content-Disposition
ヘッダフィールド名：コンテンツ処分
Applicable protocol: http
該当するプロトコル：HTTP
Status: standard
ステータス：標準
Author/Change controller: IETF
著者/変更コントローラ：IETF
Specification document: this specification (Section 4)
仕様書：この仕様書（第4節）
Related information: none
関連情報：なし
Thanks to Adam Barth, Rolf Eike Beer, Stewart Bryant, Bjoern Hoehrmann, Alfred Hoenes, Roar Lauritzsen, Alexey Melnikov, Henrik Nordstrom, and Mark Nottingham for their valuable feedback.
彼らの貴重なフィードバックのためのアダム・バース、ロルフ・アイケビール、スチュワートブライアント、ビョルンHoehrmann、アルフレッドHoenes、ロア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月。
[RFC5987] Reschke, J., "Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters", RFC 5987, August 2010.
[RFC5987]、RFC 5987、2010年8月Reschke、J.、 "ハイパーテキスト転送プロトコル（HTTP）ヘッダフィールドパラメータのセットと言語文字エンコード"。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、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月。
[RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2183] Troost、R.、ドルナー、S.、およびK.ムーア、エド、 "インターネット・メッセージでプレゼンテーション情報を伝える：コンテンツ-Dispositionヘッダーフィールド"。、RFC 2183、1997年8月。
[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月。
[RFC2388] Masinter, L., "Returning Values from Forms: multipart/ form-data", RFC 2388, August 1998.
[RFC2388] Masinter、L.、 "フォームからの値返す：multipart / form-data" を、RFC 2388、1998年8月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864] Klyne、G.、ノッティンガム、M.、およびJ.モーグル、BCP 90、RFC 3864、2004年9月 "メッセージヘッダフィールドの登録手順"。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[US-ASCII] American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[US-ASCII]米国規格協会、 "コード化文字セット - 情報交換のための7ビットの米国標準コード"、ANSI X3.4、1986。
Appendix A. Changes from the Definition
付録A.定義からの変更点
Compared to Section 19.5.1 of [RFC2616], the following normative changes reflecting actual implementations have been made:
[RFC2616]のセクション19.5.1に比べ、実際の実装を反映し、次の規範的変更がなされてきました。
o According to RFC 2616, the disposition type "attachment" only applies to content of type "application/octet-stream". This restriction has been removed, because recipients in practice do not check the content type, and it also discourages properly declaring the media type.
O RFC 2616によれば、配置型「付着は」唯一のタイプ「アプリケーション/オクテットストリーム」の内容に適用されます。実際に受信者がコンテンツの種類を確認していないため、この制限は、削除されました、そしてそれはまた、適切にメディアタイプを宣言思いとどまら。
o RFC 2616 only allows "quoted-string" for the filename parameter. This would be an exceptional parameter syntax, and also doesn't reflect actual use.
O RFC 2616には、ファイル名のみパラメータに、「引用符で囲まれた文字列を」ことができます。これは例外的なパラメータの構文となり、また、実際の使用を反映するものではありません。
o The definition for the disposition type "inline" ([RFC2183], Section 2.1) has been re-added with a suggestion for its processing.
気質タイプ「インライン」（[RFC2183]、セクション2.1）の定義は、その処理のための提案で再追加された、O。
o This specification requires support for the extended parameter encoding defined in [RFC5987].
Oこの仕様は[RFC5987]で定義された拡張パラメータ符号化のためのサポートを必要とします。
Appendix B. Differences Compared to
に比べ付録B.違い
Section 2 of [RFC2183] defines several additional disposition parameters: "creation-date", "modification-date", "quoted-date-time", and "size". The majority of user agents do not implement these; thus, they have been omitted from this specification.
「作成日時」、「変更日付」、「引用された日付・時間」、および「サイズ」：[RFC2183]の第2節では、いくつかの追加処分のパラメータを定義します。ユーザーエージェントの大半はこれらを実装していません。このように、彼らはこの仕様から省略されています。
Appendix C. Alternative Approaches to Internationalization
付録C.代替は国際化へのアプローチ
By default, HTTP header field parameters cannot carry characters outside the ISO-8859-1 ([ISO-8859-1]) character encoding (see [RFC2616], Section 2.2). For the "filename" parameter, this of course is an unacceptable restriction.
デフォルトでは、HTTPヘッダフィールドパラメータは、ISO-8859-1（[ISO-8859-1]）の文字エンコード（[RFC2616]、セクション2.2を参照）以外の文字を運ぶことができません。 「ファイル名」パラメータには、もちろんの、これは容認できない制限です。
Unfortunately, user agent implementers have not managed to come up with an interoperable approach, although the IETF Standards Track specifies exactly one solution ([RFC2231], clarified and profiled for HTTP in [RFC5987]).
IETF標準化過程は正確に一つの解決策を指定するが、残念ながら、ユーザエージェントの実装は、相互運用可能なアプローチを思い付くために管理していない（[RFC2231]を、明確にし、[RFC5987]でHTTPのためのプロファイル）。
For completeness, the sections below describe the various approaches that have been tried, and explain how they are inferior to the RFC 5987 encoding used in this specification.
完全を期すために、以下のセクションでは、試されてきた様々なアプローチを説明し、それらが本明細書中で使用されるRFC 5987エンコーディングに劣っている方法を説明します。
C.1. Encoding
C.1。エンコーディング
RFC 2047 defines an encoding mechanism for header fields, but this encoding is not supposed to be used for header field parameters -- see Section 5 of [RFC2047]:
RFC 2047ヘッダーフィールドの符号化機構を定義するが、この符号化がヘッダーフィールドのパラメータのために使用することを想定していない - [RFC2047]のセクション5を参照してください。
An 'encoded-word' MUST NOT appear within a 'quoted-string'.
「エンコードされた単語は、」「引用符で囲まれた文字列」内に表示されてはなりません。
...
。。。
An 'encoded-word' MUST NOT be used in parameter of a MIME Content-Type or Content-Disposition field, or in any structured field body except within a 'comment' or 'phrase'.
「エンコードされた単語は、」「コメント」または「句」内を除き、または任意の構造化フィールド本文にMIMEのContent-Typeやコンテンツ・処分場のパラメータに使用してはいけません。
In practice, some user agents implement the encoding, some do not (exposing the encoded string to the user), and some get confused by it.
実際には、いくつかのユーザエージェントは、エンコーディングを実装し、いくつかは、（ユーザーへのエンコードされた文字列をさらす）ない、といくつかは、それによって混乱します。
C.2. Percent Encoding
C.2。パーセントエンコーディング
Some user agents accept percent-encoded ([RFC3986], Section 2.1) sequences of characters. The character encoding being used for decoding depends on various factors, including the encoding of the referring page, the user agent's locale, its configuration, and also the actual value of the parameter.
一部のユーザエージェントは、文字のパーセントエンコード（[RFC3986]、セクション2.1）の配列を受け入れます。復号化のために使用されている文字エンコーディングは、参照ページの符号化、ユーザーエージェントのロケール、その構成、及び、パラメータの実際の値を含む様々な因子に依存します。
In practice, this is hard to use because those user agents that do not support it will display the escaped character sequence to the user. For those user agents that do implement this, it is difficult to predict what character encoding they actually expect.
実際には、これはそれをサポートしていないユーザーエージェントは、ユーザーへのエスケープ文字列が表示されますので、使用するのは難しいです。これを実装するか、それらのユーザーエージェントの場合、彼らが実際に何を期待文字エンコーディングを予測することは困難です。
C.3. Encoding Sniffing
C.3。エンコーディングスニッフィング
Some user agents inspect the value (which defaults to ISO-8859-1 for the quoted-string form) and switch to UTF-8 when it seems to be more likely to be the correct interpretation.
一部のユーザーエージェントは、値（引用符で囲まれた文字列形式のためのISO-8859-1にデフォルト設定）を検査し、正しい解釈である可能性が高いように思わ時にUTF-8に切り替えます。
As with the approaches above, this is not interoperable and, furthermore, risks misinterpreting the actual value.
上記のアプローチと同様に、これは相互運用性ではないと、また、実際の値を誤って解釈リスク。
Appendix D. Advice on Generating Content-Disposition Header Fields
Content-Dispositionヘッダーフィールドを生成するには、付録D.を見ます
To successfully interoperate with existing and future user agents, senders of the Content-Disposition header field are advised to:
首尾よく既存および将来のユーザーエージェントと相互運用するには、コンテンツ-Dispositionヘッダーフィールドの送信者がすることをお勧めします：
o Include a "filename" parameter when US-ASCII ([US-ASCII]) is sufficiently expressive.
US-ASCIIは（[US-ASCII]）が十分に表現豊かであるときO "ファイル名" パラメータを含めます。
o Use the 'token' form of the filename parameter only when it does not contain disallowed characters (e.g., spaces); in such cases, the quoted-string form should be used.
Oそれは許されない文字（例えば、スペース）が含まれていない場合にのみ、ファイル名パラメータの「トークン」形式を使用します。このような場合には、引用符で囲まれた文字列の形式を使用する必要があります。
o Avoid including the percent character followed by two hexadecimal characters (e.g., %A9) in the filename parameter, since some existing implementations consider it to be an escape character, while others will pass it through unchanged.
その他は不変を通してそれを通過しながら、いくつかの既存の実装が、それはエスケープ文字であると考えるので、O、filenameパラメータに2つの16進文字（例えば、％A9）が続くパーセント文字を含む避けます。
o Avoid including the "\" character in the quoted-string form of the filename parameter, as escaping is not implemented by some user agents, and "\" can be considered an illegal path character.
O filenameパラメータの引用符で囲まれた文字列の形で「\」文字を含めないでください、エスケープは、いくつかのユーザエージェントによって実装され、「\」されていないとして違法なパス文字とみなすことができます。
o Avoid using non-ASCII characters in the filename parameter. Although most existing implementations will decode them as ISO-8859-1, some will apply heuristics to detect UTF-8, and thus might fail on certain names.
O filenameパラメータに非ASCII文字を使用しないでください。ほとんどの既存の実装はISO-8859-1としてそれらをデコードしますが、いくつかは、UTF-8を検出するヒューリスティックを適用するため、特定の名前の上に失敗することがあります。
o Include a "filename*" parameter where the desired filename cannot be expressed faithfully using the "filename" form. Note that legacy user agents will not process this, and will fall back to using the "filename" parameter's content.
O所望のファイル名が「ファイル名」の形式を使用して忠実に表現できない「ファイル名*」パラメータを含みます。そのレガシーユーザエージェントがこれを処理しませんし、「ファイル名」パラメータのコンテンツを使用するようにフォールバックします注意してください。
o When a "filename*" parameter is sent, to also generate a "filename" parameter as a fallback for user agents that do not support the "filename*" form, if possible. This can be done by substituting characters with US-ASCII sequences (e.g., Unicode character point U+00E4 (LATIN SMALL LETTER A WITH DIARESIS) by "ae"). Note that this may not be possible in some locales.
「ファイル名*」パラメータが送信されると、O、また可能な場合は、「ファイル名*」の形式をサポートしていないユーザーエージェントのための代替として、「ファイル名」のパラメータを生成します。これは、（「AE」により、例えば、Unicode文字ポイントU + 00E4（DIARESIS付きラテン小文字A））US-ASCII配列と置き換える文字で行うことができます。これは、いくつかのロケールでは可能ではないかもしれないことに注意してください。
o When a "filename" parameter is included as a fallback (as per above), "filename" should occur first, due to parsing problems in some existing implementations.
「ファイル名」パラメータは、（上記の通り）のフォールバックとして含まれている場合、O、「ファイル名」により、いくつかの既存の実装で問題を解析するには、最初に発生すべきです。
o Use UTF-8 as the encoding of the "filename*" parameter, when present, because at least one existing implementation only implements that encoding.
「ファイル名*」パラメータのエンコーディングとしてUTF-8 Oの使用は、存在する場合には、少なくとも一つの既存の実装は、それだけでエンコーディングを実装しているため。
Note that this advice is based upon UA behavior at the time of writing, and might be superseded. At the time of publication of this document, <http://purl.org/NET/http/content-disposition-tests> provides an overview of current levels of support in various implementations.
このアドバイスは、執筆時点でUAの挙動に基づいており、そして取って代わられるかもしれないことに注意してください。この文書の発行時点で、<http://purl.org/NET/http/content-disposition-tests>は、様々な実装では、支持体の電流レベルの概要を提供します。
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/