メディアタイプ

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

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

メディア型は、最上位メディア型^[1] (英: top level media type)と（メディア）下位型 (英: sub-type)^[1]、そして非必須のパラメーターの組み合わせで構成される。

たとえば、とある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などは、未知のsubtypeについてapplication/octet-streamとして扱うよう規定している。

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

text

テキスト情報。特にplainメディア下位型はどんな種類の指令（例えば「文字の大きさを変更する」とか「動画を埋め込む」とか）も含まないプレーンテキストを表す。

image

画像情報。その内容は画像処理機（典型的には表示装置・印刷機など）を介して提示される。

audio

音声情報。その内容は音声出力機器（スピーカー）を介して提示される。

video

映像情報。その内容は映像を処理する機構を介して提示される。

application

典型的には、専用のアプリケーションを用いて処理される情報。

model

3次元コンピュータグラフィックスなどのモデルデータ。RFC 2011で新設。

font

フォント。RFC 8081で新設。

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

multipart

複数の独立したデータ型から成る情報。

message

カプセル化されたメッセージ。

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

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

• 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^[9])。

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

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

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

例: application/xhtml+xml、image/png

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

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

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

構文:

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

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

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

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

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

• 当初、RFC 1590とRFC 1521では、"x-"で始まるサブタイプを登録不要・私的利用としていた。
• RFC 2048では、極めて稀な場合として、必要に応じて、私的利用・実験的な用途で"x-"と"."で始まる名前を使用して良いが、なるべく避けるべきとしていた。
  • 文字“x-”で始まるメディア下位型は実験メディア型と呼ばれる^[1]。
• RFC 6838では、私的利用に"x."ツリーが用意されているが、使用は極めて避けるべきとされている。また、"x-"で始まる下位型は登録不要・私的利用ではないこととなった。

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

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

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

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

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

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

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

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

ウィキデータにはメディアタイプのプロパティであるメディアタイプがあります。（ 使用状況）

• Multipurpose Internet Mail Extensions

• IANA Media Types
• IANA Structured Syntax Suffix Registry
• RFC 2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
• RFC 6838 Media Type Specifications and Registration Procedures
• MIME Sniffing Standard
  • MIME Sniffing （日本語訳）

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

• mime.types (Apache HTTPサーバー)
• mime.types (ソースコードリポジトリ: Debian / Media Types · GitLab)
• mime.types (ソースコードリポジトリ: Fedora Paguremailcap)
• freedesktop.org.xml.in (ソースコードリポジトリ: freedesktop.org GitLab shared-mime-info)
• file/magic/Magdir at master · file/file · GitHub (file)
• mime-types-data/types (ソースコードリポジトリ: mime-types-data - GitHub)
• tika-mimetypes.xml (ソースコードリポジトリ: tika - GitHub)