[1] text/plain はいわゆる plain text (平文) の 媒体型で、もっとも基本的な形式として MIME で定義されています。

[9] MIME は媒体型が指定されていない時の既定値にこの text/plain を採用しています。

[2] また、 text/* の媒体型で UA が対応していないものは text/plain であるとして扱うことになっています。

仕様書

意味

[45] text/plain は、 text/* の一般的genericな部分型で平文を表すものです >>44。

[41] text/plain は、いかなる書式付け命令・指令をも含んでいない平文plain textを表します >>40, >>44, >>47。 平文は、 (場合によっては改行や改頁を挟みつつ) 文字を線形に並べたものと見ることができます >>44。 平文は、「そのまま」表示されることを意図したものです >>40, >>47。 その文章の意味を完全に理解するのに特別なソフトウェアが何も必要ではありません >>40。

[46] ただし平文には文字を同じ位置に重ねたものが含まれるかもしれませんし、 bidi が含まれるかもしれません >>44。[42] 厳密に解釈すれば、Wiki記法やMarkdownのような構文を使って記述されたものは text/plain とすることはできません。表示するソフトウェアが URL を自動リンクしたり、リストのように見えるものを自動的に整形したりするのは、 著者の指示ではなく表示側が勝手に行っているだけなので、問題では無さそうです。[43] text/plain; format=flowed はこの text/plain の意味と矛盾しています。

[55] インターネットメールの text/plain は、 MIME の本家本元でありながら、 歴史的、慣習的な解釈が加わった、純粋な平文とはいえないものになっています。

メール本文参照。

パラメーター

名前構文既定値説明状態出典
x-action
charsetcharset(プロトコル依存)Charset[MIME]
charset-edition4DIGIT(なし)Charset 制定年RFC 1922
charset-extensiontoken(なし)Charset 拡張RFC 1922
delsp間隔削除[RFC]
format"flowed" / "fixed"fixed書式RFC 2646, [RFC]
typetoken書式(なし)非標準
reply-typeoriginal非標準
x-rottoken(なし)簡易暗号化非標準
x-typetoken(なし)書式非標準Namazu

charset 引数

[3] charset パラメーター本体は MIME により、それを補助する charset-edition パラメーターと charset-extension パラメーターが RFC 1922 により定義されています。 詳しくは charsetパラメーターと text/* の説明を参照。

[33] >>32 で text/* の charset の既定値の扱いについて規定がありますが、 text/plain については RFC 2046 から変更せず、 US-ASCII を既定値とするとされています。

[34] 少なくても HTTP では現実に即していないと思いますが・・・。

"format" パラメーター

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

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

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

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

"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 形式であることをあらわします。

WWW での使用

フォーム提出形式として

[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 ( 版) http://www.whatwg.org/specs/web-forms/current-work/#text-plain

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

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

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

text/plain になってる HTML 文書

[28] ( 版) http://www.jisc.go.jp/ (2009年1月現在)

素片識別子

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

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

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

DOM

[38] Webブラウザーでの navigate では、架空の HTML文書に text/plain の文書の内容がそのまま含められることになっています HTML Standard。

[39] text/plain 自体にスクリプトを含めることはできませんが、 他の HTML文書で動作するスクリプトから iframe 等によって text/plain 文書の DOM にアクセスすることはできます。

[59] テキストファイルのDOM構築参照。

関連

[48] 未知の text/* MIME型は text/plain として扱うべきとされています。

text/* 参照。

メモ

[23] よく plain/text と間違えられます。 言葉としてそちらの方が自然ですから、仕方がありません。

(MIME で逆になったのは、元々 RFC 1049 式の text という型を細分化して plain という亜型名を付け足したからです。)

しかし、ただ間違えただけならまだしも、 そのまま実装しちゃう人もいるみたいですから呆れます。

[24] text/plain として札付けされていても、 実際には何らかの書式付けがなされていることはかなりあります。

極端な話、 XML Schema の単純型で表されるものはすべて text/plain で札付けしろと言っている仕様もあったりします。 「整数」とか「日付」のようなデータにまで媒体型名を割り振るのは阿呆らしいですし、 人間が読んでも予備知識無しに分かりますから (しかしその整数が何を意味しているのかはやっぱり分からないかも)、 text/plain を流用するのはまま妥当なことでしょう。 (Plain text なのに application/octet-stream というのも嫌な感じです。)

そのような細かなデータの札付けは元々媒体型の対象外でしょうから別としても (しかしフォームの提出などで頻繁に用いられているのは事実)、 プログラムのソース・コードや定型の文書など、 書式のある文書が text/plain でよく札付けされています。

Plain text の意味が非常に広くとられる傾向にあるというのもそうですが、 よく考えてみれば、狭義の plain text にしても改行や段落や引用やちょっとした見出しのように書式を持っています。 結局は程度の問題ということになるでしょう。

[30] [sylpheed-jp:10706] Re: format=flowedへの対応 ( 版) http://www.sraoss.jp/pipermail/sylpheed-jp/2008-November/000707.html

[31] XInclude 1.1 Requirement and Use Cases ( ( 版)) http://www.w3.org/TR/2012/NOTE-xinclude-11-requirements-20120214/

[35] N-Triples ( ( 版)) http://www.w3.org/TR/2013/NOTE-n-triples-20130409/#n-triples-mediatype

[36] IRC logs: freenode / #whatwg / 20140904 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20140904

[37] RFC 3801 - Voice Profile for Internet Mail - version 2 (VPIMv2) ( ( 版)) http://tools.ietf.org/html/rfc3801#section-4.5.4

[49] BEACON link dump format ( 版) https://gbv.github.io/beaconspec/beacon.html

The RECOMMENDED MIME type of BEACON files is "text/plain". The file extension .txt SHOULD be used when storing BEACON files.

[50] Remove allow non-ASCII-compatible encodings flag · whatwg/html@c485b70 ( 版) https://github.com/whatwg/html/commit/c485b70bfe41ed1302c451bc62b58df80cffd325

[51] Update integration with Encoding Standard · whatwg/html@6a31c26 ( 版) https://github.com/whatwg/html/commit/6a31c26cf12e39dab1a488e75dd56c03d6786d39

[52] Fix form submission's encoding algorithms ( (annevk著, )) https://github.com/whatwg/html/commit/ec42efb1d7c3a2e34db21b8076a8a3f4bd6dfb81

[53] Bitbucket API () https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Busername%7D/%7Brepo_slug%7D/patch/%7Bspec%7D

The raw patch is returned as-is, in whatever encoding the files in the repository use. It is not decoded into unicode. As such, the content-type is text/plain.

[54] text/plain とは一体...

[56] Move _charset_ handling to construct the form data set (tkent-google著, ) https://github.com/whatwg/html/commit/8c212e549607a41b6d40d953b47d9f3e749533f3

[57] Move _charset_ handling from "multipart/form-data encoding algorithm"… by tkent-google · Pull Request #3645 · whatwg/html () https://github.com/whatwg/html/pull/3645

[58] CORB: protecting certain nosniff and 206 responses (anforowicz著, ) https://github.com/whatwg/fetch/commit/794dd5452705564538440cc5b2c1f13d909e2f9a