[26] 存在が知られている媒体型: ,媒体型/亜型 ,説明 ,状態 ,出典 ,[CODE(MIME)[[[x-application/*]]]] ,->[CODE(MIME)[application/[VAR[*]]]] ,非推奨 ,[[application/*]] ,応用一般 ,[MIME] ,[CODE(MIME)@en[[[zz-application/zz-winassoc-tgz]]]] , ,"非標準, [[IANA]] ''未''登録" ,[[audio/*]] ,音声 ,[MIME] ,[[auth/sicily]] ,認証? ,"非標準, [[FrontPage]]" ,[CODE(MIME)@en[[[binary/octet-stream]]]] ,[[オクテット列]] ,"非標準, [[IANA]] ''未''登録 → [CODE(MIME)@en[[[application/octet-stream]]]]" ,[[chemical/*]] , ,非標準 ,[[coloreal/embedded]] , ,非標準 ,[[x-conference/x-cooltalk]] ,[[CoolTalk]] ,[Netscape] ,[CODE(MIME)[[[x-data/xact-error]]]] ,[[database/x-unknown]] , ,非標準 ,[CODE(MIME)@en[[[dsmcc-[VAR[*]]/[VAR[*]]]]]] , ,"[[規格]], [[IANA]] ''未''登録" ,[CODE(MIME)@en[[[dsmcc-download/jpeg]]]] , ,"[[規格]], [[IANA]] ''未''登録" ,[CODE(MIME)@en[[[dsmcc-file/mpeg2-ps]]]] , ,"[[規格]], [[IANA]] ''未''登録" ,[CODE(MIME)@en[[[dsmcc-file/html]]]] , ,"[[規格]], [[IANA]] ''未''登録" ,[CODE(MIME)@en[[[dsmcc-stream/mpeg2-ts]]]] , ,"[[規格]], [[IANA]] ''未''登録" ,[[x-device/floppy]] ,[[FD]] ,[GNOME] ,[CODE(MIME)[[[x-directory/normal]]]] ,[CODE(MIME)[[[drawing/x-dwf]]]] ,[[DWF]] ,非標準 ,[CODE(MIME)@en[[[example/[VAR[*]]]]]] ,[[例]] ,"[[IETF]] [[提案標準]], [[IANA]] 登録済" ,[[x-ferrum-head/*]] ,[[x-ferrum-menu/*]] ,[CODE(MIME)[[[font/[VAR[*]]]]]] ,[[フォント]] ,非標準 → [CODE(MIME)[[[application/[VAR[*]]]]]] ,[CODE(MIME)[[[x-form/x-openscape]]]] ,[CODE(MIME)@en[[[gadget/x-googlegadget]]]],,"非標準, [[IANA]] ''未''登録" ,[CODE(MIME)[[[graphics/x-inventor]]]] ,Open Inventor 3次元 scenes ,非標準 ,[[image/*]] ,画像 ,[MIME] ,[CODE(MIME)@en[[[inode/[VAR[*]]]]]] ,[[ファイル・システム]][[物体]] ,"非標準, [[IANA]] ''未''登録" ,[freedesktop.org] ,[[interface/x-winamp-skin]] ,[[winamp]] [[skin]] ,非標準 ,[CODE(MIME)[[[x-jigsaw/config]]]] ,[CODE(MIME)[[[x-kom/basic]]]] ,->[CODE(MIME)[[[text/x-kom-basic]]]] ,非推奨 ,[CODE(MIME)[[[x-lml/x-lml]]]] ,[[matter-transport/*]] ,物質転送 ,[RFC1437] ,[[message/*]] ,メッセージ ,[MIME] ,[[mforge/x-mirage]] , ,非標準 ,[[midi/mid]] ,[[MIDI]] ,非標準 ,[CODE(MIME)[[[misc/ultravox]]]] , ,非標準 , ,[[model/*]] ,三次元空間 ,[RFC2077] ,[CODE(MIME)[[[x-model/x-mesh]]]] , ,時代遅れ ,[[mozilla.application/cached-xul]] ,[[XUL]] [[cache]] ,[Mozilla] ,[[multipart/*]] ,多部分メッセージ ,[MIME] ,[CODE(MIME)[[[x-wap.multipart/vnd.uplanet.header-set]]]] , ,[WAP] ,[CODE(MIME)[[[x-music/x-midi]]]] ,[[MIDI]] ([[SMF]]) ,非推奨 ->[CODE(MIME)[[[audio/x-midi]]]] , ,[[plugin/*]] , ,非標準 ,[CODE(MIME)[[[x-pmaildx/x-mmctrl]]]] ,[[x-postpet/*]] ,PostPet ,[CODE(MIME)[[[x-script/x-wfxscript]]]] ,[CODE(MIME)[[[x-squid-internal/vary]]]] ,[CODE(MIME)[[[x-system/x-error]]]] , ,[Namazu] ,[[text/*]] ,文 ,[MIME] ,[CODE(MIME)[[[x-text-pc/ms-word]]]] ,[CODE(MIME)@en[[[unknown/unknown]]]] , ,非標準 → [CODE(MIME)@en[[[application/octet-stream]]]] ,[[HTML 5]] ,[CODE(MIME)[[[x-unknown/octet-stream]]]] ,[CODE(MIME)[[[x-unknown/x-unknown]]]] ,[[vector/*]] ,vector 画像 ->[CODE(MIME)[image/[VAR[*]]]] ,非標準 ,[[video/*]] ,動画 ,[MIME] ,[[videotex/vemmi]] , ,非標準 ,[CODE(MIME)[[[x-visa-ii/x-auth]]]] ,[[windows/*]] , ,非標準 ,[CODE(MIME)[[[workbook/formulaone]]]] , ,非標準 ,[[i-world/i-vrml]] ,->[CODE(MIME)[[[model/vrml]]]] ,非標準 ,[[x-world/*]] ,->[CODE[model/[VAR[*]]]] ,非推奨 ,[CODE(MIME)@en[[[www/mime]]]] ,[[MIME]] ,"非標準, 廃止 →[CODE(MIME)@en[[[message/rfc822]]]]" ,[[libwww]] ,[CODE(MIME)@en[[[www/unknown]]]] ,未知 (自動判別) ,非標準 ,[[libwww]] ,[CODE(MIME)[[[www/source]]]] , ,非標準 , ,[[xgi/*]] , ,非標準 [27] MIME の[CODE[[VAR[型]]/[VAR[亜型]]]]形式によらないもの : ,[[audio-file]] , ,非標準 ,[[x-be2]] , ,非標準 ,[[default]] , ,非標準 ,[[mail-file]] , ,非標準 ,[[postscript-file]] , ,非標準 ,[[x-sun-attachment]] , ,非標準 ,[[sun-deskset-message]] , ,非標準 - [30] [IANAREG] [[#comment]] * 大雑把な書式を表す接尾辞 [33] [[RFC 3023]] の [CODE(MIME)@en[+xml]] 以来、 [[XML]] と [[XML応用]]のような関係を示すために、 [[媒体型]]の末尾に [CODE(MIME)@en[+[VAR@ja[書式名]]]] のような[[文字列]]をつけるようになりました。 この[[接尾辞]]は、 [[RFC 3023]] で [CODE(MIME)@en[+xml]] が定義されているのと、 [[RFC 4288]] で (将来同様な規定が他の書式に対してもなされることに対して) 注意が促されている他は、明確に定義されているわけではありません。 [CODE(MIME)@en[+]] という記号がこの慣習に従わずに使われることもあります。 [29] ,[[媒体型]] ,説明 ,状態 ,出典 ,[CODE(MIME)[[[[VAR[*]]/[VAR[*]]+asn1]]]] ,[[ASN.1]] , ,[CODE(MIME)[[[[VAR[*]]/[VAR[*]]+csv]]]] ,[[CSV]] , ,[CODE(MIME)@en[[[[VAR[*]]/[VAR[*]]+fastinfoset]]]] ,[[Fast Infoset]] ,[CODE(MIME)@en[[[[VAR[*]]/[VAR[*]]+gzip]]]] ,[[GNU Zip]] ,[CODE(MIME)@en[[[[VAR[*]]/[VAR[*]]+json]]]] ,[[JSON]] ,[CODE(MIME)@en[[[[VAR[*]]/[VAR[*]]+n3]]]] ,[[N3]] ,[CODE(MIME)@en[[[[VAR[*]]/[VAR[*]]+ogg]]]] ,[[Ogg]] container format ,[CODE(MIME)@en[[[[VAR[*]]/[VAR[*]]+rcs]]]] ,[[RCS]] ,[CODE(MIME)@en[[[[VAR[*]]/[VAR[*]]+swcfg]]]] ,[[SuikaWikiConfig/2.0]] ,廃止 ,[CODE(MIME)@en[[[[VAR[*]]/[VAR[*]]+wbxml]]]] ,[[WBXML]] ,[CODE(MIME)@en[[[[VAR[*]]/[VAR[*]]+xml]]]] ,[[XML]] ,[[IETF]] [[原案標準]] ,[[RFC 3023]] ,[CODE(MIME)@en[[[[VAR[*]]/[VAR[*]]+zip]]]] ,[[Zip]] [34] [CODE(MIME)@en[[[audio/amr-wb+]]]] というのが登録されています。 [CODE(MIME)@en[[[application/xhtml+voice+xml]]]] には物言いがついたのに。 ([[名無しさん]] [WEAK[2006-07-02 03:17:54 +00:00]]) [35] ちなみに巷で使われているものにはほかに [CODE(MIME)@en[[[application/x-xhtml+voice+xml]]]] なんてのもあります。 ([[名無しさん]] [WEAK[2006-07-02 03:19:04 +00:00]]) [[#comment]] * 媒体型の命名構造 [28] RFC 2045 では媒体型は型 type と亜型 subtype を "/" で組み合わせたものと 定義されています。例: text/plain RFC 2048 は亜型に木 tree 構造を導入しました。木は枝を "." で組み合わせて 作ります。例: vnd.bigcompany.funnypictures RFC 3023 は XML の媒体型には亜型の最後に "+xml" をつけることを推奨しています。 また、あまり喜ばしくないとしながらも、将来同様のメタ型を使う時にも "+ebml" とか "+ebml+xml" とかすることを提案しています。 = media-type = type "/" subtype = type = discrete-type / composite-type = discrete-type = "text" / "image" / "audio" / "video" / "application" / extension-token = composite-type = "message" / "multipart" / extension-token = extension-token = ietf-token / x-token = subtype = ( ietf-tree / vendor-tree / personal-tree / x-tree / extension-tree / x-token ) = ietf-tree = branch meta-format = vendor-tree = "vnd." branch *("." branck) meta-format = personal-tree = "prs." branch *("." branck) meta-format = x-tree = "x." branch *("." branck) meta-format = extension-tree = branch *("." branch) meta-format = branch = 1*ttext = meta-format = *("+" format) = format = "xml" / extension-format = extension-format = 1*( ttext / "." ) = ttext = ALPHA / DIGIT / "!" / "#" / "$" / "%" / "&" / "'" / "*" / "-" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~" [[#comment]] * 仕様書 - RFC 1341 (廃止) - RFC 1437 matter-transport/* 媒体型 - RFC 1521 (廃止) - RFC 1590 媒体型登録手続き (廃止・・されてない) - RFC 2046 媒体型 - RFC 2048 - RFC 2077 model/* 媒体型 - RFC 2376 XML 媒体型 (廃止) - RFC 3023 XML 媒体型 - IANA 登録簿 [[#comment]] ** RFC 2046 2. Definition of a Top-Level Media Type The definition of a top-level media type consists of: 上位媒体型の定義は次のものから構成されます。 [PRE[ (1) a name and a description of the type, including criteria for whether a particular type would qualify under that type, ]PRE] (1) 型の名前と説明。特定の型をその型の下に置けるかどうかの適合基準 [PRE[ (2) the names and definitions of parameters, if any, which are defined for all subtypes of that type (including whether such parameters are required or optional), ]PRE] (2) その型のすべての亜型用に定義するパラメーターがあればその名前と定義 (そのパラメーターが必須か省略可能かを含む) [PRE[ (3) how a user agent and/or gateway should handle unknown subtypes of this type, ]PRE] (3) 利用者代理者や関門がその型の未知の亜型をどう取り扱うべきか [PRE[ (4) general considerations on gatewaying entities of this top-level type, if any, and ]PRE] (4) 必要なら、この上位型の実体の関門通過に関しての考慮一般 [PRE[ (5) any restrictions on content-transfer-encodings for entities of this top-level type. ]PRE] (5) この上位型の実体の内容転送符号化の制限 ** RFC 2046 3. Overview Of The Initial Top-Level Media Types The five discrete top-level media types are: 5つの個々上位媒体型は次の通りです。 [PRE[ (1) text -- textual information. The subtype "plain" in particular indicates plain text containing no formatting commands or directives of any sort. Plain text is intended to be displayed "as-is". No special software is required to get the full meaning of the text, aside from support for the indicated character set. Other subtypes are to be used for enriched text in forms where application software may enhance the appearance of the text, but such software must not be required in order to get the general idea of the content. Possible subtypes of "text" thus include any word processor format that can be read without resorting to software that understands the format. In particular, formats that employ embeddded binary formatting information are not considered directly readable. A very simple and portable subtype, "richtext", was defined in RFC 1341, with a further revision in RFC 1896 under the name "enriched". ]PRE] (1) text ―― 文字情報。亜型 "plain" は特に、いかなる類の書式化命令・指令 を含まない平文 (plain-text) を示します。平文は「そのまま」表示する ことを意味します。文の完全な意味を得るのに、指定された文字集合への対応を 除いて特別なソフトウェアは必要ありません。他の亜型は応用ソフトウェアが 文の見た目をよくする裕福文に使われるかもしれませんが、内容の 一般的な着想を得るのにはこのようなソフトウェアは必須ではありません。 ですから "text" の亜型となりえるものにはその形式を理解するソフトウェア 無しに読むことが出来る言葉処理器 (ワード・プロセッサー) の形式を含みます。 特に、バイナリ書式付け情報を埋め込んだ形式は直接可読とは言えません。 とても単純で移植性ある亜型, "richtext" (裕福文) は RFC 1341 で定義されていましたが、 RFC 1896 で "enriched" (裕福化) という名前で 更に改訂されています。 訳注: embeddded は d が一個多い。 [PRE[ (2) image -- image data. "Image" requires a display device (such as a graphical display, a graphics printer, or a FAX machine) to view the information. An initial subtype is defined for the widely-used image format JPEG. . subtypes are defined for two widely-used image formats, jpeg and gif. ]PRE] (2) image ――画像データ。 "image" は情報を見るのに表示機器 (画像画面, 画像印刷機, FAX 機器など) が必要です。初期亜型としては 広く使われている画像形式 JPEG を定義します。。 亜型としては 2つの広く使われている画像形式, jpeg と gif を定義します。 (訳注: 誤植というか編集ミスというか。) [PRE[ (3) audio -- audio data. "Audio" requires an audio output device (such as a speaker or a telephone) to "display" the contents. An initial subtype "basic" is defined in this document. ]PRE] (3) audio ――音声データ。 "audio" は音声出力機器 (スピーカーとか電話とか) が内容を「表示」するのに必要です。初期亜型としては "basic" をこの文書で定義します。 [PRE[ (4) video -- video data. "Video" requires the capability to display moving images, typically including specialized hardware and software. An initial subtype "mpeg" is defined in this document. ]PRE] (4) video 動画データ。 "video" は動く画像を表示する能力が必要です。 典型的には特別なハードウェアとソフトウェアを含みます。 初期亜型としては "mpeg" をこの文書で定義します。 [PRE[ (5) application -- some other kind of data, typically either uninterpreted binary data or information to be processed by an application. The subtype "octet- stream" is to be used in the case of uninterpreted binary data, in which case the simplest recommended action is to offer to write the information into a file for the user. The "PostScript" subtype is also defined for the transport of PostScript material. Other expected uses for "application" include spreadsheets, data for mail-based scheduling systems, and languages for "active" (computational) messaging, and word processing formats that are not directly readable. Note that security considerations may exist for some types of application data, most notably "application/PostScript" and any form of active messaging. These issues are discussed later in this document. ]PRE] (5) appliaction 他の種類のデータ, 典型的には解釈出来ないバイナリ・データ や応用により処理される情報です。亜型 "octet-stream" は解釈出来ない バイナリ・データに使われ、この場合の最も簡単な推奨動作は情報を ファイルに書き出すと利用者に申し出ることです。 "PostScript" 亜型も PostScript 物体を転送するために定義します。他の "application" で使うべきものには表計算, 基メイル予定系統, 「動的」(計算的)メッセージの言語, 直接可読でないワード・プロセッサーの形式があります。なお、 応用データの幾つかの型, とりわけ "application/PostScript" や動的 目セージの形式には安全性について考慮すべきことがあたりします。 この問題についてはこの文書の後の方で話します。 The two composite top-level media types are: 2つの合成上位媒体型は次の通りです。 [PRE[ (1) multipart -- data consisting of multiple entities of independent data types. Four subtypes are initially defined, including the basic "mixed" subtype specifying a generic mixed set of parts, "alternative" for representing the same data in multiple formats, "parallel" for parts intended to be viewed simultaneously, and "digest" for multipart entities in which each part has a default type of "message/rfc822". ]PRE] (1) multipart 複数の独立したデータ型の実体で構成されるデータ。 4つの亜型がはじめから定義されています。 "mixed" 亜型は 一般の混成の部分の集合を示し, "alternative" は同じデータを複数の形式で 表現していることを表し, "parallel" は同時に表示されることを意図した 部分を組み合わせたもので、 "digest" は各部分の既定値が "message/rfc822" の多部分実体で構成されるものです。 [PRE[ (2) message -- an encapsulated message. A body of media type "message" is itself all or a portion of some kind of message object. Such objects may or may not in turn contain other entities. The "rfc822" subtype is used when the encapsulated content is itself an RFC 822 message. The "partial" subtype is defined for partial RFC 822 messages, to permit the fragmented transmission of bodies that are thought to be too large to be passed through transport facilities in one piece. Another subtype, "external-body", is defined for specifying large bodies by reference to an external data source. ]PRE] (2) message カプセル化メッセージ。媒体型 "message" の本文は それ自体が何らかの種類のメッセージ物体の一部又は全部です。 この物体が今度は他の実体を含むかもしれませんし、含まないかもしれません。 "rfc822" 亜型はカプセル化内容が RFC 822 メッセージである時に使います。 "partial" 亜型は RFC 822 メッセージの一部用に定義するもので、 転送機能を一片でまとめて通過させるには大き過ぎると思われる 本文を断片化して送ることが出来ます。他の亜型, "external-body" は外部データ源を使って大きな本文を示すのに定義します。 It should be noted that the list of media type values given here may be augmented in time, via the mechanisms described above, and that the set of subtypes is expected to grow substantially. 媒体型値は上述の機構でいつ増補されるかもしれませんし、 亜型の集合は本質的に増えて行くだろうことに注意して下さい。 ** RFC 2046 6. Experimental Media Type Values [PRE[ A media type value beginning with the characters "X-" is a private value, to be used by consenting systems by mutual agreement. Any format without a rigorous and public definition must be named with an "X-" prefix, and publicly specified values shall never begin with "X-". (Older versions of the widely used Andrew system use the "X-BE2" name, so new systems should probably choose a different name.) ]PRE] 文字 "X-" から始まる媒体型値は私用値で、相互の同意により同意系統で 使われます。厳密に公的に定義されていない形式は "X-" 接頭辞つきで 名前をつけなければなりませんし、公的規定値は "X-" で始めてはいけません。 (広く使われている Andrew の系統の古い版は "X-BE2" 名を使っていましたので、 新しい系統は違う名前を選ぶのがよろしいでしょう。) [PRE[ In general, the use of "X-" top-level types is strongly discouraged. Implementors should invent subtypes of the existing types whenever possible. In many cases, a subtype of "application" will be more appropriate than a new top-level type. ]PRE] 通常、 "X-" を上位型に使うのは強く非推奨です。実装者は出来る限り 既存の型の亜型をでっち上げるべきです。多くの場合、 "application" の亜型にするのが新しい上位型にするのより適切です。 ** HTTP および派生プロトコルでの扱い →[CODE(WikiPage)[[[.//HTTP]]]] ** RFC の部分の License See [[RFCのライセンス]] * 実装 [32] [CITE[freedesktop.org - Standards/shared-mime-info-spec]] [[#comment]] * メモ - [13] >>12 禁止ではないわけだ。 実際 HTTP な世界では登録簿に無い媒体型が結構良く使われてます。 - [14] >>13 もしかしてこの注は解釈が間違ってる? 確かに未登録は非推奨とは言ってるけど、 "x-" なしのを未登録でとは言ってないな。 非推奨している「未登録媒体型」は x-媒体型のことを指してるのかもしれん。 - [16] [WEAK[2002-12-29 21:16]] ''[[名無しさん]]'': ''CVS log for gnue/gnue/common/src/GMimeTypes.py'' - [18] [[RFC1927]] Suggested Additional MIME Types for Associating Documents も幾つかの型を提案しています。 - [19] ''How to Register a Media Type with IANA (for the IETF tree)'' [[W3C]] の規格で使う媒体型を登録するための手引き。なお、 W3C の媒体型も ietf-tree に登録されます。 - [20] ''Appendix A: MIME Type Detection in Internet Explorer'' : [[M$]] の [[HTTP]] における媒体型のへたれ実装について。 - [22] [[Windoze]] では[[拡張子]]と媒体型の関連付けは、 [CODE(reg)[[[HKCR]]\.[VAR[拡張子]]\"Content Type"([[REG_SZ]])]] に値を設定することで行えます。 - [23] [[Win98]]/[[WinNT4.0]] まででは、 [[explorer]] のフォルダの設定画面の[CODE[ファイル タイプ]][[タブ]]から設定できましたが、 [[WinMe]] から初心者?にやさしい(つもりの)設定画面に変わって、媒体型の編集はまったくできなくなりました。 - [24] >>23 初心者が関連付けの設定なんかいじるのか謎ですがね。というかそもそも初心者がいじらないといけないような設計が間違ってるのであって。 - [25] [WEAK[2003-10-26 01:43:11 +00:00]] ''[[名無しさん]]'': '''' ''' [31] [CITE[A question on Media Type Registrations]] 非 [[MIME]] 型プロトコル (具体的には [[RTP]]) で媒体型を使いたいけど [[MIME]] のしがらみがうざいというのが最近 [[ietf-types]] 等々で議論になってます。 ([[名無しさん]] [sage] [WEAK[2005-06-09 00:47:27 +00:00]]) [36] [[RFC 2046]] の6章の > Any format without a rigorous and public definition must be named with an "X-" prefix, and publicly specified values shall never begin with "X-". この規定(?)に従うと、 [[RFC 2046]] で定義されている[[媒体型]]はみんな [CODE(MIME)@en[[[X-]]]] ではじめなければならなくなってしまうw ([[名無しさん]]) [37] >>36 ところが [CODE(MIME)@en[[[X-]]]] にしてしまうと後者の要件に違反してしまうw ([[名無しさん]])