コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

メディアタイプ

出典: フリー百科事典『ウィキペディア(Wikipedia)』
MIME-Typeから転送)

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

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

RFC 2046RFC 6838など、メディアタイプに関するRFCが複数存在するほか、WHATWGMIME 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/plainapplication/octet-streammultipart の場合は multipart/mixed である。applicationimageaudiovideoなどは、未知のサブタイプについてapplication/octet-streamとして扱うよう規定している。

個別最上位メディア型

[編集]

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

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

複合最上位メディア型

[編集]

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

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

例示用最上位メディア型

[編集]

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

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

[編集]

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

主な例

[編集]

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

  • application/octet-stream(任意のバイナリデータ
  • application/javascript
  • application/json
  • application/x-www-form-urlencoded
  • application/xml
  • application/zip
  • application/pdfPDF文書)
  • application/xhtml+xmlXHTMLテキスト)
  • audio/mpeg
  • audio/vorbis
  • text/css
  • text/htmlHTMLテキスト)
  • text/plainプレーンテキスト
  • image/pngPNG画像)
  • image/jpegJPEG画像)
  • image/gifGIF画像)
  • video/mpegMPEG動画)
  • message/rfc822Eml形式
  • multipart/alternativeHTMLメールにおいて、HTMLによるメッセージと同等のプレーンテキストによるメッセージを用意する場合のように、同じ情報を異なる形式で表したマルチパート)
  • application/x-www-form-urlencodedHTTPの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 1590RFC 1521では、"x-"で始まるサブタイプを登録不要・私的利用としていた。
  • RFC 2048では、極めて稀な場合として、必要に応じて、私的利用・実験的な用途で"x-"と"."で始まる名前を使用してよいが、なるべく避けるべきとしていた。
  • RFC 6838では、私的利用に"x."ツリーが用意されているが、使用は極めて避けるべきとされている。また、"x-"で始まるサブタイプは登録不要・私的利用ではないこととなった。

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

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

  • ファセット付きで登録し直された例: image/x-iconimage/vnd.microsoft.icon
  • ファセット無しで登録し直された例: application/x-gzipapplication/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から定義されている。

脚注

[編集]

注釈

[編集]
  1. ^ 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]
  2. ^ 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]
  3. ^ 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]

出典

[編集]
  1. ^ MIMEタイプ(メディアタイプ)とは - IT用語辞典 e-Words
  2. ^ Content-Type(コンテンツタイプ)とは - IT用語辞典 e-Words
  3. ^ "Media Types". Hypertext Transfer Protocol -- HTTP/1.0 (英語). May 1996. sec. 3.6. doi:10.17487/RFC1945. RFC 1945
  4. ^ HTML 4.01 Specification” (1999年12月24日). 2017年2月2日閲覧。
  5. ^ a b c d e JIS X 5810-2:2008「多目的インターネットメール拡張 (MIME) ―第2部: メディア型」日本産業標準調査会経済産業省
  6. ^ MIME タイプ(IANA メディア種別) - HTTP | MDN
  7. ^ Media Type Registration Procedure (英語). March 1994. p. 1. doi:10.17487/RFC1590. RFC 1590. These types, previously called "MIME Types", are now called "Media Types".
  8. ^ MIME Sniffing Standard” (英語). WHATWG. 2017年3月26日閲覧。 “A MIME type is sometimes called an Internet media type in protocol literature, but consistently using the term MIME type avoids confusion with the use of "media type" as described in the Media Queries CSS specification.”
  9. ^ Daniel Leidert, Egon Willighagen (2007年). “The chemical-mime-data project”. 2016年10月8日時点のオリジナルよりアーカイブ。2016年4月28日閲覧。
  10. ^ Chemical MIME Home page”. 2019年5月11日閲覧。
  11. ^ S. Rzepa, Henry; Murray-Rust, Peter; J. Whitaker, Benjamin (1998-08-14). “The Application of Chemical Multipurpose Internet Mail Extensions (Chemical MIME) Internet Standards to Electronic Mail and World Wide Web Information Exchange”. Journal of Chemical Information and Modeling (American Chemical Society). doi:10.1021/ci9803233. https://pubs.acs.org/doi/10.1021/ci9803233. 
  12. ^ a b c d e f g Media Type Specifications and Registration Procedures (英語). January 2013. doi:10.17487/RFC6838. RFC 6838
  13. ^ Berjon, Robin (2014年5月14日). “application/x-www-form-urlencoded” (英語). IANA. 2017年3月26日閲覧。

関連項目

[編集]

外部リンク

[編集]

データベース

[編集]

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