仕様書

text/* MIME 型の一覧

[6] 何らかの規格で定義されている、 あるいは用例・実装例が見つかっている text/* 媒体型は以下の通りです。

意味

[17] 最上位型 text は、 テキスト情報textual informationを表しており >>22、 主にテキストで構成されるものを送信することを意図したものです >>16, >>24。

[19] text に分類できるものには、 表示や処理などの指示を含まない平文プレインテキストだけでなく、 それを超えたリッチテキストも含まれます。 特別なソフトウェアによってテキストの見た目を向上させることができても構いませんが、 内容がどんなものか知るためにそのようなソフトウェアが必須であってはなりません >>22。 text であるのは適切なソフトウェアがなくても利用者にそのまま表示してもよさそうなもので、 text でないものはそうではないものとされています >>16, >>24。

引数

[55] RFC 3676 は、 text/plain; format=flowed 以外のすべての text/* 型では送信時に delsp 引数を使用するべきではないし、 受信時に無視するべきであるとしています RFC 3676 4.。

text/plain に限らずすべての text/* が対象とされているのは、認識できない text/* は text/plain とみなすことになっているので、 不要な混乱を防ぐためでしょう。 (しかし、そうだとすると、 すべての text/* で text/plain の引数と同じ名前のものが使えなくなりますし、すべての媒体型で application/octet-stream の引数と同じ名前のものが使えなくなってしまいます。)

ともかく、 RFC 3676 の規定があるので、 text/* では RFC 3676 と同じ意味以外で delsp という名前の引数を定義しない方が良いでしょう。 (RFC 3676 は送受信時 (それもおそらくメイルの。) のするべきの規定しかしていませんが、使えない / 使いづらいものを定義しても仕方がないので、定義すらするべきではないでしょう。)

charset 引数

[63] text/* の多くの MIME型には charset 引数があります。詳しくは charset 引数の項を参照してください。

[15] 未知の text/* MIME型は text/plain として扱う旨の規定が MIME にはありますが、 charset をどう解釈するべきかは定かではありません。 当初の MIME の目論見ではすべて text/plain と解釈し得るものを text/* に集めたかったのでしょうが、 実際には各 text/* MIME型でそれぞれまったく異なる文字コードの処理を規定しています。

[18] Webブラウザーの実装ではテキストと判定されるものは同じ sniffing の方法を実装していると思われます。 (ただし「テキスト」は text/* とは一致しません。 HTML などはここでいう 「テキスト」ではありません。)

改行と正規形

[83] MIME では、 text/* 媒体型の正規化方法が規定されています。

OS などの環境の違いによって、改行は 0x0D だったり 0x0A だったり 0x0D 0x0A だったりその他だったりします。 電子メイルでの情報交換ではこれを 0x0D 0x0A に統一しよう、というのが正規化の骨子です。

MIME 適合 MUA は、 text/* の MIME 実体を送信する前に正規化しなければなりません。 また、受信して表示する時にはその環境に応じて正規形から local form に変換します。

[25] text/* の正準形canonical formは、 改行を常に CRLF で表現しなければなりません >>24。

[26] MIME の text/* では、 CRLF は改行を表さなければなりません。 CR や LF をそれ以外で使ってはいけません。 >>24

[44] 関連: 行 (MIME)

[79] HTTP においては、送信者は、 text/* の改行を、 CRLF でも、 CR のみでも、 LF のみでも、いずれで生成しても構いません。 ただし表現全体で一貫していないといけません。 >>78

[80] HTTP においては、送信者は、 text/* の改行を、 CRLF でも、 CR のみでも、 LF のみでも、いずれであっても構文解析できなければなりません >>78。

[81] HTTP においては、 text/* において 0x0D と 0x0A を CR と LF にそれぞれ用いる charset 以外であっても使うことができます >>78。

[84] 実際には HTTP, RTSP, SIP で正規化なんてしようものなら何が起こるかわかったもんじゃないです。

[88] ほとんど無視されてますが、 HTTP でも CR や LF や CRLF の使用は一つの実体本体内では一貫していないといけないとされてます。つまりは、改行表現が CR と LF の混合とか、 CRLF だけど一部 LF とか、そういうのは駄目だということですね。

[89] それから、 2616 は各媒体型がそれぞれみな正規形を持っているみたいなことを書いてますが、実際には持っている媒体型もあれば持ってない型もあって、むしろわざわざ規定している方が稀ですね。で、 MIME が絶対的に規定した text/* については緩和するなんていうもんですから、実質 HTTP には媒体型の正規化なんて概念はないと見ていいでしょう。(実際、 MIME 的正規化なんて考えずに実装したのを後から標準化したのが HTTP RFC ですから。。。 HTTP RFC は表面的 MIME 互換性(というかつじつまあわせ) のために苦心してますよ。。。)

[90] >>89 でもこの辻褄合わせは建前みたいなもので、全然役に立たないよねえ。もうちょっと MIME と HTTP と、あとは RTSP とか SIP で共通してれば同じ library を使えただろうけど、これだけ違ってると。。。

[91] RFC 2046 の4章の最初に

The content of these types must be handled by non-MIME mechanisms; they are opaque to MIME processors.

という説明があります。にも関わらず、 text/* に対しては正準形が定義されています。 これらは直ちに矛盾はしませんが (実体の適合性と利用者エージェントの要件は別)、 設計方針として整合しているようには思えません。

[12] HTTP と MIME の関門で変換が発生すると検査和が壊れてしまいますから、 HTTP であっても検査和を使う場合には正準形が推奨recommendedされています >>11。

[40] >>39 当時の Netscape は改行を書き換えることがあったということですかね。

[42] >>39 Internet Archive の Content-Type: ヘッダーが当時サーバーが送っていたものと同じだとすると、 それは text/plain なので、文句は Netscape に言え、 というのはお門違いなんですよね。。。

テキストと text/*

[21] テキストファイルも参照。

text/* の適格性

[1] 新しい text/* 媒体型を作ろうと考えている人へ: text/* 媒体型の意味を正しく理解し、 本当に適切か考えましょう。多くの場合、 application/* 媒体型とする方が適切です!

[2] text/* 媒体型は、 MIME によると、 plain text 的に表示した時に人間が特別な予備知識なく読むことができる形式に対する媒体型です。

しかし実際には、所謂 plain text, つまりバイナリではない、テキスト・エディタで開くことが出来る形式全般に誤用されています。

[4] text/* に対する扱いは MIME と HTTP で幾分差があるので注意が必要です。

[56] >>2 とかなんとか信じられてきましたが、 Ned Freed は RFC 2046 の4.1章のアレは実装的にはこうだよねという話であって text/* に対する要件ではない なんて見解を示しています Ned 2005。

• [Ned 2005] Re: Request to review media type in AVT working group last call: draft-ietf-avt-rtp-3gpp-timed-text.txt mid:01LOV0PQ4QQS00004T@mauve.mrochek.com

(名無しさん 2005-06-04 05:50:27 +00:00)

[57] >>56

確かに RFC 2046 を読んでみるとその通りなわけです。

XML を text/* に登録できないとかのアレはなんだったわけよ?

[58] >>56, 57

本当か?http://www.imc.org/ietf-xml-mime/mail-archive/msg00203.html を見よ。

[34] このよくわからない IETF の教条的方針のせいで、数多の混乱がもたらされました。

• [36] XML MIME型のうち text/xml 等が非推奨とされた件
• [35] XHTML MIME型が application/xhtml+xml になった件
• [37] JavaScript MIME型の混乱

[38] RFC 9239: Updates to ECMAScript Media Types, Matthew A. Miller, 2022-11-22T08:20:12.000Z https://www.rfc-editor.org/rfc/rfc9239#section-2

Note that this use of the "text" media type tree willfully does not align with its original intent per [RFC2045]. The reason for this is historical. [RFC4329] registered both the text/* and application/* types, marking the text/* types obsolete. This was done to encourage people toward application/*, matching the guidance in [RFC4288], the predecessor to [RFC6838]. Since then, however, the industry widely adopted text/* anyway.

text/javascript も参照。

処理

[28] 処理方法は、部分型により異なります。

[29] 未知の部分型は、 charset を理解できるなら text/plain、理解できないなら application/octet-stream として扱うべきです >>24。

歴史

   Beyond plain text, there are many formats for representing what might
   be known as "rich text".  An interesting characteristic of many such
   representations is that they are to some extent readable even without
   the software that interprets them.  It is useful, then, to
   distinguish them, at the highest level, from such unreadable data as
   images, audio, or text represented in an unreadable form. In the
   absence of appropriate interpretation software, it is reasonable to
   show subtypes of "text" to the user, while it is not reasonable to do
   so with most nontextual data. Such formatted textual data should be
   represented using subtypes of "text".

メモ

[3] 信じられないことに HTML 文書を text/plain で送ってくる HTTP サーバーが未だに存在しているんですが。 (WinIE は text/plain でも勝手に HTML 表示してしまうから、 気づいてないんだろうなあ。)

[60] W3C TPAC: decoding text/css — Anne’s Blog ( (2012-11-23 13:30:36 +09:00 版)) http://annevankesteren.nl/2012/11/decoding-css