407.txt

[27] 名前と値を [CODE(HTTP)[=]] で連ねた構文は[DFN[[RUBY[引数][ひきすう]@en[parameter]]]]と呼ばれています。

[63] [[MIME]] のほか、派生した[[電子メール]]、[[ネットニュース]]、[[HTTP]]、
[[RTSP]]、[[SIP]]、[[MSRP]]、[[CoAP]]、 [CODE(MIME)@en[[[multipart/form-data]]]]
といった様々な[[プロトコル]]で採用されている構文です。

;; [CODE(MIME)@en[[[multipart/form-data]]]] は [[MIME]] とも [[HTTP]]
とも一部異なる構文や処理方法が採られていますので、本項では区別しています。

* 仕様書

[REFS[
- [28] [CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-08-07 05:54:02 +09:00]] 版) <https://tools.ietf.org/html/rfc7231#page-79>
- [21] [CITE@en[RFC 2231 - MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations]] ([TIME[2014-09-14 04:20:18 +09:00]] 版) <http://tools.ietf.org/html/rfc2231>
- [58] [CITE[RFC Errata Report]] ([TIME[2014-10-28 06:55:45 +09:00]] 版) <http://www.rfc-editor.org/errata_search.php?rfc=2231>
- [15] [CITE@en[RFC 5987 - Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters]] ([TIME[2014-08-10 01:17:43 +09:00]] 版) <http://tools.ietf.org/html/rfc5987>
- [134] [CITE@en[RFC 2183 - Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field]] ([TIME[2014-09-07 04:20:15 +09:00]] 版) <http://tools.ietf.org/html/rfc2183#section-2>
- [129] [CITE@en[RFC 5988 - Web Linking]] ([TIME[2014-09-11 12:14:02 +09:00]] 版) <http://tools.ietf.org/html/rfc5988#section-5.4>
- [139] [CITE@en[RFC 6266 - Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)]] ([TIME[2014-10-13 05:17:21 +09:00]] 版) <http://tools.ietf.org/html/rfc6266#section-4.1>
- [141] [CITE@en[RFC 6266 - Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)]] ([TIME[2014-10-13 05:17:21 +09:00]] 版) <http://tools.ietf.org/html/rfc6266#section-4.3>
]REFS]

* 構文

[61] [[引数]]は、名前、[CODE[=]]、値で構成されます。ただし、以降で述べる通り、
その細部は利用される場面によって様々に異なっています。

[FIG(railroad)[
= 名前
= ?
== [CODE(HTTP)[[[=]]]]
== 値
]FIG]

[62] ほとんどの場面で[[引数]]は [CODE(HTTP)[[[;]]]] 区切りの零個以上のリストとして使われています。

[FIG(railroad)[
= ?
== [[引数]]
== *
=== [CODE(HTTP)[[[;]]]]
=== [[引数]]
]FIG]

* MIME における構文

[66] [[MIME]] の[[引数]]は、[[属性]]、区間、[CODE(MIME)[[[*]]]]、
[CODE(MIME)[[[=]]]]、値により構成されます。
ただし区間と [CODE[[[*]]]] はそれぞれ継続と拡張を表しており、
該当しない場合には省略されます。 [SRC[>>21]]

[FIG(railroad)[
= [[属性]]
= ?
== 区間
= ?
== [CODE[[[*]]]]
= [CODE(MIME)[[[=]]]]
= 値
]FIG]

;; [78] [[電子メール]]では [CODE(MIME)@en[[[=]]]] の前後に[[空白]] ([[RFC 822]] では
[CODE(ABNF)@en[[[linear-white-space]]]] および [CODE(ABNF)@en[[[comment]]]]、
[[RFC 2822]] や [[RFC 5322]] では [CODE(ABNF)@en[[[CFWS]]]]) を挿入できると一般的には解釈されるようですが、
なんと [[MIME]] 関連 [[RFC]] では明文化されていません。また[[ネットニュース]]では
[CODE(ABNF)@en[[[FWS]]]] が挿入できると解釈するべきか、あるいは認められないと解釈するべきか、
明確ではありません。[[電子メール]]以外の[[プロトコル]]で [[MIME]]
を採用している場合や、 [[MIME]] を参照している場合にどう解釈するべきなのかも不明瞭です。

[68] [DFN[[RUBYB[[[属性]]]@en[attribute]]]]は、1つ以上の[RUBYB[属性に使える文字]@en[attribute-char]]の列です [SRC[>>21]]。
[[属性]]は一般には[[引数]]の名前とみなされています。[[属性]]は[[大文字・小文字不区別]]です。

[FIG(railroad)[
= +
== [[属性]]に使える[[文字]]
]FIG]

;; [69] [[RFC 2045]] 時代は[[字句]]とされていましたが、 [[RFC 2231]]
の拡張により [CODE[*]]、[CODE[']]、[CODE[%]] が除外されています [SRC[>>21]]。

[70] [RUBYB[区間]@en[section]]は [CODE[*]] の後に[[ASCII数字]]を連ねたものです。ただし[[先導0]]は認められていません。
[SRC[>>21]]

[FIG(railroad)[
= [CODE(MIME)[[[*]]]]
= |
== [CODE[[[0]]]]
== =
=== [CODE[[[1]]]] ... [CODE[[[9]]]]
=== *
==== [[ASCII数字]]
]FIG]

[67] 値は、[[字句]]、[[引用文字列]]、拡張された最初の値、拡張されたその他の値の4つの指定方法があります。 [SRC[>>21]]

[FIG(railroad)[
= |
== [[字句]]
== [[引用文字列]]
== 拡張された最初の値
== 拡張されたその他の値
]FIG]

[71] 拡張された最初の値は、[[charset]]、[[言語タグ]]、拡張されたその他の値相当の値を
[CODE[[[']]]] で区切ったものです。ただし [[charset]] と[[言語タグ]]は省略できます。 [SRC[>>21]]

[FIG(railroad)[
= ?
== [[charset]]
= [CODE(char)[[[']]]]
= ?
== [[言語タグ]]
= [CODE(char)[[[']]]]
= >>72 の値
]FIG]

[72] 拡張されたその他の値は、[RUBYB[[[属性]]に使える文字]@en[attribute-char]]か[[パーセント符号化]]された[[オクテット]]の0個以上の列です。 [SRC[>>21]]

[FIG(railroad)[
= *
== |
=== [[属性]]に使える[[文字]]
=== =
==== [CODE(char)[[[%]]]]
==== [[ASCII十六進数字]]
==== [[ASCII十六進数字]]
]FIG]

;; [73] [[十六進数字]]は[[大文字・小文字不区別]]です。

;; [74] [[パーセント符号化]]は [[URL]] で使われているものと同じものですが、
両者の定義は個々になされています。また [[MIME]] では「[[パーセント符号化]]」
という用語は使っていません。

[77] 区間、継続を表す [CODE[*]]、値の各構文の組み合わせには、後述の通り制約があります。

[135] [[RFC 2183]] は [[MIME]] [CODE(MIME)@en[[[Content-Disposition:]]]] 
[[ヘッダー]]における値の構文の選択について、次のように述べています [SRC[>>134]]。
[FIG(list)[
- [136] 78文字[[以下]]で [CODE(ABNF)@en[[[tspecials]]]] 以外の[[ASCII文字]]のみなら、
[[字句]]とする[['''べき''']]
- [137] 78文字[[以下]]で [[ASCII文字]]のみで [CODE(ABNF)@en[[[tspecials]]]]
を含むなら、[[引用文字列]]とする[['''べき''']]
- [138] それ以外なら拡張構文を使わなければ[['''ならない''']]
]FIG]

[92] [[引数]]のリストにおける区切り文字 [CODE(MIME)[[[;]]]] の前後には[[空白]]
([[RFC 822]] では [CODE(ABNF)@en[[[linear-white-space]] / [[comment]]]]、
[[RFC 2822]] や [[RFC 5322]] では [CODE(ABNF)@en[[[CFWS]]]]) が挿入できると解釈されています
(が [[RFC]] には明記されていません)。
[CODE(MIME)@en[[[;]]]] の前には何も挿入せず、後には [CODE(charname)@en[[[SPACE]]]]
を1つ挿入するのが一般的です。

;; [93] [[電子メール]]以外の[[プロトコル]]でも同様に解釈するのが一般的ですが、
[[注釈]]まで認められてはいないと理解されているのが普通のようです。

* HTTP における構文

[29] いわゆる[[引数]]構文は、それぞれで異なる定義になっています。
その多くは構文の一部を共有していますが、それぞれ個別の要件が課されていることがあります。

;; [90] 具体的な構文は、それぞれの項を参照。

;; [91] [[MIME]] から派生した[[ヘッダー]]であっても、 [[HTTP]] では [[HTTP]]
独自の構文を規定しています。

[30] [[RFC 7231]] は新しい[[HTTPヘッダー]]についてできるだけ構文解析器を流用できるように共通の構文を採用することを求めています
[SRC[>>28]]。

;; [31] しかし [[RFC 723x]] の[[引数]]系構文はそれぞれで構文が少しずつ異なっているのですが...
同時に追加されたはずの [CODE(HTTP)@en[[[Forwarded:]]]] と
[CODE(HTTP)@en[[[Prefer:]]]] すら別々の構文を規定していますし...

[60] 多くの場面では[[引数]]同士の区切りは [CODE(HTTP)[[[;]]]] ですが、
いくつか例外的に [CODE(HTTP)[[[,]]]] となっている ([[リスト]] ([CODE(HTTP)[#]]) になっている)
ことがあります。

[35] 多くの場面では [CODE(HTTP)[[[;]]]] の前後に [CODE(ABNF)@en[[[OWS]]]]
が含まれていますが、そうでない場面もあります。

[36] いくつかの場面では [CODE(HTTP)[[[;]]]] の連続 (名前と値の組のかわりに[[空文字列]])
が認められています。

;; [37] 類似した構文である[[リスト]] ([CODE(HTTP)[#]]) では [CODE(HTTP)[[[,]]]]
の連続は認められていませんが、[[受信者]]は対応することが求められています。
[[引数]]に関してはなぜかそのような規定はなく、文脈ごとに構文が違っています。

[32] 値について[[字句]]と[[引用文字列]]の両方を認め、
その両者で意味を同じとすることをすすめています [SRC[>>28]]。

[33] いくつかの場面では [CODE(HTTP)[[[=]]]] と値を省略できますが、
そうでない場面も多々あります。値の省略は[[空文字列]]の指定と同一視される場面もありますが、
そうでない場面もあります。

[34] いくつかの場面では [CODE(HTTP)[[[=]]]] の前後に [CODE(ABNF)@en[[[BWS]]]]
が含まれていますが、そうでない場面もあります。

[38] 値は[[字句]]と[[引用文字列]]の両方の構文が認められ、どちらも同じ意味とするのが普通ですが、
その解釈が明記されていないことや、どちらか一方に限定されていること、
定義上一方に限定されているように書かれているものの行間や実態からどちらでも良いと解釈するべきこともあります。

[39] 名前は[[ASCII大文字・小文字不区別]]で、値は区別されるのが普通ですが、
明記されていないこともあります。

[40] 多くの場面では同名の[[引数]]が複数ある場合の処置を明記していません。

[41] 多くの場合は[[引数]]の順序に意味があるか明記していませんが、
意味は無いのが普通です。

** RFC 5987 による構文

[95] [[RFC 5987]] [SRC[>>15]] は、 [[MIME]] における [[RFC 2231]] の構文を [[HTTP]]
に当てはめたものを定義しています。

[99] [[引数]]は、名前、拡張を表す [CODE(HTTP)[*]]、[CODE(HTTP)[[[=]]]]、
値で構成されます。ただし拡張構文を使わない場合は、 [CODE(HTTP)[*]]
を省略します。 [SRC[>>15]]

[FIG(railroad)[
= 引数名
= ?
== [CODE(HTTP)[[[*]]]]
= [CODE(HTTP)[[[=]]]]
= 値
]FIG]

[100] [CODE(HTTP)[[[=]]]] の前後には [CODE(ABNF)@en[[[LWSP]]]] を挿入できます [SRC[>>15, >>139]]。
ただその後出版された [[RFC 723x]] との整合性を考慮すると、これは 
[CODE(ABNF)@en[[[BWS]]]] と解釈するべきでしょう。

[101] 引数名は、1文字以上の[RUBYB[属性の文字]@en[attr-char]]の列です。
これは[[字句]]に使える文字から [CODE(HTTP)[*]], [CODE(HTTP)[']], [CODE(HTTP)[%]]
を除外したものです。 [SRC[>>15]]

[FIG(railroad)[
= +
== 属性の文字
]FIG]

;; [102] これは [[MIME]] における定義 (>>68) と同趣旨ではありますが、
元々の[[字句]]で使える[[文字]]が違っています。

[103] 値は、[[字句]]、[[引用文字列]]、拡張された値のいずれかです [SRC[>>15]]。
ただし名前の後に [CODE(HTTP)[*]] を指定した場合は拡張された値を、
指定しなかった場合はそれ以外を使う必要があります [SRC[>>15]]。

[FIG(railroad)[
= |
== [[字句]]
== [[引用文字列]]
== 拡張された値
]FIG]

[104] 拡張された値は、 [[charset]]、[[言語タグ]]、本来の値を [CODE(HTTP)[[[']]]]
で連結したものです [SRC[>>15]]。

[FIG(railroad)[
= [[charset]]
= [CODE(HTTP)[[[']]]]
= ?
== [[言語タグ]]
= [CODE(HTTP)[[[']]]]
= >>105
]FIG]

;; [75] これは [[MIME]] における拡張された最初の値に相当します。

;; [76] [[MIME]] と違って [[charset]] は必須となっています。

[105] 本来の値は0個以上の[RUBYB[属性の文字]@en[attr-char]]か[[パーセント符号化]]された[[オクテット]]の列です [SRC[>>15]]。

[FIG(railroad)[
= *
== |
=== 属性の文字
=== =
==== [CODE(HTTP)[[[%]]]]
==== [[ASCII十六進数字]]
==== [[ASCII十六進数字]]
]FIG]

;; [116] [[HTTP]] では [[RFC 3986]] の[[パーセント符号化]]の規定が参照されています。

;; [106] 拡張された値の解釈については、以後の章を参照。

* 引数値拡張

[20] [[RFC 2231]] は [[MIME]] の[[引数]]の拡張として、次の仕組みを追加しています
[SRC[>>21]]。
[FIG(list)[
- [22] [[引数]]の値の [[charset]] の指定
- [23] [[引数]]の値の[[言語タグ]]の指定
- [24] 長い[[引数]]の値を分割した指定 (引数値の継続)
- [59] [[引数]]の値の[[パーセント符号化]]
]FIG]

[25] [[RFC 5987]] は [[HTTP]] の[[引数]]の拡張として >>22 と >>23 と >>59 を採用しています
[SRC[>>21]]。 >>24 は[[電子メール]]に由来する [[MIME]] の行長制限に対処するためなので、
[[HTTP]] では不要 [SRC[>>15]] とされています。

[87] [[RFC 2231]] は [[MIME]] ([[RFC 2045]]) の[[引数]]の定義を[[更新]]しており、
同定義を参照するすべての[[ヘッダー]]のすべての[[引数]]に適用することを意図しているようにみえます。

[98] 実際に該当するのは、次の[[MIMEヘッダー]]です。
[FIG(short list)[
- [CODE(MIME)@en[[[Content-Type:]]]]
- [CODE(MIME)@en[[[Content-Disposition:]]]]
]FIG]

[88] [[RFC 2231]] に対する[[正誤表]]の報告 (>>58) は、 [CODE(MIME)@en[[[charset]]]] や
[CODE(MIME)@en[[[boundary]]]] のような主要な[[引数]]に適用すると旧来の
[[MIME]] の実装との互換性が失われてしまうと指摘しています。同報告はそのような[[引数]]で
[[RFC 2231]] の拡張を適用している実装が既に存在しているとも指摘しています。

[125] [[HTTP]] においては拡張構文はすべての[[引数]]に適用されるわけではなく、
[[RFC 5987]] は適用される場合仕様書で明示する[RUBYB[べき]@en[ought to]]
[SRC[>>15]] としています。適用されるかどうかは、[[ヘッダー]]と[[引数]]ごとに決まります。

[126] [[RFC 5987]] は、[[人間可読]]な[[テキスト]]を含む[[引数]]や[[非ASCII文字]]を含む[[引数]]では拡張構文を採用する[RUBYB[べき]@en[ought to]]
[SRC[>>15]] としています。

[96] [[HTTP]] における拡張構文は次の場面で採用されています。
[FIG(list)[
- [CODE(HTTP)@en[[[Content-Disposition:]]]]
- [CODE(HTTP)@en[[[Link:]]]] [[ヘッダー]] [CODE(HTTP)@en[[[title]]]] [[引数]]
]FIG]

;; [97] [[MIME]] と違って [CODE(HTTP)@en[[[Content-Type:]]]] では採用されていません。

[133] [[HTTP]] [CODE(HTTP)@en[[[Link:]]]] [[ヘッダー]]の派生形式である
[[CoRE]] も [CODE(HTTP)@en[[[title]]]] [[引数]]で拡張構文を採用しています。

[94] [[MIME]] や [[HTTP]] 以外でそれらの定義を参照する[[プロトコル]]等にこれらの拡張が適用されるのかどうかは不明確です。
多くの場合はこれらの拡張は考慮されていません。

** 引数値の継続

[45] [[MIME]] では、[[引数]]の名前の後に [CODE[*]] と数値を続けることで、
[[引数]]の値を複数の[[引数]]に分割できます。

[EG[
[46] 例えば、
[PRE(MIME code)[
Content-Type: message/external-body; access-type=URL;
 URL*0="ftp://";
 URL*1="cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"
]PRE]
... は
[PRE(MIME code)[
Content-Type: message/external-body; access-type=URL;
 URL="ftp://cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"
]PRE]
... と等価です [SRC[>>21]]。
]EG]

;; [47] [[MIME]] では[[引数]]の順序は意味を持たないこと、既存の [[MIME]]
の構文を変更しないこと、という制約のため、このような構文が採用されました [SRC[>>21]]。
なおこの拡張のため、[[引数]]の名前に [CODE[*]] は使えなくなりました。

[80] [[先導0]]は構文上認められていません。

[79] 仕様書の書き方から、 [CODE[*0]] から順に使用しなければならないとみられますが、
明言されていません。受信者も番号が若いものから順に連結していくべきとみられますが、
番号が飛んでいる場合にどうするべきなのか不明です。また同名・数の[[引数]]が複数存在するときにどう処理するべきなのかは不明です。

[48] [[HTTP]] ではこの構文は使えません。

** 引数値の文字コードと言語、符号化

[49] [[MIME]] と [[HTTP]] では、[[引数]]の名前の後に [CODE[*]]
を続けることで、[[引数]]の値の[[文字コード]]と[[言語タグ]]の一方または両方を指定することができます。

[50] その場合の[[引数]]の値は、[[文字コード]]、[[言語タグ]]、本来の[[引数]]の値を
[CODE[']] で連結したものとします。ただし[[文字コード]]と[[言語タグ]]は省略して[[空文字列]]にできます。また本来の値は[[パーセント符号化]]します。

[EG[
[51] 次の例 [SRC[>>21]]
[PRE(MIME code)[
Content-Type: application/x-stuff;
 title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A
]PRE]
... は、
[PRE(MIME code)[
Content-Type: application/x-stuff;
 title="This is ***fun***"
]PRE]
... と等価ですが、 [[charset]] [CODE(charset)@en[[[us-ascii]]]] と[[言語タグ]]
[CODE(lang)@en[[[en-us]]]] が指定されています。
]EG]

;; [52] [[引数]]の定義は、[[引数]]固有の[[文字コード]]や[[言語タグ]]の[[既定値]]を規定しては[['''なりません''']] [SRC[>>21]]。
[[空文字列]]は[[引数]]依存の既定値を意味するのではなく、[[プロトコル]]共通の[[既定値]]を意味しているようです。
ただしそれが何であるのか [[RFC 2231]] には明記されていません。 [[MIME]]
の他の部分との整合性を考慮すると、それぞれ [CODE(charset)@en[[[US-ASCII]]]]
と [CODE(lang)@en[[[i-default]]]] と解釈するべきでしょうか。

[81] 指定方法が構文上正しくない (例えば [CODE[']] が0個または1個しか含まれない)
場合にどう処理するべきなのかは不明です。

** 引数値の継続と符号化の組み合わせ

[53] [[MIME]] では、長い[[引数]]の継続構文と[[文字コード]]や[[言語タグ]]を指定した[[符号化]]構文を組み合わせて使うことができます。

[55] 一組の[[引数]]を構成する分割された[[引数]]のそれぞれで、
旧来の[[字句]]または[[引用文字列]]の構文と拡張された[[パーセント符号化]]の構文を混用できます。
[[パーセント符号化]]構文の場合は、[[引数]]の名前の分割番号の後に [CODE[*]] が付きます。 
[SRC[>>21]]

[54] [[文字コード]]や[[言語タグ]]の指定がある場合は、
最初 (0番) の[[引数]]に含めなければなりません。
その場合最初の[[引数]]は[[字句]]や[[引用文字列]]の構文にはできません。 [SRC[>>21]]

[82] また最初の[[引数]]以外で[[文字コード]]や[[言語タグ]]を指定することはできません。
一組の[[引数]]を構成する値のそれぞれで別の[[文字コード]]や[[言語タグ]]を混在させることはできません [SRC[>>21]]。
最初の[[引数]]以外で [CODE[']] を使うことは構文上認められていません。
もし含まれていた場合にどう処理するべきなのかは不明です。

[EG[
[56] 例えば次のように表せます [SRC[>>21, >>58]]。

[PRE(MIME code)[
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!"
]PRE]
]EG]

[84] [[多バイト文字コード]]における[[文字]]の途中の[[バイト]]で[[引数]]を分割して良いのか悪いのか、
状態を持つ[[文字コード]]で[[引数]]ごとに完結しない形で分割して良いのか悪いのか、
[[RFC]] には明記されていません。また拡張された構文と旧来の[[字句]]や[[引用文字列]]の構文が混在する場合に、
後者は常に [[ASCII]] として解釈するべきなのか、それとも [[ASCII]]
に相当する[[バイト列]]として解釈するべきなのかは不明です。

[EG[
[85] 例えば、 [CODE(char)[[[U+3000]]]] のあとに [CODE(file)[.txt]] と続く[[ファイル名]]を
[PRE(MIME code)[
Content-Disposition: attachment;
  filename*0*=shift_jis'ja'%81;
  filename*1="@.txt"
]PRE]
... と表現して良いのでしょうか。
]EG]

[57] [[HTTP]] では継続構文が認められていないので、このような構文も使えません。

** 重複の処理

[89] 拡張された[[引数]]と旧来の構文の[[引数]]で同名のものが重複して存在する時、
また継続構文を採用したものと符号化構文を採用したものとで重複して存在する時、
どのように処理するべきかは [[MIME]] 仕様上言及がありません。

[127] [[HTTP]] の仕様である [[RFC 5987]] では、拡張された構文とそうでないもので重複している場合
(例えば [CODE[title=...]] と [CODE[title*=...]] が両方指定されている場合)
の処理の規定は拡張構文を採用する[[ヘッダー]]の仕様書の責任としています [SRC[>>15]]。

[128] [[RFC 5987]] としては拡張構文を優先させることを[RUBYB[提案]@en[suggest]]しており、
未対応の実装に向けた旧来の構文の [[ASCII]] 版と拡張構文の版の両方を指定させられると述べています
[SRC[>>15]]。ただし既存の実装は未対応の[[引数]]を無視しなかったり、
旧来の構文を優先させたりする [SRC[>>15]] と当の [[RFC 5987]]
自身が述べており、実際に両方を指定してもどれだけ意味があるのかは疑問です。

[130] [CODE(HTTP)@en[[[Link:]]]] [[ヘッダー]]の [CODE(HTTP)@en[[[title]]]]
[[引数]]はこれに従い、 [CODE(HTTP)@en[[[title*]]]] を優先する[['''べき''']]だ
[SRC[>>129]] としています。

[140] [CODE(HTTP)@en[[[Content-Disposition:]]]] [[ヘッダー]]の [CODE(HTTP)@en[[[filename]]]]
[[引数]]でも、 [CODE(HTTP)@en[[[filename*]]]] を優先する[['''べき''']]だ
[SRC[>>141]] とされています。

* charset

[110] [[RFC 2231]] / [[RFC 5987]] で拡張された構文では、値の [[charset]]
を指定できます。

[75] [[MIME]] では、 [[charset]] は登録された [[IANA charset]] 名とされています [SRC[>>21]]。

;; [107] 具体的な構文は明記されていません。

[112] [[HTTP]] では [CODE(charset)@en[[[UTF-8]]]] または [CODE(charset)@en[[[ISO-8859-1]]]]
([[大文字・小文字不区別]]) とされています [SRC[>>15]]。
このいずれかを[[生成]]しなければ[['''なりません''']] [SRC[>>15]]。

[113] ただし構文上はそれに加えて [CODE(ABNF)@en[[[mime-charset]]]] も認められています。
これは1文字以上の [[ASCIIラテン文字]]、[[ASCII数字]]、
[CODE(char)[[[!]]]], [CODE(char)[#]], [CODE(char)[[[$]]]], [CODE(char)[[[%]]]],
[CODE(char)[[[&]]]], [CODE(char)[[[+]]]], [CODE(char)[[[-]]]], [CODE(char)[[[^]]]],
[CODE(char)[[[_]]]], [CODE(char)[[[`]]]], [CODE(char)[[[{]]]], [CODE(char)[[[}]]]],
[CODE(char)[[[~]]]] の列とされています。これは [[IANA charset]]
として登録されたものとする[['''べきです''']]。
こちらは将来の利用のために[[予約]]されています。 [SRC[>>15]]

;; [114] [[RFC 2978]] の定義から [CODE(char)[[[']]]] を除外したものです [SRC[>>15]]。

;; [119] これらの [[charset]] を受信した時にどうするべきなのかは明記されていません。

[117] [[MIME]] では [[charset]] を省略して[[空文字列]]にできますが、
[[HTTP]] では必ず指定しなければなりません。

[83] 指定された[[文字コード]]により値を[[復号]]できない場合にどう処理するべきなのかは不明です。
[[MIME]] ではまったく言及されていませんが、 [[HTTP]] では次のような記述があります。

[120] 受信者は、不正や不完全な[[パーセント符号化]]や[[復号]]できない[[オクテット列]]などの[[符号化]]の誤りに対して[[頑健]]である[RUBYB[べき]@en[should]]です
[SRC[>>15]]。具体的な方法は定めませんが、例えば次のような方法を採ることができます
[SRC[>>15]]。

[FIG(list)[
- [121] [[引数]]を無視する
- [122] [[復号]]できない[[オクテット列]]を除去する
- [123] [[復号]]できない[[オクテット列]]を [CODE(char)[[[U+FFFD]]]]
などで置換する
]FIG]

;; [124] 不正な列の処理方法が実装により一定していないと[[相互運用性]]の問題が生じそうなものですが・・・。
特に[[復号]]できない[[オクテット列]]を除去するような方法は、
実装ごとに異なった解釈がされてしまうことで[[セキュリティー]]上の問題を生じさせる危険性もあります...

* 言語タグ

[111] [[RFC 2231]] / [[RFC 5987]] で拡張された構文では、値の[[言語タグ]]を指定できます。

[76] [[MIME]] では、[[言語タグ]]は、登録された [[RFC 1766]] [[言語タグ]]とされています [SRC[>>21]]。

;; [109] [[RFC 1766]] を参照しており、 [[MIME]] として独自には構文を規定していません。

[115] [[HTTP]] では、 [[RFC 5646]] [[言語タグ]]とされています [SRC[>>15]]。

;; [108] 現在ではどちらも [[BCP 47]] [[言語タグ]]と解釈するべきでしょう。

[118] [[MIME]] でも [[HTTP]] でも、[[言語タグ]]は省略して[[空文字列]]にできます。

* 引数やそれと同様の構文を採用している箇所

[42] [[HTTP]] では次の箇所で[[引数]]またはそれと同様の構文を採用しています。

[FIG(list short)[
- [[転送符号化]]
- [CODE(HTTP)@en[[[TE:]]]]
- [[MIME型]]
- [[媒体範囲]]
- [CODE(HTTP)@en[[[Accept:]]]] ([CODE(ABNF)@en[[[accept-params]]]])
- [[品質値]]
- [CODE(HTTP)@en[[[chunked]]]]
- 各種[[指令]]
-- [CODE(HTTP)@en[[[Cache-Control:]]]]
-- [CODE(HTTP)@en[[[Pragma:]]]]
-- [CODE(HTTP)@en[[[Strict-Transport-Security:]]]]
-- [CODE(HTTP)@en[[[Negotiate:]]]]
- [CODE(ABNF)@en[[[auth-param]]]]
-- [[challenge]]
-- [[credentials]]
- [CODE(HTTP)@en[[[Authentication-Info:]]]]
- [CODE(HTTP)@en[[[Forwarded:]]]]
- [CODE(HTTP)@en[[[Prefer:]]]]
- [CODE(HTTP)@en[[[Preference-Applied:]]]]
- [CODE(HTTP)@en[[[Set-Cookie:]]]]
- [CODE(HTTP)@en[[[Set-Cookie2:]]]]
- [CODE(HTTP)@en[[[Cookie:]]]]
]FIG]

;; [43] [[HTTP]] 以外では、 [[MIMEヘッダー]]や[[電子メール]]の[[ヘッダー]]の一部、 [[HTML]]
の [CODE(HTML)@en[<[[meta]] [[http-equiv]]>]] の一部で似た
(しかし異なる) 構文を採用しています。また [[URL]] の [[query]] や [[HTML]]
の[[属性]]の指定も似たようにみえる構文を採用していますが、かなりの違いもあります。

* IMAP における処理

[64] [[IMAP4]] [[鯖]]は、 [[MIME]] [[メッセージ]]を処理する場合、
[[fetch属性]] [CODE[[[BODY]]]] や [CODE[[[BODYSTRUCTURE]]]] の生成の際に[[引数]]の値の継続を[[復号]]する[['''べきです''']]
[SRC[>>21]]。

;; [65] [[文字コード]]や[[言語タグ]]をどう扱うべきなのかは不明です。

* 歴史

** MIME における引数の拡張

[142] [[引数]]の拡張構文は [[RFC 2184]] で規定され、後に改訂されて [[RFC 2231]]
となりました。

[26] なお [[RFC 2231]] は、実際に必要性がない場合には軽々しく使う[RUBYB[べきではない]@en[should not]]ともしています [SRC[>>21]]。

[FIG(quote)[
[FIGCAPTION[
[10] RFC 2231 3.  Parameter Value Continuations
]FIGCAPTION]

[PRE[
   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.
]PRE]

[PRE[
   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
]PRE]

(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 頭の編集は禁止しているので、
利用者代理者段階の処理が行われた時にパラメーターの順序を
変えることは可能ではある。

[PRE[
   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.
]PRE]

The original parameter value is recovered by concatenating the
various sections of the parameter, in order.  For example, the
content-type field

元のパラメーター値はパラメーターの各節を順につなぐことで復元されます。
例えば次の content-type 領域

[PRE[
        Content-Type: message/external-body; access-type=URL;
         URL*0="ftp://";
         URL*1="cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"
]PRE]

is semantically identical to

は意味的には次のものと同じです。

[PRE[
        Content-Type: message/external-body; access-type=URL;
          URL="ftp://cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"
]PRE]

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 の一部では''ない''のです。なお、引用符で囲まれている継続領域
と囲まれていない継続領域が混じっていることは明確に認められます。
]FIG]

[FIG(quote)[
[FIGCAPTION[
[11] RFC 2231 4.  Parameter Value Character Set and Language Information
]FIGCAPTION]

[PRE[
   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.
]PRE]

[PRE[
   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.
]PRE]

[PRE[
   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:
]PRE]

[PRE[
        Content-Type: application/x-stuff;
         title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A
]PRE]

[PRE[
   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.
]PRE]

* 4.1.  Combining Character Set, Language, and Parameter Continuations
* 4.1. 文字集合, 言語, パラメーター継続の組合せ

Character set and language information may be combined with the
parameter continuation mechanism. For example:

文字集合及び言語情報はパラメーター継続機構と併用できます。例:

[PRE[
   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!"
]PRE]

訳注: 各パラメータの後に「;」が必要ですが、この例では抜けています。
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) 継続パラメーター値の最初の部分が符号化されている場合、
言語及び文字集合領域区切りは領域が空であっても''なければなりません''。
]FIG]

[FIG(quote)[
[FIGCAPTION[
[12] RFC 2231 6.  IMAP4 Handling of Parameter Values
]FIGCAPTION]

IMAP4 [RFC-2060] servers SHOULD decode parameter value continuations
when generating the BODY and BODYSTRUCTURE fetch attributes.
]FIG]

[FIG(quote)[
[FIGCAPTION[
[13] RFC 2231 7.  Modifications to MIME ABNF
]FIGCAPTION]

The ABNF for MIME parameter values given in RFC 2045 is:

RFC 2045 で MIME パラメーター値の ABNF は

[PRE[
   parameter := attribute "=" value
]PRE]

[PRE[
   attribute := token
                ; Matching of attributes
                ; is ALWAYS case-insensitive.
]PRE]

This specification changes this ABNF to:

でした。この仕様書はこの ABNF を次のように変更します。

[PRE[
   parameter := regular-parameter / extended-parameter
]PRE]

[PRE[
   regular-parameter := regular-parameter-name "=" value
]PRE]

[PRE[
   regular-parameter-name := attribute [section]
]PRE]

[PRE[
   attribute := 1*attribute-char
]PRE]

[PRE[
   attribute-char := <any (US-ASCII) CHAR except SPACE, CTLs,
                     "*", "'", "%", or tspecials>
]PRE]

[PRE[
   section := initial-section / other-sections
]PRE]

[PRE[
   initial-section := "*0"
]PRE]

[PRE[
   other-sections := "*" ("1" / "2" / "3" / "4" / "5" /
                          "6" / "7" / "8" / "9") *DIGIT)
]PRE]

[PRE[
   extended-parameter := (extended-initial-name "="
                          extended-value) /
                         (extended-other-names "="
                          extended-other-values)
]PRE]

; 編註: extened-value は extended-initial-value の誤り?

[PRE[
   extended-initial-name := attribute [initial-section] "*"
]PRE]

[PRE[
   extended-other-names := attribute other-sections "*"
]PRE]

[PRE[
   extended-initial-value := [charset] "'" [language] "'"
                             extended-other-values
]PRE]

[PRE[
   extended-other-values := *(ext-octet / attribute-char)
]PRE]

[PRE[
   ext-octet := "%" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
]PRE]

[PRE[
   charset := <registered character set name>
]PRE]

[PRE[
   language := <registered language tag [RFC-1766]>
]PRE]

(以下略)
]FIG]

*** [CODE(ABNF)@en[encoded-word]] の拡張

[16] [[RFC 2231]] は [CODE(ABNF)@en[[[encoded-word]]]] に[[言語]]を指定できるようにする拡張も規定しています。

;; [CODE(ABNF)@en[[[encoded-word]]]] を参照。

*** 文字コードによる言語指定

[86] [[RFC 2231]] は将来[[文字コード]]レベルで[[言語]]の指定ができるようになるので、
その場合はより柔軟に指定できるそちらの方法を [[MIME]] レベルの指定の方法よりも利用する[['''べき''']] [SRC[>>21]]
としていましたが、そのような方法は後に取り下げられています。

;; [[RFC 2482]] を参照。

*** 他の仕様の BNF 抜粋

**** RFC 1766

[PRE[
    Language-Tag = Primary-tag *( "-" Subtag )
    Primary-tag = 1*8ALPHA
    Subtag = 1*8ALPHA
]PRE]

[PRE[
   Whitespace is not allowed within the tag.
]PRE]

大文字・小文字を区別しません。

*** RFC 2978

[PRE[
     mime-charset = 1*mime-charset-chars
     mime-charset-chars = ALPHA / DIGIT /
                "!" / "#" / "$" / "%" / "&" /
                "'" / "+" / "-" / "^" / "_" /
                "`" / "{" / "}" / "~"
     ALPHA        = "A".."Z"    ; Case insensitive ASCII Letter
     DIGIT        = "0".."9"    ; Numeric digit
]PRE]

区切子「'」とか、問題ありまくりじゃなかろうか?
(実際には、 [!#$%&'^`{}~] を使った 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:欄]]の [CODE(ABNF)[name]] パラメーターで [[encoded-word]] の使用を認めています。

*** Mozilla の実装

[2] Mozilla 1.2.1 では既定では >>3 の方法を使います。設定
(まだ [[UI]] では実装されていないらしい。) により RFC 2231 の方法を使えますが、

[PRE[
 Content-Type: application/excel;
  name*=ISO-8859-1'en-us, en, fr, ru, ja'membership.xls
]PRE]

のような値を生成してしまう問題があります。 ([[ietf-822]],
<news://news.gmane.org/3DFA24AE.7060604@alex.blilly.com>)

[6]
[CITE[Mozilla Japan ナレッジベース - 受取人のメールクライアントによって、添付ファイル名が正しく表示されない場合がある]] 
([[Thundirbird 1.5]])
<http://www.mozilla-japan.org/kb/solution/3067>

これに加えて値の方に生の [CODE(char)[/]]
を含めてしまうとか [SRC@en[mew-dist 26833]]、
分割した最後の引数の番号の後にまで [CODE(char)[*]]
をつけてしまうとか [SRC@en[mew-dist 26847]]
ずいぶんと杜撰な実装のようでございます。

([[名無しさん]] [WEAK[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文字しか含んでいないから不要なのです。
([[名無しさん]] [WEAK[2006-06-13 07:17:00 +00:00]])

[44] [CITE@en[193439 – RFC 2231 style encoding should be used for filename parameter of attachment (instead of RFC 2047 style)]]
( ([TIME[2014-10-28 06:31:37 +09:00]] 版))
<https://bugzilla.mozilla.org/show_bug.cgi?id=193439>

** HTTP

[14] [CITE@en[charset / Content-Type BNF flaw in RFC2616]] ([[Andreas Maier]] 著, [TIME[2007-05-23 20:41:09 +09:00]] 版) <http://lists.w3.org/Archives/Public/ietf-http-wg/2007AprJun/0065.html>
([[名無しさん]] [WEAK[2007-06-11 11:22:27 +00:00]])

** HTTP における引数の拡張

[17] [[HTTP]] における [[MIME]] 由来の[[ヘッダー]]に [[RFC 2231]]
が適用されるのか否かは長らく不明瞭なままでした。00年代までは [[HTTP]]
では [[RFC 2231]] の拡張はほとんど実装されていませんでしたが、
[[非ASCII文字]]を表現する方法として唯一標準化されていたのが [[RFC 2231]]
だったこともあり、 [[RFC 2231]] を実装するのが正しいと主張する人達もいました。

[REFS[
- [8]
[CITE@en[Applicability of RFC 2231 Encoding to Hypertext Transfer Protocol (HTTP) Headers]] ([CODE[2008-10-10 20:52:00 +09:00]] 版) <http://greenbytes.de/tech/webdav/draft-reschke-rfc2231-in-http-latest.html>
- [9]
[CITE[Test Cases for HTTP Content-Disposition header and RFC 2231/2047 Encoding]] ([TIME[2008-09-21 02:53:50 +09:00]] 版) <http://greenbytes.de/tech/tc2231/>
]REFS]

[19] 2010年になってようやく [[RFC 5987]] が出版され、 [[RFC 2231]]
の拡張の [[HTTP]] への適用方法が明らかにされました。

[REFS[
- [18] [CITE@en[RFC 5987 - Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters]] ([TIME[2014-08-10 01:17:43 +09:00]] 版) <http://tools.ietf.org/html/rfc5987>
]REFS]

;; [131] [[HTTP]] における [[RFC 2231]] / [[RFC 5987]] の実装状況については、
[CODE(HTTP)@en[[[Content-Disposition:]]]] を参照。


[132] [CITE@en[draft-reschke-rfc5987bis-07 - Indicating Character Encoding and Language for HTTP Header Field Parameters]]
( ([TIME[2014-10-17 03:39:39 +09:00]] 版))
<https://tools.ietf.org/html/draft-reschke-rfc5987bis-07>