メディアタイプ

メディアタイプは、ファイルやインターネット上で転送されるコンテンツの形式を表現する識別子である。MIMEタイプや要素タイプ とも表記される。text/plainのように、スラッシュで区切る表記が特徴的である。

公式には、IANAがメディア型を管理している。現在の形式のメディア型は、RFC 1341のMIMEの仕様の一部として定義されたことに始まる。RFC 1341では、電子メールの本文や添付ファイルの種類の記述に用いている。その後、HTTPなどその他のインターネットプロトコルや、HTMLのようなファイル形式でも同様の目的に使用されるようになっていった。

RFC 2046やRFC 6838など、メディア型に関するRFCが複数存在するほか、WHATWGの[1]の4 MIME typesにもメディア型に関する規定が存在する。

RFC 2046の技術的内容及び構成を変更しない日本語訳が，日本産業規格JIS X 5810-2:2008「多目的インターネットメール拡張  ―第2部: メディア型」として発行されている。

1. 名称について
---------

RFC 1341では、Content-Typeの値 またはMIMEタイプ と表記されている。その後、RFC 1590でメディア型の名称が定められた。一部のRFCではインターネットメディア型 と表記する事例もある。

HTMLおよび関連する仕様では、このメディア型を指す用語としてMIMEタイプを用いている。この理由は、CSSメディアクエリにおける「メディア種別」との混同を避けるためである。

2. 命名規則
-------

メディア型は、最上位メディア型 と下位型 、そして非必須のパラメーターの組み合わせで構成される。

たとえば、とあるHTMLファイルについてtext/html; charset=UTF-8というメディア型が付与されたとする。この例では、textが最上位メディア型、htmlがメディア下位型、charset=UTF-8が文字コードを表すパラメーターである。

下位型は「ツリー」または「ファセット」と呼ばれるさらなる分類がなされる。

構文:

最上位メディア型 / 下位型 [ ; パラメーター ]
最上位メディア型 / [ ツリー. ] 下位型 [ +接尾辞 ] [ ; パラメーター ]パラメーターは複数付与する場合もある。例: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes

2.1. 最上位メディア型
-------------

最上位メディア型は、全般的な大分類を表す部分である。

最上位メディア型毎に未知のメディア下位型の扱いが規定されており、受信側は自分の扱えない下位型であっても最低限の取り扱いが可能となる。text の場合は text/plain、application/octet-stream・multipart の場合は multipart/mixed である。application・image・audio・videoなどは、未知の//subtype//についてapplication/octet-streamとして扱うよう規定している。

2.1.1. 個別最上位メディア型
-----------------

個別の最上位メディア型は次のものが存在する。

textテキスト情報。特にplain}}メディア下位型はどんな種類の指令も含まないプレーンテキストを表す。image画像情報。その内容は画像処理機を介して提示される。audio音声情報。その内容は音声出力機器を介して提示される。video映像情報。その内容は映像を処理する機構を介して提示される。application典型的には、専用のアプリケーションを用いて処理される情報。model3次元コンピュータグラフィックスなどのモデルデータ。RFC 2011で新設。fontフォント。RFC 8081で新設。

2.1.2. 複合最上位メディア型
-----------------

複合の最上位メディア型は次の2つである。

2.1.3. 例示用最上位メディア型
------------------

例示用の最上位メディア型としてexampleがRFC 4735で規定されている。

2.1.4. 非公式な最上位メディア型
-------------------

非公式な最上位メディア型としてchemicalが存在する。

2.2. 主な例
--------

application/octet-stream
application/javascript
application/json
application/x-www-form-urlencoded
application/xml
application/zip
application/pdf
application/xhtml+xml
audio/mpeg
audio/vorbis
text/css
text/html
text/plain
image/png
image/jpeg
image/gif
video/mpeg
message/rfc822
multipart/alternative
application/x-www-form-urlencoded
multipart/form-data

2.3. 登録ツリー
----------

全てのメディア型は、IANAの登録手続きを経て登録されるべきとされる。個々の下位型名はツリーに分類されて登録される。この場合、下位型名に"ツリー."接頭辞が付与されたものとなる 3. Registration Trees and Subtype Namesよりlang。現在、次のツリーが存在する: 標準、企業、個人、私的利用。これらのツリーは1996年11月のRFC 2048で最初に定義され、現在はRFC 6838に置き換えられている。ツリーによって登録の手続きに差異がある。

登録ツリーそのものの追加が必要な場合、IETFの標準化作業によって決定される 。

2.3.1. 標準ツリー
------------

標準ツリーに属するメディア型は、原則として接頭辞を持たない 3.1. Standards Treeよりlang。

標準ツリーへの追加には、IESGで承認を受けたIETF仕様またはIANAが認める標準化を行う団体からの登録のいずれかが必要である。

構文: type / メディア型 [+接尾辞]

例: application/xhtml+xml、image/png

2.3.2. ベンダーツリー
--------------

ベンダーツリーは、公開されている製品に関連するメディア型で用いられる。vnd.ファセットが用いられる 。

この文脈では、ベンダーと開発元は同義である。すなわち、非営利な団体・コンソーシアムであっても、自身が開発したデータ形式についてベンダーツリーへの登録申請が可能である。

また、ベンダーツリーへの登録は、必ずしもベンダーや開発元によって申請される必要は無く、メディア型の登録を望む第三者が申請しても良い。ただしその場合でも、登録対象のタイプは、それに関するソフトウェアのベンダー・組織に属することになり、ベンダー・組織はいつでもそのタイプに対する所有権を表明できる。

構文:

type / vnd. メディア型名 [+接尾辞] - 製作元が著名な場合
type / vnd. 製作元の名称 . メディア型名 [+接尾辞] - 製作元の名称はIANAに承認される必要がある
type / vnd. 製作元の名称 . 製品名 . メディア型名 [+接尾辞] - 製作元の名称と製品名はIANAに承認される必要がある

2.3.3. パーソナルツリー
---------------

パーソナルツリーは、実験的なタイプや商業的に頒布される製品に関係しないタイプを含む。prs.ファセットが用いられる。

構文: type / prs. メディア型名 [+接尾辞]

2.3.4. 未登録なものを表すx.ツリー
---------------------

"x."ツリーは、私的利用であったり外部に公開しない環境で当事者同士の積極的な合意の下での利用であったりする場合に用いられる。このツリーでの登録は受け付けられていない。

未登録で使用できるメディア型の命名規則は以下のように変遷している。

当初、RFC 1590とRFC 1521では、"x-"で始まるサブタイプを登録不要・私的利用としていた。
RFC 2048では、極めて稀な場合として、必要に応じて、私的利用・実験的な用途で"x-"と"."で始まる名前を使用して良いが、なるべく避けるべきとしていた。
文字“x-”で始まるメディア下位型は実験メディア型と呼ばれる。
RFC 6838では、私的利用に"x."ツリーが用意されているが、使用は極めて避けるべきとされている。また、"x-"で始まる下位型は登録不要・私的利用ではないこととなった。登録不要のメディア型名を使用するのではなく、できるだけ登録されるべきとされている。このため、ベンダーツリー・パーソナルツリーへの登録手続きは簡略化されている 3.4. Unregistered x. Treeよりlang。もちろん、標準化団体の標準化手順を通して、標準ツリーへの登録を申請しても良い。

広く運用されているメディア型で未登録のものについては、可能な限り適切なファセット付きの下位型名で登録し直すべきとされている。それが困難な場合、メディア型のレビューアとIESGの承認の後、ファセットのない名称のままの登録も可能である 。

ファセット付きで登録し直された例: image/x-icon → image/vnd.microsoft.icon
ファセット無しで登録し直された例: application/x-gzip → application/gzip
x-付きのまま登録された例: application/x-www-form-urlencoded構文: type / x. メディア型名 [+接尾辞]

2.4. 接尾辞
--------

接尾辞は、登録対象のメディア型に対して、元となるデータ形式をメディア型の命名に加えるものである。著名な構造を持つメディア型については、IANAに登録されている適切な"+suffix"を登録時に付与すべきとされている。未登録の接尾辞は使用すべきではない。接尾辞の登録手続きもで定められている 。

RFC 6838の当初時点の接尾辞は、次のとおりである。現在登録されている接尾辞の一覧は[2]を参照。

+xml
+json
+ber
+der
+fastinfoset
+wbxml
+zipただし、+xmlの接尾辞は、サフィックスがIANAで管理されるようになる前、2001年1月のRFC 3023から定義されている。

3. 脚注
-----

3.1. 注釈
-------

3.2. 出典
-------

4. 関連項目
-------

Multipurpose Internet Mail Extensions

5. 外部リンク
--------

[3]
[4]
2046}} Multipurpose Internet Mail Extensions  Part Two: Media Types
6838}} Media Type Specifications and Registration Procedures
[5]
[6]

5.1. データベース
-----------

これらには、IANAに登録されていないメディア型も収録されている。

[7] 
[8] 
[10] 
[12] 
[14]