text/* MIME 型の一覧[6] 何らかの規格で定義されている、
あるいは用例・実装例が見つかっている text/*
媒体型は以下の通りです。
text/* MIME型[17] 最上位型 text は、
テキスト情報を表しており >>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/* の正準形は、
改行を常に CRLF で表現しなければなりません >>24。
[26] MIME の text/* では、 CRLF
は改行を表さなければなりません。 CR や LF
をそれ以外で使ってはいけません。 >>24
[79] HTTP においては、送信者は、 text/* の改行を、
CRLF でも、 CR のみでも、 LF のみでも、いずれで生成しても構いません。
ただし表現全体で一貫していないといけません。 >>78
[80] HTTP においては、送信者は、 text/* の改行を、
CRLF でも、 CR のみでも、 LF のみでも、いずれであっても構文解析できなければなりません
>>78。
text/html については改行として CR、LF、
CRLF のいずれも認められていますが、 >>78 や >>80 に基づき認められるというよりは、
HTML Standard により直接的に認められていると考えるべきでしょう。
その他の MIME型も、それぞれが構文や構文解析方法を定義していて、
厳密にはそれらの解釈は等しくありません。[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 を使えただろうけど、これだけ違ってると。。。
The content of these types must be handled by non-MIME mechanisms; they are opaque to MIME processors.
という説明があります。にも関わらず、
text/* に対しては正準形が定義されています。
これらは直ちに矛盾はしませんが
(実体の適合性と利用者エージェントの要件は別)、
設計方針として整合しているようには思えません。
[12] HTTP と MIME の関門で変換が発生すると検査和が壊れてしまいますから、 HTTP であっても検査和を使う場合には正準形が推奨されています >>11。
Some users of web browsers from Netscape report that the cabinet files are corrupt. Investigation has shown that in the copy received on these users’ machines, each line-feed has been expanded to a carriage-return and line-feed pair. I do not use Netscape’s browsers and I cannot begin to think why they treat cabinet files as text rather than as binaries. If you encounter this problem and you are a Netscape user, then please direct your enquiries to Netscape, not to me.
Copyright © 1997-99. Geoff Chappell. All rights reserved.
[40] >>39 当時の Netscape は改行を書き換えることがあったということですかね。
[42] >>39 Internet Archive の Content-Type: ヘッダーが当時サーバーが送っていたものと同じだとすると、
それは text/plain なので、文句は Netscape に言え、
というのはお門違いなんですよね。。。
text/*text/* の適格性[1] 新しい text/* 媒体型を作ろうと考えている人へ:
text/* 媒体型の意味を正しく理解し、
本当に適切か考えましょう。多くの場合、
application/* 媒体型とする方が適切です!
[2] text/* 媒体型は、 MIME
によると、 plain text
的に表示した時に人間が特別な予備知識なく読むことができる形式に対する媒体型です。
しかし実際には、所謂 plain text, つまりバイナリではない、テキスト・エディタで開くことが出来る形式全般に誤用されています。
[4] text/* に対する扱いは MIME と HTTP
で幾分差があるので注意が必要です。
[56]
>>2 とかなんとか信じられてきましたが、 Ned Freed
は RFC 2046 の4.1章のアレは実装的にはこうだよねという話であって
なんて見解を示しています Ned 2005。text/* に対する要件ではない
(名無しさん 2005-06-04 05:50:27 +00:00)
確かに RFC 2046 を読んでみるとその通りなわけです。
XML を text/*
に登録できないとかのアレはなんだったわけよ?
本当か?http://www.imc.org/ietf-xml-mime/mail-archive/msg00203.html を見よ。
[34] このよくわからない IETF の教条的方針のせいで、数多の混乱がもたらされました。
text/xml 等が非推奨とされた件application/xhtml+xml になった件The information in CellML Umbrella documents cannot be interpreted
without understanding the semantics of the XML elements used to mark
up the model structure. Therefore, the application top-level type is
used instead of the text top-level type.
The server MUST process a text/xml or application/xml request body,
and MAY process request bodies in other formats. See [RFC3023] for
guidance on packaging XML in requests.
[38] RFC 9239: Updates to ECMAScript Media Types, Matthew A. Miller, 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 も参照。
[29] 未知の部分型は、 charset を理解できるなら
text/plain、理解できないなら application/octet-stream
として扱うべきです >>24。
application/octet-stream のように扱うようです。
また Web では text/plain として扱われるものとそうでないものがあります
(テキストファイル参照)。The "text" media type is intended for sending material which is principally textual in form. A "charset" parameter may be used to indicate the character set of the body text for "text" subtypes, notably including the subtype "text/plain", which is a generic subtype for plain text. Plain text does not provide for or allow formatting commands, font attribute specifications, processing instructions, interpretation directives, or content markup. Plain text is seen simply as a linear sequence of characters, possibly interrupted by line breaks or page breaks. Plain text may allow the stacking of several characters in the same position in the text. Plain text in scripts like Arabic and Hebrew may also include facilitites that allow the arbitrary mixing of text segments with opposite writing directions.
"text" 媒体型は基本的に文字であるものを送るのに使います。 "charset" パラメーターを各 "text" 亜型 (とりわけ平文の総称亜型である "text/plain" を含む) の本文の文字集合を示すのに 使うことが出来ます。平文は書式付け命令, 書体属性指定, 処理命令, 解釈指令, 内容マーク付けなどの手法を提供しませんし認めません。 平文は単純に文字の一次列に見えます。文字はもしかすると改行や改頁と 解釈されるかもしれません。平文は幾つかの文字を文中の同じ位置に 重ね打ちすることが出来ます。アラビアやヘブライのような用字系は 逆書字方向の文断片の任意の混合を認める機能も含むかもしれません。
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".
平文のほかに、「裕福文」として知られているような多くの表現方法 があります。多くのこのような表現の興味深い特徴は、これを解釈する ソフトウェア無しでもある程度可読であるということです。これを 画像や音声や非可読形式で表される文と最上位で区別するのは有用なことです。 適切な解釈ソフトウェアが無い場合、 "text" の亜型を利用者に示すのは、 ほとんどの非文データをそうするのとは違って道理にかなっています。 このような書式付けされた文字データは "text" の亜型を使って表現するべきです。
The canonical form of any MIME "text" subtype MUST always represent a line break as a CRLF sequence. Similarly, any occurrence of CRLF in MIME "text" MUST represent a line break. Use of CR and LF outside of line break sequences is also forbidden.
MIME "text" 亜型の正規形は常に改行を CRLF 列で表さなければなりません。同様に、 MIME "text" 中の CRLF は改行を表さなければなりません。 CR と LF を改行シーケンス以外で使用することも禁止します。
This rule applies regardless of format or character set or sets involved.
この規則はどんな形式や文字集合であっても適用されます。
NOTE: The proper interpretation of line breaks when a body is displayed depends on the media type. In particular, while it is appropriate to treat a line break as a transition to a new line when displaying a "text/plain" body, this treatment is actually incorrect for other subtypes of "text" like "text/enriched" [RFC-1896]. Similarly, whether or not line breaks should be added during display operations is also a function of the media type. It should not be necessary to add any line breaks to display "text/plain" correctly, whereas proper display of "text/enriched" requires the appropriate addition of line breaks.
参考: 本体が表示される時の改行の適切な解釈は媒体型によります。 特に、 "text/plain" 本体を表示する時に改行を新しい行へ移るものとして扱うのは適切ですが、 "text/enriched" [RFC-1896] のような "text" の他の亜型には実際この扱いは間違いです。 同様に、改行が表示操作により追加されるべきかどうかも媒体型の機能によります。 "text/plain" を正しく表示するのに改行を追加する必要があるのは望ましくありませんが、 "text/enriched" の適切な表示には適切に改行を追加する必要があります。
NOTE: Some protocols defines a maximum line length. E.g. SMTP [RFC-821] allows a maximum of 998 octets before the next CRLF sequence. To be transported by such protocols, data which includes too long segments without CRLF sequences must be encoded with a suitable content-transfer-encoding.
参考: 幾つかのプロトコルは最大行長を決めています。 例えば SMTP は最大で998オクテットがそれに続く CRLF シーケンスの前にあることを認めています。このようなプロトコルで転送するには、 CRLF シーケンスなしの長過ぎる部分を含むデータは適切な内容転送符号化で符号化しなければなりません。
See charsetパラメーター
The simplest and most important subtype of "text" is "plain". This indicates plain text that does not contain any formatting commands or directives. Plain text is intended to be displayed "as-is", that is, no interpretation of embedded formatting commands, font attribute specifications, processing instructions, interpretation directives, or content markup should be necessary for proper display. The default media type of "text/plain; charset=us-ascii" for Internet mail describes existing Internet practice. That is, it is the type of body defined by RFC 822.
No other "text" subtype is defined by this document.
他の "text" 亜型はこの文書では定義しません。
Unrecognized subtypes of "text" should be treated as subtype "plain" as long as the MIME implementation knows how to handle the charset. Unrecognized subtypes which also specify an unrecognized charset should be treated as "application/octet-stream".
認識出来ない "text" の亜型は、 MIME 実装者が charset をどう扱うか 知っているなら亜型 "plain" として扱います。認識出来ない charset も指定された認識出来ない亜型は "application/octet-stream" として扱います。
Internet media types are registered with a canonical form.
{1945,2068} In general, an{2616} AnEntity-Bodyentity-body transferred via HTTP messagesmustMUST be represented in the appropriate canonical form prior to its transmission; the exception isexcept for "text" types, as defined in the next paragraph.
Internet 媒体型は正規形とともに登録されます。 HTTP メッセージで転送される実体本文は、次の段落で定義する "text" 型を除いては、転送の前に適切な正規形で表現しなければなりません。
When in canonical form, media
Mediasubtypes of the "text" type use CRLF as the text line breakwhen in canonical form. HTTP relaxes this requirement and allows the transport of text media with plain CR or LF alone representing a line break whenusedit is done consistentlywithin the Entity-Bodyfor an entire entity-body. HTTP applicationsmustMUST accept CRLF, bare CR, and bare LF as being representative of a line break in text media received via HTTP. In addition, if the textmediais represented in a character set that does not use octets 13 and 10 for CR and LF respectively, as is the case for some multi-byte character sets, HTTP allows the use of whatever octet sequences are defined by that character set to represent the equivalent of CR and LF for line breaks. This flexibility regarding line breaks applies only to text media in theEntity-Bodyentity-body; a bare CR or LFshould notMUST NOT be substituted for CRLF within any of the HTTP control structures (such as header fields and multipart boundaries).
正規形では、 "text" 型の媒体亜型は CRLF を文改行に使います。 HTTP はこの要件を緩和し、文媒体を生の CR や LF だけを改行の表現に使って 転送することを、実体本文全体で一貫している場合は認めます。 HTTP 応用は CRLF, 単独 CR, 単独 LF を HTTP で受け取った文媒体の改行の表現 であるとして認めなければなりません。加えて、文がオクテット 13 および 10 をそれぞれ CR と LF に使わない、幾つかの多バイト文字集合の場合のような 文字集合で表現されている場合は、 HTTP haその文字集合で定義されている CR や LF と同等のオクテット列を使うことを認めます。この柔軟性は、 実体本文中の文媒体にのみ適応されます。単独の CR や LF は HTTP 制御構造 (頭領域や多部分区切りなど) の中では CRLF の代わりに使っては いけません。
If
the body has beenan entity-body is encoded with a{1945,2068} Content-Encoding{2616} content-coding, the underlying datashouldMUST be incanonical forma form defined above prior to being encoded.
実体本文が内容符号化で符号化されている時は、中のデータは 符号化の前に上に定義した形にしておかなければなりません。
The "charset" parameter is used with some media types to define the character set (
Sectionsection 3.4) of the data. When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined to have a default charset value of "ISO-8859-1" when received via HTTP. Data in character sets other than "ISO-8859-1" or its subsetsmustMUST be labelled with an appropriate charset valuein order to be consistently interpreted by the recipient. {2616} See section 3.4.1 for compatibility problems.
"charset" パラメーターを幾つかの媒体型でデータの文字集合を定義するのに 使います。 HTTP で受信した時に、送信者により明示された charset パラメーターが無い場合は、 "text" の媒体亜型は既定の charset 値 "ISO-8859-1" を持つものと定義します。 "ISO-8859-1" かその部分集合でない文字集合のデータは適切な charset 値で札付けしなければなりません。互換性問題については3.4.1節を 参照して下さい。
{1945} Note: Many current HTTP servers provide data using charsets other than "ISO-8859-1" without proper labelling. This situation reduces interoperability and is not recommended. To compensate for this, some HTTP user agents provide a configuration option to allow the user to change the default interpretation of the media type character set when no charset parameter is given.
注意 : 多くの現在の HTTP サーバーは、適切に札付けせずに
ISO-8859-1 以外の charset
を使ってデータを提供しています。この状況は相互運用性を低下させるので、
推奨しません。これを補正するために、 HTTP 利用者エージェントの中には設定選択肢を用意して、
charset 引数が与えられていない時に利用者が媒体型文字集合の既定の解釈を変更することを可能としているものもあります。
{2068} Some HTTP/1.0 software has interpreted a Content-Type header without charset parameter incorrectly to mean "recipient should guess." Senders wishing to defeat this behavior MAY include a charset parameter even when the charset is ISO-8859-1 and SHOULD do so when it is known that it will not confuse the recipient.
Unfortunately, some older HTTP/1.0 clients did not deal properly with an explicit charset parameter. HTTP/1.1 recipients MUST respect the charset label provided by the sender; and those user agents that have a provision to "guess" a charset MUST use the charset from the content-type field if they support that charset, rather than the recipient's preference, when initially displaying a document.
注 : RFC 2616 ではこの部分は 3.6.1 節に移動しています。
charset//HTTP を参照。
RFC 2045 [7] requires that an Internet mail entity be converted to canonical form prior to being transferredRFC 1521MIME, {1945} as described in Appendix G of RFC 1521 [5], {2616} as described in section 4 of RFC 2049 [48] . Section{1945} 3.6.13.7.1 of this document describes the forms allowed for subtypes of the "text" media type when transmitted over HTTP.MIMERFC 2046 requires that content with a type of "text" represent line breaks as CRLF and forbids the use of CR or LF outside of line break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a line break within text content when a message is transmitted over HTTP.
[7] RFC 2045 では、 Internet メイルの実体は転送される前に RFC 2049 の第4章で説明された通り正規形に変換する必要があります。 この文書の3.7.1節は "text" 媒体型の亜型を HTTP 上で転送する時に認められる形式について説明しています。 RFC 2046 は "text" の型の内容は CRLF で改行を表現することを要求し、改行シーケンス以外で CR や LF を使うことを禁止しています。 HTTP は、 HTTP 上でメッセージを転送する際に文中で CRLF, 単独の CR, 単独の LF を改行を示すのに使うことを認めています。
RFC 1521 requires that content with a Content-Type of "text" represent line breaks as CRLF and forbids the use of CR or LF outside of line break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a line break within text content when a message is transmitted over HTTP.
RFC 1521 は、 Content-Type が text
の内容が改行を CRLF で表現することを要求し、
改行列以外での CR と LF
の使用を禁止しています。 HTTP は、メッセージが HTTP
上を転送されるに際して文内容中の改行を示すために
CRLF, 単独の CR および単独の LF
を認めています。
Where it is possible, a proxy or gateway from HTTP to a strict
RFC 1521MIME environmentshouldSHOULD translate all line breaks within the text media types described inSection 3.6.1section 3.7.1 of this document to theRFC 2049 canonical form of CRLF. Note, however, that thisRFC 1521MIMEmay{2616} might be complicated by the presence of a Content-Encoding and by the fact that HTTP allows the use of some character sets which do not use octets 13 and 10 to represent CR and LF, as is the case for some multi-byte character sets.
[8] 可能であれば、 HTTP から厳密な MIME
環境への串や関門はこの文書の3.7.1節で説明した文媒体型中の全ての改行を
RFC 2049 正規形の CRLF に変換するのが良いです。しかし、
Content-Encoding の出現や, HTTP
が幾つかの多バイト文字集合の場合のようにオクテット
13 と 10 を CR や LF
を表現するのに使わない文字集合の使用を認めているという事実が、これを複雑にしていようことに注意して下さい。
{2616} Implementors should note that conversion will break any cryptographic checksums applied to the original content unless the original content is already in canonical form. Therefore, the canonical form is recommended for any content that uses such checksums in HTTP.
[9] 実装者は、元の内容が既に正規形で無かった時に、元の内容に適応される暗号検査和が壊れようことに注意するのが良いです。 このため、 HTTP で検査和を使う内容では正規形が推奨されます。
注意: 注記のない修正点は RFC 1945 → RFC 2068 もの。
[3] 信じられないことに HTML 文書を text/plain で送ってくる
HTTP サーバーが未だに存在しているんですが。 (WinIE は
text/plain でも勝手に HTML 表示してしまうから、
気づいてないんだろうなあ。)
[60] W3C TPAC: decoding text/css — Anne’s Blog ( ( 版)) http://annevankesteren.nl/2012/11/decoding-css