[27] 名前と値を =
で連ねた構文は引数と呼ばれています。
[63] MIME のほか、派生した電子メール、ネットニュース、HTTP、
RTSP、SIP、MSRP、CoAP、 multipart/form-data
といった様々なプロトコルで採用されている構文です。
[146] MIME においては RFC 2045 と RFC 2231 が、 HTTP においては RFC 7231 と RFC 5987 が引数構文の主要な仕様書となっています。
[61] 引数は、名前、=
、値で構成されます。ただし、以降で述べる通り、
その細部は利用される場面によって様々に異なっています。
[62] ほとんどの場面で引数は ;
区切りの零個以上のリストとして使われています。
[66] MIME の引数は、属性、区間、*
、
=
、値により構成されます。
ただし区間と *
はそれぞれ継続と拡張を表しており、
該当しない場合には省略されます。 >>21
=
の前後に空白 (RFC 822 では
linear-white-space
および comment
、
RFC 2822 や RFC 5322 では CFWS
) を挿入できると一般的には解釈されるようですが、
なんと MIME 関連 RFC では明文化されていません。またネットニュースでは
FWS
が挿入できると解釈するべきか、あるいは認められないと解釈するべきか、
明確ではありません。電子メール以外のプロトコルで MIME
を採用している場合や、 MIME を参照している場合にどう解釈するべきなのかも不明瞭です。[68] 属性は、1つ以上の属性に使える文字の列です >>21。 属性は一般には引数の名前とみなされています。属性は大文字・小文字不区別です。
[70] 区間は *
の後にASCII数字を連ねたものです。ただし先導0は認められていません。
>>21
[67] 値は、字句、引用文字列、拡張された最初の値、拡張されたその他の値の4つの指定方法があります。 >>21
[71] 拡張された最初の値は、charset、言語タグ、拡張されたその他の値相当の値を
'
で区切ったものです。ただし charset と言語タグは省略できます。 >>21
[72] 拡張されたその他の値は、属性に使える文字かパーセント符号化されたオクテットの0個以上の列です。 >>21
[77] 区間、継続を表す *
、値の各構文の組み合わせには、後述の通り制約があります。
[135] RFC 2183 は MIME Content-Disposition:
ヘッダーにおける値の構文の選択について、次のように述べています >>134。
[92] 引数のリストにおける区切り文字 ;
の前後には空白
(RFC 822 では linear-white-space / comment
、
RFC 2822 や RFC 5322 では CFWS
) が挿入できると解釈されています
(が RFC には明記されていません)。
;
の前には何も挿入せず、後には SPACE
を1つ挿入するのが一般的です。
[29] いわゆる引数構文は、それぞれで異なる定義になっています。 その多くは構文の一部を共有していますが、それぞれ個別の要件が課されていることがあります。
[30] RFC 7231 は新しいHTTPヘッダーについてできるだけ構文解析器を流用できるように共通の構文を採用することを求めています >>28。
Forwarded:
と
Prefer:
すら別々の構文を規定していますし...[60] 多くの場面では引数同士の区切りは ;
ですが、
いくつか例外的に ,
となっている (リスト (#
) になっている)
ことがあります。
[35] 多くの場面では ;
の前後に OWS
が含まれていますが、そうでない場面もあります。
[36] いくつかの場面では ;
の連続 (名前と値の組のかわりに空文字列)
が認められています。
[32] 値について字句と引用文字列の両方を認め、 その両者で意味を同じとすることをすすめています >>28。
[33] いくつかの場面では =
と値を省略できますが、
そうでない場面も多々あります。値の省略は空文字列の指定と同一視される場面もありますが、
そうでない場面もあります。
[34] いくつかの場面では =
の前後に BWS
が含まれていますが、そうでない場面もあります。
[38] 値は字句と引用文字列の両方の構文が認められ、どちらも同じ意味とするのが普通ですが、 その解釈が明記されていないことや、どちらか一方に限定されていること、 定義上一方に限定されているように書かれているものの行間や実態からどちらでも良いと解釈するべきこともあります。
[39] 名前はASCII大文字・小文字不区別で、値は区別されるのが普通ですが、 明記されていないこともあります。
[40] 多くの場面では同名の引数が複数ある場合の処置を明記していません。
[41] 多くの場合は引数の順序に意味があるか明記していませんが、 意味は無いのが普通です。
[95] RFC 5987 >>15 は、 MIME における RFC 2231 の構文を HTTP に当てはめたものを定義しています。
[99] 引数は、名前、拡張を表す *
、=
、
値で構成されます。ただし拡張構文を使わない場合は、 *
を省略します。 >>15
[100] =
の前後には LWSP
を挿入できます >>15, >>139。
ただその後出版された RFC 723x との整合性を考慮すると、これは
BWS
と解釈するべきでしょう。
[101] 引数名は、1文字以上の属性の文字の列です。
これは字句に使える文字から *
, '
, %
を除外したものです。 >>15
[103] 値は、字句、引用文字列、拡張された値のいずれかです >>15。
ただし名前の後に *
を指定した場合は拡張された値を、
指定しなかった場合はそれ以外を使う必要があります >>15。
[104] 拡張された値は、 charset、言語タグ、本来の値を '
で連結したものです >>15。
[105] 本来の値は0個以上の属性の文字かパーセント符号化されたオクテットの列です >>15。
[20] RFC 2231 は MIME の引数の拡張として、次の仕組みを追加しています >>21。
[25] RFC 5987 は HTTP の引数の拡張として >>22 と >>23 と >>59 を採用しています >>21。 >>24 は電子メールに由来する MIME の行長制限に対処するためなので、 HTTP では不要 >>15 とされています。
[87] RFC 2231 は MIME (RFC 2045) の引数の定義を更新しており、 同定義を参照するすべてのヘッダーのすべての引数に適用することを意図しているようにみえます。
[88] RFC 2231 に対する正誤表の報告 (>>58) は、 charset
や
boundary
のような主要な引数に適用すると旧来の
MIME の実装との互換性が失われてしまうと指摘しています。同報告はそのような引数で
RFC 2231 の拡張を適用している実装が既に存在しているとも指摘しています。
[125] HTTP においては拡張構文はすべての引数に適用されるわけではなく、 RFC 5987 は適用される場合仕様書で明示するべき >>15 としています。適用されるかどうかは、ヘッダーと引数ごとに決まります。
[126] RFC 5987 は、人間可読なテキストを含む引数や非ASCII文字を含む引数では拡張構文を採用するべき >>15 としています。
[133] HTTP Link:
ヘッダーの派生形式である
CoRE も title
引数で拡張構文を採用しています。
[94] MIME や HTTP 以外でそれらの定義を参照するプロトコル等にこれらの拡張が適用されるのかどうかは不明確です。 多くの場合はこれらの拡張は考慮されていません。
[45] MIME では、引数の名前の後に *
と数値を続けることで、
引数の値を複数の引数に分割できます。
[46] 例えば、
Content-Type: message/external-body; access-type=URL; URL*0="ftp://"; URL*1="cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"... は
Content-Type: message/external-body; access-type=URL; URL="ftp://cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"... と等価です >>21。
*
は使えなくなりました。[79] 仕様書の書き方から、 *0
から順に使用しなければならないとみられますが、
明言されていません。受信者も番号が若いものから順に連結していくべきとみられますが、
番号が飛んでいる場合にどうするべきなのか不明です。また同名・数の引数が複数存在するときにどう処理するべきなのかは不明です。
[49] MIME と HTTP では、引数の名前の後に *
を続けることで、引数の値の文字コードと言語タグの一方または両方を指定することができます。
[50] その場合の引数の値は、文字コード、言語タグ、本来の引数の値を
'
で連結したものとします。ただし文字コードと言語タグは省略して空文字列にできます。また本来の値はパーセント符号化します。
Content-Type: application/x-stuff; title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A... は、
Content-Type: application/x-stuff; title="This is ***fun***"... と等価ですが、 charset
us-ascii
と言語タグ
en-us
が指定されています。US-ASCII
と i-default
と解釈するべきでしょうか。[81] 指定方法が構文上正しくない (例えば '
が0個または1個しか含まれない)
場合にどう処理するべきなのかは不明です。
[157]
Content-Language:
も参照。
[53] MIME では、長い引数の継続構文と文字コードや言語タグを指定した符号化構文を組み合わせて使うことができます。
[55] 一組の引数を構成する分割された引数のそれぞれで、
旧来の字句または引用文字列の構文と拡張されたパーセント符号化の構文を混用できます。
パーセント符号化構文の場合は、引数の名前の分割番号の後に *
が付きます。
>>21
[54] 文字コードや言語タグの指定がある場合は、 最初 (0番) の引数に含めなければなりません。 その場合最初の引数は字句や引用文字列の構文にはできません。 >>21
[82] また最初の引数以外で文字コードや言語タグを指定することはできません。
一組の引数を構成する値のそれぞれで別の文字コードや言語タグを混在させることはできません >>21。
最初の引数以外で '
を使うことは構文上認められていません。
もし含まれていた場合にどう処理するべきなのかは不明です。
Content-Type: application/x-stuff; title*0*=us-ascii'en'This%20is%20even%20more%20; title*1*=%2A%2A%2Afun%2A%2A%2A%20; title*2="isn't it!"
[84] 多バイト文字コードにおける文字の途中のバイトで引数を分割して良いのか悪いのか、 状態を持つ文字コードで引数ごとに完結しない形で分割して良いのか悪いのか、 RFC には明記されていません。また拡張された構文と旧来の字句や引用文字列の構文が混在する場合に、 後者は常に ASCII として解釈するべきなのか、それとも ASCII に相当するバイト列として解釈するべきなのかは不明です。
[89] 拡張された引数と旧来の構文の引数で同名のものが重複して存在する時、 また継続構文を採用したものと符号化構文を採用したものとで重複して存在する時、 どのように処理するべきかは MIME 仕様上言及がありません。
[127] HTTP の仕様である RFC 5987 では、拡張された構文とそうでないもので重複している場合
(例えば title=...
と title*=...
が両方指定されている場合)
の処理の規定は拡張構文を採用するヘッダーの仕様書の責任としています >>15。
[128] RFC 5987 としては拡張構文を優先させることを提案しており、 未対応の実装に向けた旧来の構文の ASCII 版と拡張構文の版の両方を指定させられると述べています >>15。ただし既存の実装は未対応の引数を無視しなかったり、 旧来の構文を優先させたりする >>15 と当の RFC 5987 自身が述べており、実際に両方を指定してもどれだけ意味があるのかは疑問です。
[130] Link:
ヘッダーの title
引数はこれに従い、 title*
を優先するべきだ
>>129 としています。
[140] Content-Disposition:
ヘッダーの filename
引数でも、 filename*
を優先するべきだ
>>141 とされています。
[148] ダイジェスト認証の username
引数と
username*
引数が同時に指定されている場合、
誤りとされています。
[110] RFC 2231 / RFC 5987 で拡張された構文では、値の charset を指定できます。
[75] MIME では、 charset は登録された IANA charset 名とされています >>21。
[112] HTTP では UTF-8
または ISO-8859-1
(大文字・小文字不区別) とされています >>15。
このいずれかを生成しなければなりません >>15。
[113] ただし構文上はそれに加えて mime-charset
も認められています。
これは1文字以上の ASCIIラテン文字、ASCII数字、
!
, #
, $
, %
,
&
, +
, -
, ^
,
_
, `
, {
, }
,
~
の列とされています。これは IANA charset
として登録されたものとするべきです。
こちらは将来の利用のために予約されています。 >>15
[151] HTTPヘッダー Authentication-Control:
とHTTP認証の一種 Mutual
は、
UTF-8
のみを認めています >>150, >>153。
[117] MIME では charset を省略して空文字列にできますが、 HTTP では必ず指定しなければなりません。
[83] 指定された文字コードにより値を復号できない場合にどう処理するべきなのかは不明です。 MIME ではまったく言及されていませんが、 HTTP では次のような記述があります。
[120] 受信者は、不正や不完全なパーセント符号化や復号できないオクテット列などの符号化の誤りに対して頑健であるべきです >>15。具体的な方法は定めませんが、例えば次のような方法を採ることができます >>15。
[111] RFC 2231 / RFC 5987 で拡張された構文では、値の言語タグを指定できます。
[76] MIME では、言語タグは、登録された RFC 1766 言語タグとされています >>21。
[115] HTTP では、 RFC 5646 言語タグとされています >>15。
[118] MIME でも HTTP でも、言語タグは省略して空文字列にできます。
[152] HTTPヘッダー Authentication-Control:
と HTTP認証の一種 Mutual
は、
空文字列のみを認めています >>150, >>153。
TE:
Accept:
accept-params
chunked
auth-param
auth-control-param
Authentication-Info:
Forwarded:
Prefer:
Preference-Applied:
Content-Disposition:
Link:
Set-Cookie:
Set-Cookie2:
Cookie:
Cookie2:
Keep-Alive:
Accept-Features:
Accept-Additions:
OPES-System:
OPES-Via:
SHTTP-Privacy-Domains:
SHTTP-Certificate-Types:
SHTTP-Key-Exchange-Algorithms:
SHTTP-Signature-Algorithms:
SHTTP-Message-Digest-Algorithms:
SHTTP-Symmetric-Content-Algorithms:
SHTTP-Symmetric-Header-Algorithms:
SHTTP-MAC-Algorithms:
SHTTP-Privacy-Enhancements:
SHTTP-Cryptopts:
Surrogate-Capability:
Surrogate-Capabilities:
Proxy-Features:
PAOS:
Sec-WebSocket-Extensions:
Alt-Svc:
[64] IMAP4 鯖は、 MIME メッセージを処理する場合、
fetch属性 BODY
や BODYSTRUCTURE
の生成の際に引数の値の継続を復号するべきです
>>21。
[142] 引数の拡張構文は RFC 2184 で規定され、後に改訂されて RFC 2231 となりました。
[26] なお RFC 2231 は、実際に必要性がない場合には軽々しく使うべきではないともしています >>21。
Long MIME media type or disposition parameter values do not interact well with header line wrapping conventions. In particular, proper header line wrapping depends on there being places where linear whitespace (LWSP) is allowed, which may or may not be present in a parameter value, and even if present may not be recognizable as such since specific knowledge of parameter value syntax may not be available to the agent doing the line wrapping. The result is that long parameter values may end up getting truncated or otherwise damaged by incorrect line wrapping implementations.
A mechanism is therefore needed to break up parameter values into smaller units that are amenable to line wrapping. Any such mechanism MUST be compatible with existing MIME processors. This means that
(1) the mechanism MUST NOT change the syntax of MIME media type and disposition lines, and
(1) 方法は MIME 媒体型及び意向行の構文を変えてはならない。
(2) the mechanism MUST NOT depend on parameter ordering since MIME states that parameters are not order sensitive. Note that while MIME does prohibit modification of MIME headers during transport, it is still possible that parameters will be reordered when user agent level processing is done.
(2) 方法は parameter 順に依存してはならない。 MIME はパラメーターの順は関係しないとしている。 なお、 MIME は転送中の MIME 頭の編集は禁止しているので、 利用者代理者段階の処理が行われた時にパラメーターの順序を 変えることは可能ではある。
The obvious solution, then, is to use multiple parameters to contain a single parameter value and to use some kind of distinguished name to indicate when this is being done. And this obvious solution is exactly what is specified here: The asterisk character ("*") followed by a decimal count is employed to indicate that multiple parameters are being used to encapsulate a single parameter value. The count starts at 0 and increments by 1 for each subsequent section of the parameter value. Decimal values are used and neither leading zeroes nor gaps in the sequence are allowed.
The original parameter value is recovered by concatenating the various sections of the parameter, in order. For example, the content-type field
元のパラメーター値はパラメーターの各節を順につなぐことで復元されます。 例えば次の content-type 領域
Content-Type: message/external-body; access-type=URL; URL*0="ftp://"; URL*1="cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"
is semantically identical to
は意味的には次のものと同じです。
Content-Type: message/external-body; access-type=URL; URL="ftp://cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"
Note that quotes around parameter values are part of the value syntax; they are NOT part of the value itself. Furthermore, it is explicitly permitted to have a mixture of quoted and unquoted continuation fields.
なお、 parameter value の周りの引用符は value 構文の一部ではありません。 これは value の一部ではないのです。なお、引用符で囲まれている継続領域 と囲まれていない継続領域が混じっていることは明確に認められます。
Some parameter values may need to be qualified with character set or language information. It is clear that a distinguished parameter name is needed to identify when this information is present along with a specific syntax for the information in the value itself. In addition, a lightweight encoding mechanism is needed to accommodate 8 bit information in parameter values.
Asterisks ("*") are reused to provide the indicator that language and character set information is present and encoding is being used. A single quote ("'") is used to delimit the character set and language information at the beginning of the parameter value. Percent signs ("%") are used as the encoding flag, which agrees with RFC 2047.
Specifically, an asterisk at the end of a parameter name acts as an indicator that character set and language information may appear at the beginning of the parameter value. A single quote is used to separate the character set, language, and actual value information in the parameter value string, and an percent sign is used to flag octets encoded in hexadecimal. For example:
Content-Type: application/x-stuff; title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A
Note that it is perfectly permissible to leave either the character set or language field blank. Note also that the single quote delimiters MUST be present even when one of the field values is omitted. This is done when either character set, language, or both are not relevant to the parameter value at hand. This MUST NOT be done in order to indicate a default character set or language -- parameter field definitions MUST NOT assign a default character set or language.
Character set and language information may be combined with the parameter continuation mechanism. For example:
文字集合及び言語情報はパラメーター継続機構と併用できます。例:
Content-Type: application/x-stuff title*0*=us-ascii'en'This%20is%20even%20more%20 title*1*=%2A%2A%2Afun%2A%2A%2A%20 title*2="isn't it!"
訳注: 各パラメータの後に「;」が必要ですが、この例では抜けています。 RFC errata http://www.rfc-editor.org/errata.html 参照。
Note that:
註:
(1) Language and character set information only appear at the beginning of a given parameter value.
(1) 言語及び文字集合情報はパラメーター値の始めにのみ出現できます。
(2) Continuations do not provide a facility for using more than one character set or language in the same parameter value.
(2) 継続は同じパラメーター値で複数の文字集合や言語を使うのには 使用できません。
(3) A value presented using multiple continuations may contain a mixture of encoded and unencoded segments.
(3) 複数の継続を使って表現されている値は 符号化されている部分と符号化されていない部分が混じっていても構いません。
(4) The first segment of a continuation MUST be encoded if language and character set information are given.
(4) 言語及び文字集合情報がある場合、継続の最初の部分は 符号化されていなければなりません。
(5) If the first segment of a continued parameter value is encoded the language and character set field delimiters MUST be present even when the fields are left blank.
(5) 継続パラメーター値の最初の部分が符号化されている場合、 言語及び文字集合領域区切りは領域が空であってもなければなりません。
IMAP4 [RFC-2060] servers SHOULD decode parameter value continuations when generating the BODY and BODYSTRUCTURE fetch attributes.
The ABNF for MIME parameter values given in RFC 2045 is:
RFC 2045 で MIME パラメーター値の ABNF は
parameter := attribute "=" value
attribute := token ; Matching of attributes ; is ALWAYS case-insensitive.
This specification changes this ABNF to:
でした。この仕様書はこの ABNF を次のように変更します。
parameter := regular-parameter / extended-parameter
regular-parameter := regular-parameter-name "=" value
regular-parameter-name := attribute [section]
attribute := 1*attribute-char
attribute-char := <any (US-ASCII) CHAR except SPACE, CTLs, "*", "'", "%", or tspecials>
section := initial-section / other-sections
initial-section := "*0"
other-sections := "*" ("1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9") *DIGIT)
extended-parameter := (extended-initial-name "=" extended-value) / (extended-other-names "=" extended-other-values)
; 編註: extened-value は extended-initial-value の誤り?
extended-initial-name := attribute [initial-section] "*"
extended-other-names := attribute other-sections "*"
extended-initial-value := [charset] "'" [language] "'" extended-other-values
extended-other-values := *(ext-octet / attribute-char)
ext-octet := "%" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
charset := <registered character set name>
language := <registered language tag [RFC-1766]>
(以下略)
encoded-word
の拡張#✎[16] RFC 2231 は encoded-word
に言語を指定できるようにする拡張も規定しています。
encoded-word
を参照。[86] RFC 2231 は将来文字コードレベルで言語の指定ができるようになるので、 その場合はより柔軟に指定できるそちらの方法を MIME レベルの指定の方法よりも利用するべき >>21 としていましたが、そのような方法は後に取り下げられています。
Language-Tag = Primary-tag *( "-" Subtag ) Primary-tag = 1*8ALPHA Subtag = 1*8ALPHA
Whitespace is not allowed within the tag.
大文字・小文字を区別しません。
mime-charset = 1*mime-charset-chars mime-charset-chars = ALPHA / DIGIT / "!" / "#" / "$" / "%" / "&" / "'" / "+" / "-" / "^" / "_" / "`" / "{" / "}" / "~" ALPHA = "A".."Z" ; Case insensitive ASCII Letter DIGIT = "0".."9" ; Numeric digit
区切子「'」とか、問題ありまくりじゃなかろうか? (実際には、 [!#$%&'^`{}~] を使った charset 名は登録されていない。 但し「$」については非標準名で使用例あり。)
[1] あまり実装されていません。
[5] MIME-like な仕組みを採用している HTTP 及び派生プロトコルで RFC2231 の方法が使えるのかは定かではありませんが、 RFC 2231 もそれより後に出た RFC2616 (HTTP/1.1) も触れていないところをみると使わないのかもしれません。 HTTP では quoted-string の中に encoded-word が使えるとか、 RTSP や SIP では UTF-8 が使えるとかもあるし。
[3] parameter の value に認められない文字を含める時、 (特に quoted-string 内に) encoded-word を使う実装があります。
RFC 1867 は Content-Disposition の name パラメーター値 についてこれを認めています。
RFC 2017 urn:ietf:rfc:2017 は長い URL について、 RFC 2231 の方法を使わず、 URL 間に FWS を挟むことを認めています。 (順序的にこっちが元祖だ:-) MHTML (RFC2110) の Content-Base:領域, Content-Location:領域もこれに倣っています。
Link:領域では、 「SGML 実体参照」というのが使えると HTML4 は主張しています。
[4] RFC2388 (multipart/form-data媒体型) は Content-Disposition:欄の name
パラメーターで encoded-word の使用を認めています。
[2] Mozilla 1.2.1 では既定では >>3 の方法を使います。設定 (まだ UI では実装されていないらしい。) により RFC 2231 の方法を使えますが、
Content-Type: application/excel; name*=ISO-8859-1'en-us, en, fr, ru, ja'membership.xls
のような値を生成してしまう問題があります。 (ietf-822, news://news.gmane.org/3DFA24AE.7060604@alex.blilly.com)
[6] Mozilla Japan ナレッジベース - 受取人のメールクライアントによって、添付ファイル名が正しく表示されない場合がある (Thundirbird 1.5) http://www.mozilla-japan.org/kb/solution/3067
これに加えて値の方に生の /
を含めてしまうとか mew-dist 26833、
分割した最後の引数の番号の後にまで *
をつけてしまうとか mew-dist 26847
ずいぶんと杜撰な実装のようでございます。
(名無しさん 2006-04-04 05:37:17 +00:00)
[7] >>2の問題はThunderbird 1.5で修正、>>6のうちKB3067の問題はThunderbird 1.5.0.2で修正されました。生の / を含めてしまう問題はThunderbird 1.5.0.5で修正される予定です。ご迷惑をおかけして申し訳ありません。 番号の後に * を付けるのは不要(冗長)なだけで違反はしていません。また最後の引数の番号だから不要なのではなくて、([mew-dist 26847]の例では)ASCII文字しか含んでいないから不要なのです。 (名無しさん 2006-06-13 07:17:00 +00:00)
[44] 193439 – RFC 2231 style encoding should be used for filename parameter of attachment (instead of RFC 2047 style) ( ( 版)) https://bugzilla.mozilla.org/show_bug.cgi?id=193439
[14] charset / Content-Type BNF flaw in RFC2616 (Andreas Maier 著, 版) http://lists.w3.org/Archives/Public/ietf-http-wg/2007AprJun/0065.html (名無しさん 2007-06-11 11:22:27 +00:00)
[17] HTTP における MIME 由来のヘッダーに RFC 2231 が適用されるのか否かは長らく不明瞭なままでした。00年代までは HTTP では RFC 2231 の拡張はほとんど実装されていませんでしたが、 非ASCII文字を表現する方法として唯一標準化されていたのが RFC 2231 だったこともあり、 RFC 2231 を実装するのが正しいと主張する人達もいました。
2008-10-10 20:52:00 +09:00
版) http://greenbytes.de/tech/webdav/draft-reschke-rfc2231-in-http-latest.html[19] 2010年になってようやく RFC 5987 が出版され、 RFC 2231 の拡張の HTTP への適用方法が明らかにされました。
[132] draft-reschke-rfc5987bis-07 - Indicating Character Encoding and Language for HTTP Header Field Parameters ( ( 版)) https://tools.ietf.org/html/draft-reschke-rfc5987bis-07
[143] RFC 5536 - Netnews Article Format ( ( 版)) http://tools.ietf.org/html/rfc5536#section-3.2.8
[144] メールの符号化は悪だ - あどけない話 ( ( 版)) http://d.hatena.ne.jp/kazu-yamamoto/20071226/1198656209
[145] RFC 7444 - Security Labels in Internet Email ( 版) https://tools.ietf.org/html/rfc7444
RFC 5987 が各最新ブラウザで問題なくファイル名指定ダウンロードができることが分かりました。エンコード方法によっては400エラーになってしまったり、ファイル名が正しく指定できなかったりとサポートしていないことが分かります。
[154] ABNF for metric-value · Issue #12 · w3c/server-timing () https://github.com/w3c/server-timing/issues/12
[155] Review request for Server-Timing · Issue #188 · w3ctag/design-reviews () https://github.com/w3ctag/design-reviews/issues/188
multipart/form-data
は MIME とも HTTP とも一部異なる構文や処理方法が採られていますので、本項では区別しています。