[要約] RFC 6266は、HTTPでContent-Dispositionヘッダーフィールドの使用方法を定義しています。その目的は、Webブラウザがリソースのダウンロード時に正しいファイル名や表示方法を提案するためです。
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)
HyperText転送プロトコル（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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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で使用されるコンテンツディスポジションの定義と登録を引き継ぎます。既存のユーザーエージェント（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]).
注：このドキュメントは、メディアタイプの「MultiPart/Form-Data」（[RFC2388]）を使用する場合など、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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
This specification uses the augmented BNF (ABNF) notation defined in Section 2.1 of [RFC2616], including its rules for implied linear whitespace (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.
この仕様では、コンテンツディスポジションヘッダーフィールドの送信者（通常、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.
送信者は、無効なコンテンツディスポジションヘッダーフィールドを生成してはなりません。
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
disposition-parm = filename-parm | disp-ext-parm
処分-Parm = filename-parm |Disp-Ext-Parm
filename-parm = "filename" "=" value
| "filename*" "=" ext-value
disp-ext-parm = token "=" value
| ext-token "=" ext-value
ext-token = <the characters in token, followed by "*">
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
Defined in [RFC5987]:
[RFC5987]で定義されています。
ext-value = <ext-value, defined in [RFC5987], Section 3.2>
Content-Disposition header field values with multiple instances of the same parameter name are invalid.
同じパラメーター名の複数のインスタンスを備えたコンテンツ拡張ヘッダーフィールド値は無効です。
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）のルールがあるため、オプションの白文学は単語（トークンまたは引用符で引用されたストリング）とセパレーター文字の間に表示される可能性があることに注意してください。
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-valueに使用される形式では、自然言語を指定できることに注意してください（例： "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).
一方、「インライン」（case-insensitive）に一致する場合、これはデフォルトの処理を意味します。したがって、気質タイプ「インライン」は、ファイル名などの追加のパラメーターで補強されている場合にのみ役立ちます（以下を参照）。
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.
パラメーター「Filename」と「Filename*」は、ケースインスセンスに一致するように、メッセージペイロードを保存するためのファイル名を構築する方法に関する情報を提供します。
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).
処分の種類に応じて、この情報はすぐに使用される場合があります（「添付ファイル」処分タイプに引き起こされる「AS ...」相互作用）、または後で（たとえば、ユーザーがの内容を保存することを決定した場合に表示されている現在のページ）。
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]).
パラメーター「ファイル名」と「ファイル名*」は、[rfc5987]で定義されたエンコードを使用して、その「ファイル名*」でのみ異なり、ISO-8859-1文字セットに存在しない文字の使用を可能にします（[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).
この仕様に先行する多くのユーザーエージェントの実装では、「Filename*」パラメーターを理解していません。したがって、「ファイル名」と「ファイル名*」の両方が単一のヘッダーフィールド値に存在する場合、受信者は「ファイル名*」を選択し、「ファイル名」を無視する必要があります。これにより、送信者は、より表現力のある「ファイル名*」パラメーターと、レガシー受信者のフォールバックとして「ファイル名」パラメーターの両方を送信することにより、特別なケースの特定のユーザーエージェントを回避できます（例についてはセクション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を参照）。したがって、2つの16進数が続くパーセント文字を含むファイル名を誤解する可能性があります。
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などのコンテンツ拡散を使用して、異なるプロトコルによって共有されます。したがって、HTTPのコンテキストでは、すべての登録値が意味をなさないわけではありません。
Direct the UA to show "save as" dialog, with a filename of "example.html":
uaに「save as」ダイアログを表示するように指示し、「embles.html」のファイル名を備えています。
Content-Disposition: Attachment; filename=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 Headerフィールドが存在しないかのようにUAを指示しますが、後続の保存操作のためのファイル名「amemple.html」を覚えておいてください。
Content-Disposition: INLINE; FILENAME= "an 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):
UAに「Save As」ダイアログを表示するように指示し、Unicode文字u 20ac（ユーロサイン）を含むファイル名を備えています。
Content-Disposition: attachment;
filename*= UTF-8''%e2%82%ac%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]で定義されたエンコードを使用して、「Filename*」パラメーター（セクション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).
さらに、実装者は、HTTPに適用されるセキュリティ上の考慮事項（[RFC2616]のセクション15を参照）、および[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.
Adam Barth、Rolf Eike Beer、Stewart Bryant、Bjoern Hoehrmann、Alfred Hoenes、Roar Lauritzsen、Alexey Melnikov、Henrik Nordstrom、Mark Nottinghamの貴重なフィードバックに感謝します。
[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。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-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] Reschke、J。、「ハイパーテキスト転送プロトコル（HTTP）ヘッダーフィールドパラメーターの文字セットと言語エンコード」、RFC 5987、2010年8月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046] Freed、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.、Dorner、S。、およびK. Moore、ed。、「インターネットメッセージでのプレゼンテーション情報の通信：コンテンツ拡散ヘッダーフィールド」、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] Freed、N。およびK. Moore、「MIMEパラメーター値とエンコードされた単語拡張機能：文字セット、言語、継続」、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.、Nottingham、M。、およびJ. Mogul、「メッセージヘッダーフィールドの登録手順」、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] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、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] American National Standards Institute、「コード化された文字セット - 情報交換のための7ビットアメリカ標準コード」、ANSI X3.4、1986。
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.
o 処分タイプ「インライン」（[RFC2183]、セクション2.1）の定義には、その処理の提案が再び貼られています。
o This specification requires support for the extended parameter encoding defined in [RFC5987].
o この仕様には、[RFC5987]で定義された拡張パラメーターエンコードのサポートが必要です。
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では、「作成日」、「修正日」、「引用日課程」、「サイズ」といういくつかの追加の処分パラメーターを定義しています。ユーザーエージェントの大部分はこれらを実装していません。したがって、それらはこの仕様から省略されています。
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標準トラックは正確に1つのソリューション（[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エンコードより劣っている方法を説明します。
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コンテンツタイプまたはコンテンツ拡散フィールドのパラメーター、または「コメント」または「フレーズ」内を除く構造化されたフィールド本体で使用してはなりません。
In practice, some user agents implement the encoding, some do not (exposing the encoded string to the user), and some get confused by it.
実際には、一部のユーザーエージェントはエンコーディングを実装し、一部のユーザーエージェントは（エンコードされた文字列をユーザーに公開します）、一部のユーザーはそれによって混乱します。
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.
実際には、それをサポートしていないユーザーエージェントがユーザーに逃げた文字シーケンスを表示するため、これは使用するのが困難です。これを実装するユーザーエージェントにとって、実際に期待するキャラクターエンコードを予測することは困難です。
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.
上記のアプローチと同様に、これは相互運用可能ではなく、さらに、実際の値を誤って解釈するリスクがあります。
To successfully interoperate with existing and future user agents, senders of the Content-Disposition header field are advised to:
既存のユーザーエージェントと将来のユーザーエージェントと正常に相互運用するために、コンテンツディスポジションヘッダーフィールドの送信者は次のようにアドバイスされています。
o Include a "filename" parameter when US-ASCII ([US-ASCII]) is sufficiently expressive.
o us-ascii（[us-ascii]）が十分に表現力があるときに「ファイル名」パラメーターを含めます。
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 ファイル名パラメーターには、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 脱出は一部のユーザーエージェントによって実装されておらず、「\」は違法なパス文字と見なされる可能性があるため、「\」文字をファイル名パラメーターの引用された形式に含めることを避けます。
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としてそれらをデコードしますが、一部の人はHeuristicを適用して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 「ファイル名」フォームを使用して、目的のファイル名を忠実に表現できない「filename*」パラメーターを含めます。Legacyユーザーエージェントはこれを処理せず、「Filename」パラメーターのコンテンツを使用することに戻ることに注意してください。
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 「filename*」パラメーターが送信されると、「ファイル名*」フォームをサポートしていないユーザーエージェントのフォールバックとして「ファイル名」パラメーターを生成します。これは、文字をUS-ASCIIシーケンス（例：Unicode文字ポイントU 00E4（ダイアアレス付きラテン小文字A）で「AE」に置き換えることで実行できます。これは一部の地域では不可能かもしれません。
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.
o 少なくとも1つの既存の実装がそのエンコードのみを実装するため、存在する場合、「filename*」パラメーターのエンコードとしてUTF-8を使用します。
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
Julian F. Reschke Greenbytes GmbH Hafenweg 16 Muenster、NW 48155ドイツ
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/