メディアタイプ

メディアタイプ（，）は、ファイルやインターネット上で転送されるコンテンツの形式を表現する識別子である。MIMEタイプや要素タイプ (Content type)とも表記される。text/plainのように、スラッシュで区切る表記が特徴的である。
公式には、IANAがメディア型を管理している。現在の形式のメディア型は、RFC 1341のMIMEの仕様の一部として定義されたことに始まる。RFC 1341では、電子メールの本文や添付ファイルの種類の記述に用いている。その後、HTTPなどその他のインターネットプロトコルや、HTMLのようなファイル形式でも同様の目的に使用されるようになっていった。
RFC 2046やRFC 6838など、メディア型に関するRFCが複数存在するほか、WHATWGのMIME Sniffing Standardの4 MIME typesにもメディア型（MIMEタイプ）に関する規定が存在する。
RFC 2046の技術的内容及び構成を変更しない日本語訳が，日本産業規格JIS X 5810-2:2008「多目的インターネットメール拡張 (MIME) ―第2部: メディア型」として発行されている。
名称について.
RFC 1341では、Content-Typeの値 (Content-Type Values)またはMIMEタイプ (MIME type)と表記されている。その後、RFC 1590でメディア型の名称が定められた。一部のRFCではインターネットメディア型 (Internet Media Type)と表記する事例もある。
HTMLおよび関連する仕様では、このメディア型を指す用語としてMIMEタイプ(MIME type)を用いている。この理由は、CSSメディアクエリにおける「メディア種別」(media type)との混同を避けるためである。
命名規則.
メディア型は、最上位メディア型 ()と（メディア）下位型 ()、そして非必須のパラメーターの組み合わせで構成される。
たとえば、とあるHTMLファイルについてcodice_1というメディア型が付与されたとする。この例では、textが最上位メディア型、htmlがメディア下位型、charset=UTF-8が文字コードを表すパラメーターである。
下位型は「ツリー」または「ファセット」と呼ばれるさらなる分類がなされる。
構文: 
パラメーターは複数付与する場合もある。例: codice_4
最上位メディア型.
最上位メディア型は、全般的な大分類を表す部分である。
最上位メディア型毎に未知のメディア下位型の扱いが規定されており、受信側は自分の扱えない下位型であっても最低限の取り扱いが可能となる。codice_5 の場合は codice_6、codice_7・codice_8 の場合は codice_9 である。codice_10・codice_11・codice_12・codice_13などは、未知の"subtype"についてcodice_7として扱うよう規定している。
個別最上位メディア型.
個別の最上位メディア型は次のものが存在する。
複合最上位メディア型.
複合の最上位メディア型は次の2つである。
例示用最上位メディア型.
例示用の最上位メディア型としてexampleがRFC 4735で規定されている。
非公式な最上位メディア型.
非公式な最上位メディア型としてchemicalが存在する。
登録ツリー.
全てのメディア型は、IANAの登録手続きを経て登録されるべきとされる。個々の下位型名はツリーに分類されて登録される。この場合、下位型名に"ツリー."接頭辞が付与されたものとなる。現在、次のツリーが存在する: 標準、企業、個人、私的利用。これらのツリーは1996年11月のRFC 2048で最初に定義され、現在はRFC 6838に置き換えられている。ツリーによって登録の手続きに差異がある。
登録ツリーそのものの追加が必要な場合、IETFの標準化作業によって決定される (RFC 6838 3.5. Additional Registration Trees)。
標準ツリー.
標準ツリーに属するメディア型は、原則として接頭辞を持たない。
標準ツリーへの追加には、IESGで承認を受けたIETF仕様またはIANAが認める標準化を行う団体からの登録のいずれかが必要である。
構文: codice_36
例: application/xhtml+xml、image/png
ベンダーツリー.
ベンダーツリーは、公開されている製品に関連するメディア型で用いられる。vnd.ファセットが用いられる (RFC 6838 3.2. Vendor Tree)。
この文脈では、ベンダー（販売元）と開発元は同義である。すなわち、非営利な団体・コンソーシアムであっても、自身が開発したデータ形式についてベンダーツリーへの登録申請が可能である。
また、ベンダーツリーへの登録は、必ずしもベンダーや開発元によって申請される必要は無く、メディア型の登録を望む第三者が申請しても良い。ただしその場合でも、登録対象のタイプは、それに関するソフトウェアのベンダー・組織に属することになり、ベンダー・組織はいつでもそのタイプに対する所有権を表明できる。
構文:
パーソナルツリー.
パーソナルツリーは、実験的なタイプや商業的に頒布される製品に関係しないタイプを含む。prs.ファセットが用いられる。
構文: codice_40
未登録なものを表すx.ツリー.
"x."ツリーは、私的利用であったり外部に公開しない環境で当事者同士の積極的な合意の下での利用であったりする場合に用いられる。このツリーでの登録は受け付けられていない。
未登録で使用できるメディア型の命名規則は以下のように変遷している。
登録不要のメディア型名を使用するのではなく、できるだけ登録されるべきとされている。このため、ベンダーツリー・パーソナルツリーへの登録手続きは簡略化されている。もちろん、標準化団体の標準化手順を通して、標準ツリーへの登録を申請しても良い。
広く運用されているメディア型（"x-"接頭辞を持つファセットのないサブタイプ）で未登録のものについては、可能な限り適切なファセット付きの下位型名で登録し直すべきとされている。それが困難な場合、メディア型のレビューアとIESGの承認の後、ファセットのない名称のままの登録も可能である (RFC 6838 Appendix A. Grandfathered Media Types)。
構文: codice_47
接尾辞.
接尾辞は、登録対象のメディア型に対して、元となるデータ形式をメディア型の命名に加えるものである。著名な構造を持つメディア型については、IANAに登録されている適切な"+suffix"を登録時に付与すべきとされている。未登録の接尾辞は使用すべきではない。接尾辞の登録手続きもRFC 6838で定められている (RFC 6838 6. Structured Syntax Suffix Registration Procedures)。
RFC 6838の当初時点の接尾辞は、次のとおりである。現在登録されている接尾辞の一覧はStructured Syntax Suffix Registryを参照。
ただし、codice_48の接尾辞は、サフィックスがIANAで管理されるようになる前、2001年1月のRFC 3023から定義されている。
外部リンク.
データベース.
これらには、IANAに登録されていないメディア型も収録されている。