text/*

MIME型群 text/*

[77] text/* は、テキストMIME型群です。

仕様書

text/* MIME 型の一覧

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

[32] text/* MIME型
text/vnd.in3d.3dml
text/vnd.abc
text/abiword
text/actActionSheet非標準, 非推奨[W3C NOTE-AS]
text/x-actionscript
text/x-adaAda source非推奨[WING]
text/x-adasrc
text/apl
text/vnd.sun.j2me.app-descriptor
text/x-apple-macintalk
text/x-ascii-*ASCII 文書非推奨[Apache]
text/x-ascii-art
text/x-ascii-html
text/x-ascii-plain
text/x-asm
text/x-asp
text/x-asterisk
text/x-astromark
text/x-authors著者一覧[Gnome]
text/x-aveAve document[WING]
text/bib参考文献一覧非標準[Gnome]
text/x-bibtex
text/x-apple-binscii
text/x-bison
text/x-brainfuck
text/x-boo
text/boolean非標準, IANA 登録XUP
text/bssCSS テレビ放送プロファイル非標準
text/x-cC source非推奨[HTTP RFC], [Gnome]
text/x-c-sourceC source非推奨[WING]
text/cache-manifest
text/x-cassandra
text/x-csrcC source非推奨
text/x-c++C++ source非推奨[Gnome]
text/x-c++hdrC++ header非推奨
text/x-c++srcC++ source非推奨
text/calendar
text/x-calendar
text/casCAS非標準[W3C NOTE-AS]
text/x-ceylon
text/x-changelog
text/x-chdr
text/cloud-config-archive
text/cloud-config
text/cloud-boothook
text/x-clojure
text/x-cmake
text/cmmlCMML満期 (IETF I-D)
text/x-cmmlCMML満期 (IETF I-D)
text/vnd.wap.co非標準[WAP]
text/x-co-desc
text/coffeescript
text/x-coffeescript
text/comma-separated-values
text/x-comma-separated-valuesCSV->text/csv[Gnome]
text/vnd.net2phone.commcenter.command
text/x-common-lisp
text/x-component
text/vnd.wap.connectivility-xml非標準[WAP]
text/x-confCONF file非推奨[WING]
text/x-copyingLicense 規約[Gnome]
text/cppC++ source非標準
text/x-cpp
text/x-cpp-sourceC++ source非推奨[WING]
text/x-credits著者の credit[Gnome]
text/x-cross-domain-policy
text/x-crystal
text/x-cshcsh script非推奨[Gnome]
text/x-csharp
text/x-csharpsrc
text/vnd.csr
text/x-csrc
text/css
text/x-css-cmml満期 (IETF I-D)CMML
text/x-css-inlineCSS (style 属性)WebHACC
text/csv
text/x-csv
text/vnd.curl
text/csv-schemaCSV Schema
text/x-cvsweb-markup
text/x-cython
text/x-d
text/x-dsrc
text/x-dclDCL script非推奨[Gnome]
text/x-moz-deleted
text/x-diff
text/directory
text/x-django
text/x-dockerfile
text/download
text/vnd.dmclientscript
text/x-dos-batchDOS batch file非推奨[WING]
text/x-dpatch
text/x-dot-template
text/x-dslDSSSL stylesheet非推奨[Gnome]
text/dssslDSSSL stylesheet非標準, 非推奨
text/x-dtdSGML DTD非推奨[Gnome]
text/dns
text/x-dylan
text/x-ecl
text/x-emacs-lisp
text/x-email
text/ecmascript
text/x-eiffel
text/x-elixir
text/x-ejs-template
text/x-elm
text/x-emelody[WAP]
text/english
text/x-erlang
text/enriched
text/x-errorlistCompilation error list[WING]
text/x-estraier-draft
text/event-stream
text/example
text/x-example
text/x-ez80
text/x-factor
text/x-fcl
text/x-feature
text/x-forth
text/x-fortran
text/x-fsharp
text/ftp-dir
text/ftp-dir-listing
text/vnd.fmi.flexstor
text/vnd.fly
text/x-game-map
text/x-gap
text/x-gas
text/x-generic
text/x-genie
text/x-github-pull-request
text/x-gettext-translation
text/x-gettext-translation-template
text/x-go
text/goml
text/gpx
text/x-gql
text/vnd.graphviz
text/x-groovy
text/gss
text/x-gss
text/x-gtkrcGTK rc[Gnome]
text/x-gwt-rpc
text/x-glsl-fs
text/x-h2h
text/x-h2h+htmlH2H 1.0 (HTML 混じり)廃止
text/h323H.323 Internet Telephony非標準, [M$]
text/x-haml
text/x-handlebars-template
text/x-haskell
text/x-hatena-syntax
text/x-haxe
text/x-hdmlHDML時代遅れversion={2.0|3.0|3.1}
text/x-hive
text/hjson
text/html
text/x-html
text/htmlr
text/_moz_htmlcontext
text/_moz_htmlinfo
text/x-html-srcdoc
text/x-html-templateHTML‐to‐be
text/hnfHNF非標準 ->text/x-hnf[NAMAZU]
text/x-hnfHNF, H2H 0.9
text/x-hxml
text/ico非標準, 時代遅れ->image/vnd.microsoft.icon[IANAREG image/vnd.microsoft.icon]
text/x-jade
text/x-idl
text/x-imagemap鯖側画像写像非推奨, 時代遅れ
text/x-imelody
text/x-include-once-url
text/x-include-url
text/x-info[MAGIC]
text/x-ini
text/x-ini-file
text/x-installINSTALL[Gnome]
text/iuls(*.uls)非標準
text/vnd.sun.j2me.app-descriptor[IANAREG]
text/x-javaJava source[Gnome], 非推奨
text/x-java-sourceJava source非推奨[WING]
text/javascriptJavaScriptIETF 情報提供 RFC (廃止) → application/javascript, IANA 登録済 (廃止)RFC 4329, [IANAREG]
text/x-javascriptJavaScriptapplication/javascript
text/javascript1.1->application/x-javascript; version=1.1非標準, 時代遅れ
text/javascript1.2->application/x-javascript; version=1.2非標準, 時代遅れ
text/javascript1.3->application/x-javascript; version=1.3非標準, 時代遅れ
text/javascript+json
text/x-jdoc-formatJドキュメント書式
text/x-jquery-tmpl
text/x-js
text/json
text/x-json
text/x-jsrender
text/jss
text/jsss
text/jsx
text/x-julia
text/typescript-jsx
text/kendo-tmpl
text/x-kom-basic
text/x-kshksh shell script非推奨
text/vnd.latex-z[IANAREG]
text/ldif
text/less
text/x-less
text/x-libtool
text/livescript
text/x-livescript
text/x-literate-haskell
text/x-lua
text/x-lua-source
text/x-mail
text/x-makefileMakefile非推奨[Gnome], [WING]
text/markdown
text/x-markdown
text/x-mathjax-config
text/x-mathematica
text/mathml
text/x-matlab
text/x-mbl
text/mdl
text/vnd.ms-mediapackage
text/x-meson
text/x-message-pem
text/x-message-rfc934
text/x-message-rfc1153
text/mirc
text/x-mmlMML[Vodafone]
text/x-moc
text/x-modelica
text/vnd.motorola.reflex
text/mp4
text/mpml-basic-layout
text/x-mscgen
text/x-msgenny
text/x-msil
text/x-mssql
text/mustache
text/x-mysql
text/x-mariadb
text/n3
text/x-nemerle
text/x-netrexx
text/vnd.iptc.newsml
text/nginx
text/x-nreum-data
text/x-nsis
text/ng-template
text/n-triples
text/ntriples
text/x-nquads
text/vnd.iptc.nitf
text/x-objcsrc
text/x-objectivec
text/x-objective-j
text/x-ocaml
text/x-ocl
text/x-octave
text/x-oeb1-css
text/x-oeb1-document
text/ofx
text/oobhtml
text/x-opml
text/os-dataOpenSocial データ非標準, IANA 登録OpenSocial
text/os-templateOpenSocial 雛形非標準, IANA 登録OpenSocial
text/owl-manchester
text/x-oz
text/x-packed-dat
text/x-pascalPASCAL source非推奨[WING]
text/parityfec[IANAREG], RFC 3009
text/x-patchdiff非推奨 ->application/x-patch
text/perlPerlスクリプト非標準
text/x-perlPerl scripttext/perlXHTML 2.0 例, [Gnome], [WING]
text/perlscriptPerlScript非標準 ->text/x-perlSee スクリプトの媒体型 (>>20)
text/x-perl-scriptPerl
text/x-pgp-cleartext-signedPGPメッセージ交換形式 (クリア署名) message body
text/php
text/x-php
text/x-php-script
text/x-php-sourcePHP source非推奨[WING]
text/x-pig
text/x-plsql
text/x-pkg-config
text/x-pgsql
text/x-moz-place
text/x-moz-place-container
text/x-placeholder
text/plain平文[IANAREG], [MIME], RFC 3679
text/x-plsqlPLSQL source非推奨[WING]
text/x-pmaildxオープンネットコンテンツ
text/x-poPO
text/x-pot
text/x-pox
text/pod
text/part-handler
text/x-prolog
text/x-properties
text/x-protobuf
text/pson
text/x-psp
text/x-pug
text/x-puppet
text/python
text/x-pythonPython script非推奨[Gnome], [WING]
text/x-python-script
text/x-q
text/qif
text/x-qif
text/x-r
text/x-rcDOS RC file非推奨[WING]
text/rdfRDF/XML非標準 ->application/rdf+xml[Mozilla]
text/rdf+n3N3W3C チーム提出物N3
text/rdf+turtle
text/x-readmeREADME[Gnome]
text/vnd.rn-realtext(*.rt)非標準[Real]
text/vnd.rn-realtext3d(*.r3t)非標準[Real]
text/redIETF 提案標準, IANA 登録済RFC 4102, [IANAREG]
text/x-regexp-jsJavaScript 正規表現
text/x-request-mfr
text/microsoft-resx
text/x-reject
text/rfc822
text/rfc822-headers
text/richtext
text/rocketscript
text/x-rpm-spec
text/x-rpm-changes
text/x-rst
text/ruby
text/x-ruby
text/x-www-ruleslibwww
text/prs.fallenstein.rst
text/x-rsrc
text/rtf
text/rtx
text/x-roff[Namazu]
text/rubyscriptActiveRubyScript非標準 (See スクリプトの媒体型 (>>10))[ActiveRubyScript]
text/ruby-script
text/rust
text/x-rustsrc
text/x-sas
text/x-sass
text/x-scala
text/x-schemeScheme script非推奨[Gnome]
text/script
text/x-script-element-contentscript 要素内容
text/x-script-element-text
text/x-script-inline-documentation
text/x-script.perl
text/x-script.perl-module
text/x-script.python
text/x-script.ruby
text/scriptletScriptlet非標準[M$], See スクリプトの媒体型 (>>23)
text/x-scriptletScriptlet非推奨(See スクリプトの媒体型 (>>23))
text/x-scss
text/x-moz-search-engine
text/x-serialization
text/x-server-parsed-html
text/x-server-parsed-html3
text/x-setextStructure Enhanced Text[APACHE], [Gnome]
text/sgmlSGML 解析対象実体[IANAREG], RFC 1874
text/x-sgmlSGML 解析対象実体時代遅れ ->text/sgml
text/x-shsh script非推奨[Gnome]
text/x-shellscript
text/site
text/sitemap
text/x-smarty
text/smil-basic-layoutSMIL Basic Layout Language非標準, 非推奨[SMIL 1.0]
text/sms
text/x-solr
text/x-soy
text/x-speech発話合成データ (MVP Solutions)
text/spice
text/vnd.in3d.spot[IANAREG]
text/spreadsheetSpreadsheet interchange非標準[Gnome]
text/x-spreadsheet
text/x-sqlSQL source非推奨[Gnome], [WING]
text/x-squirrel
text/x-srt
text/x-ssa
text/x-stex
text/strings
text/x-stsrc
text/x-styl
text/stylesheet
text/dvb.subtitle非標準[MHP 1.1]
text/x-suikawiki
text/x-swift
text/x-syn
text/x-systemverilog
text/t140
text/tab-separated-values
text/prs.lines.tag
text/tcl
text/x-tclTcl script非推奨[Gnome]
text/dvb.teletext非標準[MHP 1.1]
text/x-tmpl
text/template
text/teon
text/x-texTeX source[Gnome]
text/x-texinfoTexinfo source[Gnome]
text/x-moz-text-internal
text/x-textile
text/x-tiddlywiki
text/tiscriptTerra Informatica Script非標準, IANA 登録
text/x-toml
text/x-tornado
text/x-trac-wiki
text/troff
text/x-trofftroff source[Gnome]
text/x-troff-manman page[Gnome]
text/x-troff-me[Gnome]
text/x-troff-mm[Gnome]
text/x-troff-ms[Gnome]
text/tsv
text/x-ttcn-asn
text/t-timeT-Time スタイル・シート非標準, 非推奨
text/x-ttcn
text/x-ttcn3
text/x-ttcnpp
text/x-ttcn-cfg
text/x-ttml[WAP]
text/turtle
text/typescript
text/x-underscore-template
text/unicode
text/upstart-job
text/uri-list
text/url-list
text/x-moz-url
text/x-moz-url-data
text/x-moz-url-desc
text/x-moz-url-priv
text/url
text/x-url
text/x-url-shortcutInternet Shortcut
text/dvb.utf8Java 修正 UTF-8非標準[MHP 1.1]
text/x-uuencodeuuencode非推奨 ->Content-Transfer-Encoding: x-uuencode など
text/x-vala
text/x-vbVB source非推奨
text/x-vbnet
text/x-vb-sourceVB source非推奨[WING]
text/vbs
text/vbscript
text/x-vbscript
text/x-vbookmarkvBookmark[Vodafone]
text/x-vcalendar
text/vcalendar
text/vcard
text/x-vcardGnome, Chrome
text/x-vcardvCard[Gnome]
text/x-vcf
text/vcsswg
text/velocity
text/x-verilog
text/x-verilog-src
text/x-vertex
text/x-vhdl
text/x-yacc
text/x-vmessagevMessage[Vodafone]
text/x-vnotevNote[Vodafone]
text/vnd.viewcvs-markup(ViewCVS 内部用)非標準, 非推奨
text/x-vmel[WAP]
text/vtt
text/x-vue
text/vnd.wap.si[IANAREG]
text/vnd.wap.sl[IANAREG]
text/wmlWML 文書非推奨 ->text/vnd.wap.wml
text/vnd.wap.wmlWML 文書[IANAREG] text/vnd.wap.wml; type=4365
text/x-wap.wmlWML 文書非推奨 ->text/vnd.wap.wml]]
text/vnd.wap.wmlscript[IANAREG]
text/x-wap-wta-wml[WAP]
text/x-webidl
text/webviewhtml
text/x-web-intelligent
text/wiki
text/x-wiki
text/x.wiki
text/vnd.ms-word
text/vnd.wordperfect
text/wreq
text/xaml
text/x-xu
text/x-xetext
text/xhtml
text/xhtml+xml
text/xml
text/x-xmlXML 実体非推奨 ->application/xml[WING]
text/xml-contentXML 内容非標準 =>application/xml-external-parsed-entity など
text/xml-dtd
text/xml-external-parsed-entity
text/xml+oembed
text/xml-script
text/xmlp+xmlXML Protocol非標準
text/xml-soapSOAP非標準I-D draft-box-http-soap
text/xmms-playlistXMMS Playlist (*.m3u)非標準 ->audio/x-mpegurl
text/xslXSL スタイル・シート非標準 ->application/xslt+xml[W3C], [MS]
text/xslfo
text/xul
text/x-yacas
text/yaml
text/x-yaml
text/x-z80

意味

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

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

[23] バイナリーデータを埋め込む形式は、直接読めるとはみなしません >>22

引数

[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] MIMEtext/* では、 CRLF改行を表さなければなりませんCRLF をそれ以外で使ってはいけません。 >>24

[27] これは改行をどう表現しなければならないかの制約であり、 どう表示するか (どこで新しい行に進むか) の制約では無い >>24 ようです。

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

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

[82] これらの HTTP における規定が、どれだけ実態にあったものなのかは疑問です。 例えば text/html については改行として CRLFCRLF のいずれも認められていますが、 >>78>>80 に基づき認められるというよりは、 HTML Standard により直接的に認められていると考えるべきでしょう。 その他の MIME型も、それぞれが構文や構文解析方法を定義していて、 厳密にはそれらの解釈は等しくありません。

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

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

[85] もっとも、 RTSP や SIP では text/* なんてそんな使わないかな。

[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] HTTPMIME関門で変換が発生すると検査和が壊れてしまいますから、 HTTP であっても検査和を使う場合には正準形推奨 (recommended) されています >>11

テキストと text/*

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

処理

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

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

[30] この規定は一部の MUA しか従っていないようです。一部の MUA は未知のものをすべて application/octet-stream のように扱うようです。 また Web では text/plain として扱われるものとそうでないものがあります (テキストファイル参照)。
[31] この規定の通りに実装されていたなら、 text/plain; format=flowed引数ではなく新しい MIME型になっていたはずです。

歴史

[61] RFC 2046 4.1. Text Media Type

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.

[2] "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" の亜型を使って表現するべきです。

4.1.1. Representation of Line Breaks 改行の表現

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 シーケンスなしの長過ぎる部分を含むデータは適切な内容転送符号化で符号化しなければなりません。

4.1.2. Charset Parameter Charset パラメーター

See charsetパラメーター

4.1.3. Plain Subtype Plain 亜型

   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" 亜型はこの文書では定義しません。

4.1.4. Unrecognized Subtypes

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" として扱います。

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

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

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

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

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

[57] >>56

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

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

[58] >>56, 57

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

[86] RFC 1945 (HTTP/1.0) 3.6.1; RFC 2068・2616 (HTTP/1.1) 3.7.1 Canonicalization and Text Defaults

Internet media types are registered with a canonical form. {1945,2068} In general, an {2616} An Entity-Body entity-body transferred via HTTP messages must MUST be represented in the appropriate canonical form prior to its transmission ; the exception is except for "text" types, as defined in the next paragraph.

Internet 媒体型は正規形とともに登録されます。 HTTP メッセージで転送される実体本文は、次の段落で定義する "text" 型を除いては、転送の前に適切な正規形で表現しなければなりません

When in canonical form, media Media subtypes of the "text" type use CRLF as the text line break when in canonical form. HTTP relaxes this requirement and allows the transport of text media with plain CR or LF alone representing a line break when used it is done consistently within the Entity-Body for an entire entity-body. HTTP applications must MUST accept CRLF, bare CR, and bare LF as being representative of a line break in text media received via HTTP. In addition, if the text media is 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 the Entity-Body entity-body; a bare CR or LF should not MUST 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 been an entity-body is encoded with a {1945,2068} Content-Encoding {2616} content-coding, the underlying data should MUST be in canonical form a form defined above prior to being encoded.

実体本文が内容符号化で符号化されている時は、中のデータは 符号化の前に上に定義した形にしておかなければなりません

The "charset" parameter is used with some media types to define the character set (Section section 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 subsets must MUST be labelled with an appropriate charset value in 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 を参照。

[87] RFC 1945 (HTTP/1.0) C.1; RFC 2068 (HTTP/1.1) 19.4.1; RFC 2616 (HTTP/1.1) 19.4.2 Conversion to Canonical Form

RFC 1521 MIME RFC 2045 [7] requires that an Internet mail entity be converted to canonical form prior to being transferred, {1945} as described in Appendix G of RFC 1521 [5] , {2616} as described in section 4 of RFC 2049 [48] . Section {1945} 3.6.1 3.7.1 of this document describes the forms allowed for subtypes of the "text" media type when transmitted over HTTP. MIME RFC 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改行を表現することを要求し、改行シーケンス以外で CRLF を使うことを禁止しています。 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-Typetext の内容が改行CRLF で表現することを要求し、 改行列以外での CRLF の使用を禁止しています。 HTTP は、メッセージが HTTP 上を転送されるに際して文内容中の改行を示すために CRLF, 単独の CR および単独の LF を認めています。

Where it is possible, a proxy or gateway from HTTP to a strict RFC 1521 MIME environment should SHOULD translate all line breaks within the text media types described in Section 3.6.1 section 3.7.1 of this document to the RFC 1521 MIME RFC 2049 canonical form of CRLF. Note, however, that this may {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 が幾つかの多バイト文字集合の場合のようにオクテット 1310 を 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 もの。

メモ

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

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

[60] W3C TPAC: decoding text/css — Anne’s Blog ( ( 版)) <http://annevankesteren.nl/2012/11/decoding-css>

[20] RFC 4708 - CellML Media Type ( 版) <https://tools.ietf.org/html/rfc4708>

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.

[33] RFC 5323 - Web Distributed Authoring and Versioning (WebDAV) SEARCH () <https://tools.ietf.org/html/rfc5323#section-2.2.2>

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.