RFC 2231の方法

引数 (MIME、HTTP)

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

[63] MIME のほか、派生した電子メールネットニュースHTTPRTSPSIPMSRPCoAPmultipart/form-data といった様々なプロトコルで採用されている構文です。

multipart/form-dataMIME とも HTTP とも一部異なる構文や処理方法が採られていますので、本項では区別しています。

仕様書

[146] MIME においては RFC 2045RFC 2231 が、 HTTP においては RFC 7231RFC 5987引数構文の主要な仕様書となっています。

構文

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

  1. 名前
  2. ?
    1. =

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

  1. ?
    1. 引数
    2. *
      1. ;
      2. 引数

MIME における構文

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

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

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

  1. +
    1. 属性に使える文字
[69] RFC 2045 時代は字句とされていましたが、 RFC 2231 の拡張により *'% が除外されています >>21

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

  1. *
  2. |
    1. 0
    2. =
      1. 1 ... 9
      2. *
        1. ASCII数字

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

  1. |
    1. 字句
    2. 引用文字列
    3. 拡張された最初の値
    4. 拡張されたその他の値

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

  1. ?
    1. charset
  2. '
  3. ?
    1. 言語タグ
  4. '
  5. >>72 の値

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

  1. *
    1. |
      1. 属性に使える文字
      2. =
        1. %
        2. ASCII十六進数字
        3. ASCII十六進数字
[74] パーセント符号化URL で使われているものと同じものですが、 両者の定義は個々になされています。また MIME では「パーセント符号化」 という用語は使っていません。

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

[135] RFC 2183MIME Content-Disposition: ヘッダーにおける値の構文の選択について、次のように述べています >>134

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

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

HTTP における構文

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

[90] 具体的な構文は、それぞれの項を参照。
[91] MIME から派生したヘッダーであっても、 HTTP では HTTP 独自の構文を規定しています。

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

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

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

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

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

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

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

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

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

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

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

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

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

RFC 5987 による構文

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

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

  1. 引数名
  2. ?
    1. *
  3. =

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

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

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

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

  1. |
    1. 字句
    2. 引用文字列
    3. 拡張された値

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

  1. charset
  2. '
  3. ?
    1. 言語タグ
  4. '
  5. >>105
[75] これは MIME における拡張された最初の値に相当します。
[76] MIME と違って charset は必須となっています。

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

  1. *
    1. |
      1. 属性の文字
      2. =
        1. %
        2. ASCII十六進数字
        3. ASCII十六進数字
[116] HTTP では RFC 3986パーセント符号化の規定が参照されています。
[106] 拡張された値の解釈については、以後の章を参照。

引数値拡張

[20] RFC 2231MIME引数の拡張として、次の仕組みを追加しています >>21

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

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

[98] MIME における採用箇所

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

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

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

[96] HTTP における採用箇所
[97] MIME と違って Content-Type: では採用されていません。

[133] HTTP Link: ヘッダーの派生形式である CoREtitle 引数で拡張構文を採用しています。

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

引数値の継続

[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

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

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

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

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

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

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

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

[51] 次の例 >>21

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 が指定されています。

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

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

[157] Content-Language: も参照。

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

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

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

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

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

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

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 に相当するバイト列として解釈するべきなのかは不明です。

[85] 例えば、 U+3000 のあとに .txt と続くファイル名

Content-Disposition: attachment;
  filename*0*=shift_jis'ja'%81;
  filename*1="@.txt"
... と表現して良いのでしょうか。

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

重複の処理

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

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

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

[130] Link: ヘッダーtitle 引数はこれに従い、 title* を優先するべき>>129 としています。

[140] Content-Disposition: ヘッダーfilename 引数でも、 filename* を優先するべき>>141 とされています。

[148] ダイジェスト認証username 引数username* 引数が同時に指定されている場合、 誤りとされています。

それがどう処理するべきものかは不明です。

charset

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

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

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

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

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

[114] RFC 2978 の定義から ' を除外したものです >>15
[119] これらの charset を受信した時にどうするべきなのかは明記されていません。

[151] HTTPヘッダー Authentication-Control:HTTP認証の一種 Mutual は、 UTF-8 のみを認めています >>150, >>153

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


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

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

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

言語タグ

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

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

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

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

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

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

[152] HTTPヘッダー Authentication-Control:HTTP認証の一種 Mutual は、 空文字列のみを認めています >>150, >>153

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

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

IMAP における処理

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

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

関連

[156] 似て非なるものに DCSV があります。

歴史

MIME における引数の拡張

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

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

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

[11] RFC 2231 4. Parameter Value Character Set and Language Information
   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.

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:

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

   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) 継続パラメーター値の最初の部分が符号化されている場合、 言語及び文字集合領域区切りは領域が空であってもなければなりません

[12] RFC 2231 6. IMAP4 Handling of Parameter Values

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

[13] RFC 2231 7. Modifications to MIME ABNF

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 2231encoded-word言語を指定できるようにする拡張も規定しています。

encoded-word を参照。

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

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

RFC 2482 を参照。

他の仕様の BNF 抜粋

RFC 1766

    Language-Tag = Primary-tag *( "-" Subtag )
    Primary-tag = 1*8ALPHA
    Subtag = 1*8ALPHA
   Whitespace is not allowed within the tag.

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

RFC 2978

     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 が使えるとか、 RTSPSIP では 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 の使用を認めています。

Mozilla の実装

[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

HTTP

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

HTTP における引数の拡張

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

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

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

[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

[149] S3のContent-Dispositionのブラウザ対応について調査してみた - Innovator Japan Engineers’ Blog () http://tech.innovator.jp.net/entry/s3-content-disposition

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