PROFILPELAJAR.COM

メディアタイプ（英: media type(s)）は、ファイルやインターネット上で転送されるデータ（コンテンツ）の形式を識別するためのコード体系である^[1]。MIMEタイプやコンテンツタイプ^[2]（コンテントタイプ、content type）とも表記される。その具体的な識別子は、text/plainのように、スラッシュで区切る表記が特徴的である。

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

RFC 2046やRFC 6838など、メディアタイプに関するRFCが複数存在するほか、WHATWGのMIME Sniffing Standardの「4 MIME types」にもメディアタイプ（MIMEタイプ）に関する規定が存在する。

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

日本語では「メディア種別」とも訳される^[6]が、定訳はなく、「メディアタイプ」という外来語カナ表記がそのまま使われることも多い。本記事では「メディアタイプ」で統一するものとする。

名称について

RFC 1341では、コンテンツタイプの値 (Content-Type Values) またはMIMEタイプ (MIME type) と表記されている。その後、RFC 1590でメディアタイプの名称が定められた^[7]。一部のRFCではインターネットメディアタイプ (Internet Media Type) と表記する事例もある。

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

命名規則

メディアタイプは、トップレベルメディアタイプ (英: top-level media type、最上位メディア型^[5]）と（メディア）サブタイプ（英: subtype / sub-type、下位型^[5]）、そして非必須のパラメーターの組み合わせで構成される。

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

サブタイプは「ツリー」または「ファセット」と呼ばれるさらなる分類がなされる。

構文:

トップレベルメディアタイプ名 / サブタイプ名 [ ; パラメーター ]
トップレベルメディアタイプ名 / [ ツリー. ] サブタイプ名 [ +接尾辞 ] [ ; パラメーター ]

パラメーターは複数付与する場合もある。例: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes

トップレベルメディアタイプ

トップレベルメディアタイプは、全般的な大分類を表す部分である。

トップレベルメディアタイプごとに未知のサブタイプの扱いが規定されており、受信側は自分の扱えないサブタイプであっても最低限の取り扱いが可能となる。text の場合は text/plain、application/octet-stream・multipart の場合は multipart/mixed である。application・image・audio・videoなどは、未知のサブタイプについてapplication/octet-streamとして扱うよう規定している。

個別最上位メディア型

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

text: テキスト情報。特にplainメディア下位型はどんな種類の指令（例えば「文字の大きさを変更する」とか「動画を埋め込む」とか）も含まないプレーンテキストを表す。
image: 画像情報。その内容は画像処理機（典型的には表示装置・印刷機など）を介して提示される。
audio: 音声情報。その内容は音声出力機器（スピーカー）を介して提示される。
video: 映像情報。その内容は映像を処理する機構を介して提示される。
application: 典型的には、専用のアプリケーションを用いて処理される情報。
model: 3次元コンピュータグラフィックスなどのモデルデータ。RFC 2011で新設。
font: フォント。RFC 8081で新設。

複合最上位メディア型

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

multipart: 複数の独立したデータ型から成る情報。
message: カプセル化されたメッセージ。

例示用最上位メディア型

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

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

非公式な最上位メディア型としてchemicalが存在する^[9]^[10]^[11]。

主な例

インターネットなどで広く利用されているものや、標準化されているものを中心に例示する。

application/octet-stream（任意のバイナリデータ）
application/javascript
application/json
application/x-www-form-urlencoded
application/xml
application/zip
application/pdf（PDF文書）
application/xhtml+xml（XHTMLテキスト）
audio/mpeg
audio/vorbis
text/css
text/html（HTMLテキスト）
text/plain（プレーンテキスト）
image/png（PNG画像）
image/jpeg（JPEG画像）
image/gif（GIF画像）
video/mpeg（MPEG動画）
message/rfc822（Eml形式）
multipart/alternative（HTMLメールにおいて、HTMLによるメッセージと同等のプレーンテキストによるメッセージを用意する場合のように、同じ情報を異なる形式で表したマルチパート）
application/x-www-form-urlencoded（HTTPのPOSTメソッドによるフォームデータの送信）
multipart/form-data（同上、主にファイルアップロードを伴う場合）

登録ツリー

全てのメディアタイプは、IANAの登録手続きを経て登録されるべきとされる。個々のサブタイプ名はツリーに分類されて登録される。この場合、サブタイプ名に"ツリー."接頭辞が付与されたものとなる^{[注釈 1]}。現在、次のツリーが存在する: 標準、企業、個人、私的利用。これらのツリーは1996年11月のRFC 2048で最初に定義され、現在はRFC 6838に置き換えられている。ツリーによって登録の手続きに差異がある。

登録ツリーそのものの追加が必要な場合、IETFの標準化作業によって決定される (RFC 6838 3.5. Additional Registration Trees^[12])。

標準ツリー

標準ツリーに属するメディアタイプは、原則として接頭辞を持たない^{[注釈 2]}。

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

構文: type / メディアタイプ名 [+接尾辞]

例: application/xhtml+xml、image/png

ベンダーツリー

ベンダーツリーは、公開されている製品に関連するメディアタイプで用いられる。vnd.ファセットが用いられる (RFC 6838 3.2. Vendor Tree^[12])。

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

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

構文:

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

パーソナルツリー

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

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

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

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

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

当初、RFC 1590とRFC 1521では、"x-"で始まるサブタイプを登録不要・私的利用としていた。
RFC 2048では、極めて稀な場合として、必要に応じて、私的利用・実験的な用途で"x-"と"."で始まる名前を使用してよいが、なるべく避けるべきとしていた。
RFC 6838では、私的利用に"x."ツリーが用意されているが、使用は極めて避けるべきとされている。また、"x-"で始まるサブタイプは登録不要・私的利用ではないこととなった。

登録不要のメディアタイプ名を使用するのではなく、できるだけ登録されるべきとされている。このため、ベンダーツリー・パーソナルツリーへの登録手続きは簡略化されている^{[注釈 3]}。もちろん、標準化団体の標準化手順を通して、標準ツリーへの登録を申請してもよい。

広く運用されているメディアタイプ（"x-"接頭辞を持つファセットのないサブタイプ）で未登録のものについては、可能な限り適切なファセット付きのサブタイプ名で登録し直すべきとされている。それが困難な場合、メディアタイプのレビューアとIESGの承認の後、ファセットのない名称のままの登録も可能である (RFC 6838 Appendix A. Grandfathered Media Types^[12])。

ファセット付きで登録し直された例: image/x-icon → image/vnd.microsoft.icon
ファセット無しで登録し直された例: application/x-gzip → application/gzip
x-付きのまま登録された例: application/x-www-form-urlencoded^[13]

構文: type / x. メディアタイプ名 [+接尾辞]

接尾辞

接尾辞は、登録対象のメディアタイプに対して、元となるデータ形式をメディアタイプの命名に加えるものである。著名な構造を持つメディアタイプについては、IANAに登録されている適切な"+suffix"を登録時に付与すべきとされている。未登録の接尾辞は使用すべきではない。接尾辞の登録手続きもRFC 6838で定められている (RFC 6838 6. Structured Syntax Suffix Registration Procedures^[12])。

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

+xml
+json
+ber
+der
+fastinfoset
+wbxml
+zip

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

脚注

[脚注の使い方]

注釈

^ RFC 6838 3. Registration Trees and Subtype NamesよりThe following subsections define registration "trees" that are distinguished by the use of faceted names, e.g., subtype names that begin with a "tree." prefix.^[12]
^ RFC 6838 3.1. Standards TreeよりMedia types in the standards tree MUST NOT have faceted names, unless they are grandfathered in using the process described in Appendix A.^[12]
^ RFC 6838 3.4. Unregistered x. TreeよりHowever, with the simplified registration procedures described above for vendor and personal trees, it should rarely, if ever, be necessary to use unregistered types. Therefore, use of types in the "x." tree is strongly discouraged.^[12]