"format" パラメーター

[4] RFC 2646 urn:ietf:rfc:2646 で定義されています。

値は大文字・小文字を区別しません。 "fixed" が既定値で、 MIME の "text/plain", すなわち RFC 822 の本文の形式と同じ意味です。

"flowed" の場合は、 RFC 2646 で定義されているように解釈します。

[7] 実際のところ flowed 形式は (見た目こそ同様ではありますが意味的には) fixed の text/plain 形式と随分と差があります。 標準化に際して別の媒体型にするかパラメーターにするかの激しい議論があったようですが、結局こうなりました。

• [8] Message-pm では fixed と flowed を別モジュールに分けて実装しています。 (というかそうしないととっても複雑になりそうだった。)
• [19] delsp=yes ってのをつけてるのがいます。 X-Mailer: Apple Mail (2.552) なのが。
• [20] 2003-11-21 08:04:53 +00:00 US-ASCII: Hotmail なんかも format=flowed を送ってきます。
• [21] Flowed って text/plain にかなり重大な意味的修正を加えてますよね。それを text/なんたらじゃなくて text/plain にしないといけなかったというのが、なんとも MIME の失敗を物語っているようで。 だって、 MIME がちゃんと実装されていれば、 text/なんたらは未対応でもちゃんと text/plain に fallback されるはずで、何も問題ないんだから。

"type" パラメーター, "x-type" パラメーター

[5] 小分類を示します。このパラメーターはどの RFC でも定義されていませんが、用例が観測されています。

[6] 値 "patch" は、内容がパッチであることを示します。 パッチに使われる媒体型には、他に text/x-patch媒体型がありますが、 "type" parameter も text/x-patch も、使用するべきではありません。 text/*媒体型では改行の正規化などの制限があるからです。 (See text/*媒体型の正規化) パッチには application/octet-stream媒体型を使うべきです。 (と、どこかの ML で守岡さんが書いてた。)

[7] namazu は内部処理に "x-type" パラメーターを使っています。 現在使われている値は "rfc" で、 RFC 形式であることをあらわします。

フォーム提出形式として

• [10] form 要素の enctype 属性に指定された時に、対応する UA は application/x-www-form-urlencoded と同じようにフォーム項目の値を用意し、 URI符号化は行わず、 "&" の代わりに改行を使います。
• [11] >>10 但しこの動作はどの RFC や W3C の仕様書にも書かれていません。 de facto なものです。
• [12] >>10-11 charset をちゃんと処理してるのかとか、もともとの改行はどうなるのかとか謎ですし

[25] action が mailto: URI の時によく使われます。

[22] Web Forms 2.0 や HTML 5 では enctype が text/plain の時の UA の挙動も規定しています。

[26] フォームでメールを送信するには http://tohoho.wakusei.ne.jp/lng/199812/98120210.htm

[29] Web Forms 2.0 (2009-01-05 20:07:15 +09:00 版) http://www.whatwg.org/specs/web-forms/current-work/#text-plain

鯖の誤設定と逝かれたブラウザ

• [13] 一部の WWWブラウザは、内容に HTML のタグらしきものがあると、媒体型が text/plain であっても勝手に HTML とみなしてみたり、画像のヘッダらしきものがあると画像とみなしてみたりします。
• [14] このような誤動作するのは、 WinIE/MacIE, Opera (こちらは設定で変更可。既定値 off にしとけよな。。。)です。

[15] HTTP サーバーの設定不良が原因で、媒体型が無意味に text/plain になっている資源は沢山あります。

• [17] Mozilla は、標準モード以外では媒体型が text/css 以外である CSS のスタイル・シート (らしきもの) を「正しく」読み込んでしまいますし、画像などで媒体型を無視する挙動も見せます。 Mozilla はまだまともな方で、 IE などは媒体型よりも拡張子や内容を重視しているように思えます。
• [18] このような挙動は、時に安全上の重大な問題をも引き起こします。 IW:Tiki:"Tiki/クロスサイトスクリプティング" では、 Tiki の text/plain 出力の内容に HTML とも解釈し得るものが含まれていて、かつ危険な code も含まれている場合に問題 (クロスサイトスクリプティング脆弱性) が発生することについての議論です。 (どうして異常な UA の尻拭いをする必要があるのか, するとしたらどういう方法があるのか, 云々)

[60] N-Triples は独自の規定を持っています。

素片識別子

[27] 媒体型 text/plain の素片識別子は RFC 5147 で規定されています。

[16] 歴史的にはそれと異なった実装もありました。

詳しくは text/plainの素片識別子の項を参照してください。