type

MIME 型

[45] MIME型 (MIME type) は、ファイルの種別を表す短い識別子です。 大分類と小分類を text/plain のように斜線で区切って識別子とするのが特徴です。

[21] MIME (電子メール) の他、Web (HTTP/HTML) や SIPRTP など様々な応用でデータ形式の記述方式として広く採用されています。

[143] ファイルシステムにおける拡張子などファイルの種類におおむね対応する概念です。

仕様書

[222] MIME型は、 MIME 仕様群の1つである RFC 2046 で規定されています。しかし、その適用範囲の拡大に追随した仕様の改訂が行われず、 他のいろいろな仕様書が自身に必要な範囲でそれぞれ規定する形で事実上の改訂を (相互に矛盾するようなしないようなよくわからない状態で) 行っています。

[394] MIME型データモデル構文解析は、 MIME Sniffing Standard により規定されています。

呼称

[144] MIME型は、次のような名前で呼ばれています。

[395] MIME型の呼称
  • MIME型 (MIMEタイプ)
  • 媒体型 (メディアタイプ) (media type)
  • インターネット媒体型 (Internet Media Type)
  • MIME 媒体型 (メディアタイプ) (media type)
  • 内容型 (content type)

[145] MIME型は大分類と小分類の組で表されますが、この大分類も「 (type) 」、 全体も「型」と呼ばれるため、どちらを指しているのか曖昧なことも少なくありません。

[146]MIME型」などと修飾される場合は全体を指していることが多く、 「型」とのみ呼ばれる時は大分類を指していることが多いようですが、例外もあります。 大分類であることを明示する時は、「最上位型 (top-level type) 」 のように最上位 (top-level) と修飾するのが一般的です。

[238] RFC 2077最上位型primary content typeprimary type と呼んでいます。

[147] ほとんどの場合「MIME型」や「内容型」と言えば text/plain 全体を指しますが、稀に text のみを指していることがあります。


[148] HTML StandardFetch Standard などの現在の Web仕様書は、最も普及した用語である「MIME型」を採用しています。 MIME Sniffing Standard は「MIME型」などの用語を定義しています。

[396] 改訂以後の MIME Sniffing Standard は、 MIME型 (MIME type) RFC 2046 インターネット媒体型を表すもので MIME型記録 (MIME type record) とも呼ぶ >>393 とし、「MIME型」をデータ構造として定義しています。

[398] 以前の各仕様書は、 もっぱらMIME型の文字列表現を扱っていました。 改訂以後の MIME Sniffing Standard は、 「妥当なMIME型文字列」 などMIME型文字列 (MIME type string) という語を使っています。

[149] IETF は「媒体型」を正式な用語と考えているようで、 近年の RFC の多くはこの語を採用しています。しかし次に示す通り歴史的には相当な混乱があり、 現在でも完全に統一されているわけではないようです。

[104] RFC 1341/RFC 1521 は「Content-Type の値」といったような表現を使っており、現在の「MIME型」に相当する特別な用語は用意していなかったようです。 「content-type/subtype pair」という表現もあります。また登録雛形では 「MIME type name」/「MIME subtype name」となっています >>102, >>105。 重要な概念に明確な用語を定義しなかったことが、以後の混乱の引き金となってしまいました。

[108] RFC 1341/RFC 1521 は各1箇所だけ「媒体型 (media type) 」 という語を使っています >>106, >>107

[113] RFC 1590 には従来の「MIME (Type) 」を「媒体型 (Media Type) 」 と呼ぶ >>111 との記述があります。しかし 「Content-type/subtype pair」という表現も残っています。また 「Media type name」/「Media subtype name」という記述もあります。

[117] RFC 2048 は「媒体型 (media type) >>114 と表現しています。1箇所だけ「MIME type and subtype」 との記述もあります。「MIME media type」という表現や、 「MIME media type name」/「MIME subtype name」という表現も数箇所だけ登場します。

[124] RFC 4288RFC 6838 は「媒体型 (media type) >>121 に統一しています。

[133] IANA登録簿の題名は当初は「MIME Media Types」>>132 でした。 「Content Types」/「Content Subtypes」という表現もありました。

[134] 現在のIANA登録簿の題名は「Media Types」>>131 となっています。 「Media Types (formerly known as MIME types) and Media Subtypes」 という記述もあります。

[135] 多くの RFC は「Internet Media Type」とも呼んでいます。 古いものでは RFC 1866 がこの語を使っています >>137 (どの RFCが最古のものかは不明)。 RFC 3420 では題名にもなっています >>136 (が本文中では 「MIME 媒体型」と呼ばれています)。

[139] 「"MIME types" (renamed "Internet Media Types" in later specs [RFC2046])」 と述べた文書 >>138 もありますが、 RFC 2046 には 「Internet Media Type」は登場していません。

[141] HTML4 は「内容型 (content type) 」と呼んでいました。 理由として、当時の用法により沿っている点、CSS媒体型と区別できる点を挙げています >>140。しかしその説明と同じ章で「MIME 型」という語も使われています >>140

[142] この当時から「MIME型」が最も一般的な用語だったように思います。

[350] HTML Standard媒体型CSS 用語のために使い、 インターネット媒体型MIME型と呼んでいます。 >>349

[397] MIME Sniffing Standard は、 媒体クエリー媒体型との区別のため、 各標準MIME型と呼ぶべき (encourage) である >>393 としています。


[399] 改訂より前の MIME Sniffing Standard は、 文字列表現 (現MIME型文字列) を MIME型と呼び、 データ構造 (現MIME型記録) を構文解析済みMIME型と呼んでいました。

[292] 構文解析可能MIME型 (parsable MIME type) は、 MIME型の構文解析null を返さないような MIME型です >>289

[293] 構文解析可能MIME型には、対応する構文解析済みMIME型 (parsed MIME type) があります >>289。これはMIME型の構文解析で得られる値です。

意味

[290] 資源MIME型 (MIME type) は、 当該資源の用法や書式についての技術的ヒントです >>289

[261] MIME型は、その適用対象の解釈の方法 (意味) を表すものです。具体的には利用される場面によりますが、 多くの場合は適用対象となるバイト列文字列メタデータとしてMIME型を指定することで、 そのバイト列文字列の意味と解釈方法を指定することになります。

[262] MIME では、 Content-Type: ヘッダーの値として指定すると、 メッセージ本体バイト列の形式を表すものとみなされます。

[263] HTMLstyle 要素では、 style 属性の値として指定すると、 内容文字列スタイル言語を表すものとみなされます。

[264] HTTP要求Accept: ヘッダーの値として指定すると、 それに対するHTTP応答で使うべき MIME型を指定するものとみなされます。 (HTTP要求自体にそのMIME型で解釈されるべきデータが含まれるわけではありません。)

[155] ファイル形式と MIME型は、一対一対応関係にはありません。 同じ形式に複数のMIME型を割り当てるのは非推奨 (discouraged) です >>170 が、実際には数多くあります。

[156] XMLMIME型には text/xmlapplication/xml があります。 XHTMLMIME型には application/xhtml+xmlapplication/xml があります。

[182] IANA登録簿好ましい (prefer) ものを1つ選び、 それ以外を「deprecated alias」とすることを求めています >>170。 その場合応用は好ましいものを使わなければなりません >>170。 しかし必ずしも現実に沿った運用がなされているとはいえません。

[259] 世間で最も広く用いられている JavaScriptMIME型text/javascript ですが、 IANA登録簿RFC では「廃止」状態になっています。

[184] 世間で用いられる MIME型は、その本来の意味を逸脱しているものも少なくありません。

[186] 例えば HTTPダウンロードさせたい時に application/octet-streamapplication/download が用いられることがあります。 つまりファイル形式ではなく、求める処理を表すために MIME型が使われています。

[185] 一部の Web APIAccept: ヘッダーでは、 返されるデータの標準的な MIME型を使わずに、 API の「バージョン」番号などを含めた特別なMIME型を指定させたりします。 つまりファイル形式ではなく、 API の動作モードの指定のためにMIME型が使われています。

[256] プラグインの種類を表すためにMIME型が使われることがあります。 標準的な MIME型があるのにプラグインを表す特別な MIME型が用いられたり、 データを入力としないプラグインの実行のために特別な MIME型が用いられたりします。 つまりファイル形式ではなく、プラグインを識別するためにMIME型が使われています。

[260] MIME型は元々 MIME による電子メールでの情報交換のために規定されたものですが、 プラットフォームアプリケーションのような同一環境上での伝達 (他者との通信ではなく狭義の情報交換には含まれないもの) で使われたり、特定アプリケーション内部でのみ使われたりすることもよくあります。 その場合、特定アプリケーションでしか意味を成さない内部データ構造などに MIME型が割り当てられることもありますし、標準的な MIME型であっても、本来のその定義によるバイト列等ではなく、 それに相当する内部データ構造を表していることもあります。

データモデル

[150] MIME型記録は、 , 部分型, 引数群を持ちます。

[151] (type) は、 空文字列ではないASCII文字列です >>393 (最上位型 (top-level type) ) は、 元々は媒体の種類を区別することを意図していたようで (「媒体型」の語源)、 textaudiovideo などがあります。しかし text の意味するところが曖昧だったり、 ほとんどが application に分類されていたりして、 あまりうまく機能していません。

[152] 部分型 (subtype) は、 空文字列ではないASCII文字列です >>393内における細かな分類であり、 実際のファイル形式に相当するものです。 text/plainplainimage/pngpngapplication/pdfpdf などがあります。

[153] 部分型は、組として1つの MIME型を構成します。 異なる部分型を組み合わせることはできません。例えば image/pngimagevideo に置き換えるような使い方はできず、 まったく異なる MIME型となります。

[154] video/oggaudio/ogg のように異なるで同じ部分型MIME型が定義されていることはありますが、すべてのに対して定義されているわけではありません。 また、部分型が同じだからといって異なるMIME型が同じファイル形式を表しているとは限りません。

[157] MIME型には、零個以上の引数を指定することができます。 MIME型引数を含められるかどうかは、歴史的に文脈により異なっていました。 明確に定義されていないことも少なくありませんでした。 現在のMIME型記録の定義には引数群も含まれており、 Webプラットフォーム内で引数が使えない場合には、 そのように明示的に規定されています。

[294] MIME型記録essence は、 /部分型を連結した文字列です >>393

[159] かつては構文解析可能MIME型MIME型部分 (MIME type portion) >>289 と呼ばれていました。

構文

[291] MIME型は、普通、文字列またはバイト列と考えられています。

[158] MIME型の構文 (本体、引数とも) は統一された規定が存在せず、 プロトコルマーク付け言語などがそれぞれの規定を行っています。 それらは微妙に異なっていることがよくあります。また、明確な規定を欠いていることも少なくありません。

[171] RFC 6838IANA登録簿に登録される MIME型部分型引数名の構文を規定しています。

[172] しかしそれらの組み合わせ方 (区切り文字など)、登録されない MIME型の構文には言及していません。

[72] HTTPRFC 2046 を引用しつつ、独自に MIME型の構文を定義しています >>71HTML Standard妥当なMIME型 (valid MIME type) は、 HTTP (RFC 7231) の定義に合致する文字列とされています >>349

[73] MIME型は、/部分型、零個以上の引数で構成されます。 ただし引数の前には、 ; が必要で、 ; の前後には OWS を挿入できます。 >>71

[74] 部分型は、 HTTP では字句です >>71IANA登録簿では、制限名です >>170IANA登録簿では64文字以下であるべきです >>170

[173] 部分型は、大文字・小文字不区別です >>71, >>170

  1. /
  2. 部分型
  3. *
    1. OWS
    2. ;
    3. OWS
    4. 引数

[75] 引数は、名前、=、値で構成されます >>71

[77] 引数の名前は、 HTTP では字句です >>71IANA登録簿では、制限名です >>191

[174] 引数の名前は、大文字・小文字不区別です >>71, >>191

[78] 値は字句または引用文字列です。 引用符の有無は、意味を持ちません。 値の大文字と小文字が区別されるかは、引数によります。 >>71

  1. 引数
  2. =
  3. |
    1. 字句
    2. 引用文字列
[80] = の前後には BWS も認められていません >>71

[198] 引数の順序には意味がありません >>191, >>223。 同じ引数が複数あるのは誤り (error) です >>191

[199] 誤りをどう処理するべきなのかは不明です。

[76] 引数の有無は、MIME型の定義によっては処理に影響があるかもしれません >>71

[175] 制限名 (restricted-name) は、 ASCII英数字!, #, $, &, -, ^, _, ., + で構成される1文字以上126文字以下の文字列です >>170

[176] このうち . の初出は+構造化構文接尾辞を表すことになっています >>170部分型はそれでよいとして、 引数名についてこれをどう解釈するべきかは不明瞭です。 また未登録の MIME型はこれらの規則に従っていないものもあります。
[183] !, #, $, &, ^ を使った MIME型が実在するのかは不明です。

[351] 妥当なMIME型で引数のないもの (valid MIME type with no parameters) は、 妥当なMIME型かつ ; を含まないものです >>349

構文解析

[296] MIME型を構文解析 (parse a MIME type) するには、 文字列を次のようにします >>393

  1. [313] 文字列の先頭と末尾の ASCII空白をすべて除去します。
  2. [347] を、文字列の先頭のHTTP字句符号位置すべてとし、 これを文字列から除去します。
  3. [348] 空文字列の場合、
    1. [410] 失敗を返し、ここで停止します。
  4. [411] 文字列の先頭が / の場合、
    1. [412] これを文字列から除去します。
  5. [413] それ以外の場合、
    1. [414] 失敗を返し、ここで停止します。
  6. [415] 部分型を、文字列の先頭のHTTP字句符号位置すべてとし、 これを文字列から除去します。
  7. [416] 部分型空文字列の場合、
    1. [417] 失敗を返し、ここで停止します。
  8. [418] 文字列の先頭からASCII空白をすべて除去します。
  9. [419] 文字列の先頭が ; の場合、
    1. [420] これを文字列から除去します。
  10. [421] それ以外で、文字列空文字列でない場合、
    1. [422] 失敗を返し、ここで停止します。
  11. [423] MIME型を、新しいMIME型記録に設定します。
    [424] MIME型記録
    ASCII小文字化したもの
    部分型
    部分型ASCII小文字化したもの
  12. [298] 文字列空文字列でない間、繰り返し、
    1. [300] 文字列の先頭から ASCII空白をすべて除去します。
    2. [301] 引数名を、文字列の先頭の = でも ; でもない符号位置すべてとし、 これを文字列から除去します。
    3. [317] 文字列の先頭が ; の場合、
      1. [318] これを文字列から除去します。
    4. [315] それ以外で、 文字列の先頭が = の場合、
      1. [316] これを文字列から除去します。
      2. [302] 引数名を、引数名ASCII小文字化した結果に設定します。
      3. [319] 文字列の先頭が " の場合、
        1. [328] 引数値を、空文字列に設定します。
        2. [324] 文字列の先頭が " 以外符号位置符号位置の間、 繰り返し、
          1. [331] 符号位置文字列から除去します。
          2. [325] 符号位置\ の場合、
            1. [330] 文字列の先頭が符号位置符号位置の場合、
              1. [333] 符号位置文字列から除去します。
              2. [332] 引数値の末尾に符号位置を追加します。
            2. [334] それ以外の場合、
              1. [335] 引数値の末尾に \ を追加します。
          3. [326] それ以外の場合、
            1. [329] 引数値の末尾に符号位置を追加します。
        3. [336] 文字列の先頭から ; でない符号位置をすべて除去します。
      4. [320] それ以外の場合、
        1. [321] 引数値を、文字列の先頭の ; でない符号位置すべてとし、 これを文字列から除去します。
        2. [322] 引数値の末尾から ASCII空白をすべて除去します。
      5. [299] 文字列の先頭が ; の場合、
        1. [323] これを文字列から除去します。
      6. [327] 引数名空文字列ではなく、 引数名HTTP字句符号位置以外を含ま引数値空文字列ではなく、 引数値HTTP引用文字列字句符号位置以外を含まMIME型引数群 [ 引数名 ] が存在しない場合、
        1. [425] MIME型引数群 [ 引数名 ] を、引数値に設定します。
  13. [297] MIME型を返します。
[407] MIME型を構文解析する場面

[404] MIME型をバイト列から構文解析 (parse a MIME type from bytes) するには、 バイト列を次のようにします >>393

  1. [405] 文字列を、バイト列同型復号の結果に設定します。
  2. [406] 文字列MIME型を構文解析を適用した結果を返します。
[346] MIME型をバイト列から構文解析する場面

[303] 次の場面では、指定される値が限られるため、 ASCII大文字・小文字不区別などのより簡便な方法が採られ、 MIME型の構文解析は行われません。

[304] MIME型を構文解析ない場面

直列化

[305] MIME型MIME型の直列化 (serialize a MIME type) は、 次のようにします >>289

  1. [408] 結果を、MIME型/MIME型部分型を連結した結果に設定します。
  2. [306] MIME型引数群の各名前の組について、順に、
    1. [307] 結果の末尾に ;名前= を連結した結果を追加します。
    2. [308] HTTP字句符号位置のみで構成される場合、
      1. [309] 結果の末尾にを追加します。
    3. [310] それ以外の場合、
      1. [311] "\ が含まれる場合、 そのすべての直前に \ を挿入します。
      2. [409] 結果の末尾に "" を連結した結果を追加します。
  3. [314] 結果を返します。
[342] 出力の型、部分型、引数名は小文字となります。
[403] MIME型を直列化する場面

[312] 改訂以前の定義では、 字句に長さ制限があり、直列化に失敗する可能性がありました。

[295] 直列化済みMIME型 (serialized MIME type) は、 構文解析済みMIME型MIME型の直列化を適用した結果です。 >>289


[400] MIME型をバイト列に直列化 (serialize a MIME type to bytes) するには、 MIME型を次のようにします >>393

  1. [401] 文字列を、MIME型MIME型を直列化を適用した結果に設定します。
  2. [402] 文字列同型符号化を適用した結果を返します。

[340] data:scheme fetch で呼び出されます。

MIME 型の一覧

[161] MIME型は、標準仕様で規定されているものもそうでないものも、 よく使われているものもそうでないものも含め、実に数多く、様々なものが存在しています。

[162] 次の表で * は、複数の MIME型のパターンを表しています。 所属する MIME型は、リンク先の各ページを参照してください。 ただし、場合によっては複数の MIME型を表すため、あるいは設定ミスその他の理由でしばしば MIME型として使われるものもいくつかあります。

[26] MIME型の一覧
/
*/*
vnd.android.cursor.dir/*
vnd.android.cursor.item/*
app/ggGoogle Desktop gadget
application/*
x-application/*
zz-application/zz-winassoc-tgz
archive/*
attachment/file
audio/*
audio-file
auth/sicilyFrontPage
avro/binary
b64_zlib_yaml
x-be2
bin/application
binary
binary/octet-stream
chemical/*
coloreal/embedded
x-conference/x-cooltalkCoolTalk [Netscape]
content/unknown
x-data/xact-error
unknown
database/x-unknown
default
defiant/xsl-template
x-device/floppy[GNOME]
x-directory/normal
document/x-epub
drawing/x-dwf
drawing/x-dwf(old)
drawing/x-dwf (old)
dsmcc-*/*
dsmcc-download/jpeg
dsmcc-file/mpeg2-ps
dsmcc-file/html
dsmcc-stream/mpeg2-ts
dviRFC 1049
x-epoc/x-sisx-app
example/*
x-ferrum-head/*
x-ferrum-menu/*
font/*
x-font/*
x-form/x-openscape
gadget/x-googlegadget
vnd.google.fitness.session/biking
vnd.google.fitness.session/running
vnd.google.fitness.data_type/*
com.google.android.gms.fitness.data_type/*
vnd.google.fitness.activity_type/running
vnd.google.android.hangouts/vnd.google.android.hangout_privileged
vnd.google.android.hangouts/vnd.google.android.hangout_whitelist
graphics/x-inventorOpen Inventor 3次元 scenes
gzip/document
image/*
in/share
inode/*[freedesktop.org]
interface/x-winamp-skin
x-jigsaw/config
x-kom/basic
x-lml/x-lml
math/*
matter-transport/sentient-life-form
mail-file
mce-text/javascript
message/*
mforge/x-mirage
midi/mid
misc/ultravox
model/*
x-model/x-mesh
more/less
mozilla.application/cached-xul
multipart/*
x-wap.multipart/vnd.uplanet.header-set
x-music/x-midi
none
octet/stream
plain/text
plugin/*
x-pmaildx/x-mmctrl
x-postpet/*
postscriptRFC 1049
postscript-file
pson
raw
s
x-scheme-handler/*
scribeRFC 1049
x-script/x-wfxscript
sgmlRFC 1049
x-shader/x-fragment
x-shader/x-vertex
x-squid-internal/vary
x-sun-attachment
sun-deskset-message
x-system/x-error[Namazu]
texRFC 1049
text/*
x-text-pc/ms-word
troffRFC 1049
unknown/unknown
x-unknown/octet-stream
x-unknown/x-unknown
vector/*
video/*
videotex/vemmi
x-visa-ii/x-auth
windows/*
workbook/formulaone
i-world/i-vrml
x-world/*
www/mimelibwww
www/unknown未知 (自動判別) libwww
www/source
x-*RFC 1049
xgi/*
xml/user-profileXUP
yaml

[9] JSON形式の一覧データファイルが >>10 にあります。

比較

[353] 指定されたMIME型が特定の条件を満たすかどうかの判定のほとんどは、 MIME型部分のみと比較します。つまり引数の存在は無視されます。

[352] スクリプトの型の決定では、 <script type> 属性値と 前後の空白文字を除去してからASCII大文字・小文字不区別比較が行われます。 引数つきのMIME型は扱わないので、引数があると未対応のMIME型とみなされます。

最上位型

[224] / より前の部分が (type) (最上位型 (top-level type) ) です。

[225] 一般に最上位型はデータの一般 (general) の型を表し、 部分型がその型の特定の形式を表します >>223

[226] 例えば image/png は、画像であり、 その具体的な書式は PNG であることを表しています。 利用者エージェントがこの MIME型について知識が無いとしても、 画像であることはわかります。

[227] 最上位型の情報は、未知の部分型の場合に生データを利用者に提示するべきかどうかを決定するために使うことができます >>223

[228] text/* なら未知でも生データを提示して構わないかもしれませんが、 image/* なら好ましくなさそうえす >>223

[229] 最上位型はこのようなものですから、 text/*image/*audio/*video/* の各部分型は、実際には異なる種類の情報を埋め込むべきではありません >>223

[230] そのような場合は multipart/*application/* を使うべきです >>223
[231] video/*音声トラックテキストトラックを含むのは例外とされています。 (video/* 参照。)

[177] 部分型の決定にはの意味を考慮しなければならず部分型の制約に適合しなければなりません >>170

[178] 例えば multipart/* に属する部分型multipart/* の共通の構文に従う必要があります。

木と x-

[28] 部分型. を区切り文字とする階層構造によって分けられています。 これは (tree) と呼ばれています。

[164] image/png標準木に、 image/vnd.microsoft.icon事業者木に属しています。

木 (IETF)を参照。

[165] また x- ではじまる部分型は、かつては私用のために予約されていました。 現在は特別な扱いはされておらず、 x- から始まる部分型IANA登録簿に登録されています。

木 (IETF)をも参照。

[258] IANA登録簿には (不思議なことに) application/index のようにMIME型として登録されていることもあります。

構造化構文接尾辞

[68] image/svg+xml+xml のように、 MIME型の末尾に + と構文名がついているものは、その構文の一応用であることを表します。 この例では、 XML という構文に基づいたマーク付け言語の一種である SVG ということを表しています。このようなものを構造化構文接尾辞 (structured syntax suffix) といいます。 詳しくはそちらの項を参照してください。

引数

[192] MIME型には、0個以上引数を指定できます >>191, >>223MIME型記録引数群 (parameters) は、 ASCII文字列であるキー順序付き写像で、 初期状態はです >>393

[193] しかしMIME型を使う文脈によっては、引数を指定できないこともあります。 指定されていると正しく処理できない実装も少なくありません。

[67] 引数は、個別のMIME型で規定されているものもあれば、 最上位型に属するMIME型全体で規定されるものもあります >>191, >>223。 複数の MIME型で定義を共有しているものもあります。 すべてのMIME型で共通して利用できる引数は、正式には存在しませんが、 現実には幾つかの引数MIME型と独立に使われています。

[194] 本来の MIME の設計思想に従うなら、すべての MIME型に適用可能な引数は他のヘッダーで記述するべきです。

[233] 実装は、認識できない引数を無視しなければなりません >>223

[195] 全部または多数の MIME型で使われる引数には、次のものがあります。

[85] 引数名q」は非推奨 (discouraged) です >>84。 本来は Accept: ヘッダーなど一部の場面で使われるもので、 MIME型ではなくヘッダー側に属する構文です。

[2] ODataOData の実装に対して odata から始まる (OData で規定されていない) 引数の利用を禁止しています >>1

[197] 標準木に登録する MIME型は、引数の名前と値と意味を完全に規定しなければなりませんvnd.prs.に登録する MIME型は、 可能な限り規定するべきです。 >>191

[202] なぜによって要求度が異なるのか謎です。 vnd.prs. の登録の敷居を下げるためかもしれませんが、 相互運用性に支障が出るのでは...

[288] 実際にはそれを放棄しているものもあります。

[276] 例えば text/markdown は、 任意の引数を使えると規定しています。

[200] 引数の値の構文は、引数によります。MIME型を登録する際は規定しなければなりません >>191

[201] プロトコルによってはバイナリーを値として指定できるかもしれませんが、 他のプロトコルでは使えないので、避けたほうが無難です >>191

[275] 引数の値として認められる範囲やそもそも引数を指定できるかどうかは、 他の引数の値に依存して決まることもあります。

[203] 標準木MIME型に対して新機能を追加する方法として新しい引数を定義するべきではありません。 既存の機能を変更せずに追加情報を与える新しい引数を定義するのは構いません。 vnd.prs.においても同様とするべき (encourage) ですが、必須ではありません。 >>191

[204] 例えば JPEG の改訂水準を表す revision 引数が挙げられます >>191

[205] この規定の意図するところはあまりよくわかりません。 処理に影響を与えないなら、引数が存在する意義がない気がしますが... 改訂によってそのような機能を追加するべきではないということなのでしょうか。 text/plainformat 引数を後から追加したのは、かなり大きな変更のような気がしますが、 これは許されていいのですかねぇ。 によって制約が緩和される理由もよくわかりません。

[196] その他の個別の引数は、各MIME型最上位型の項を参照してください。

[232] 引数によっては、必須とされているものもあります >>223

[235] 次の引数は、必須です。

[220] 次の引数には自然言語文を記述できるようです。

分類

[179] 次の MIME型の分類があります。

MIME 型の決め方

[281] 新しいMIME型を決める方法について、色々な人が色々なことを言っています。 IETF が発行する RFC の規定が最も「公式」と考えられていますが、 必ずしも実態に合っていませんし、何かと曖昧です。

  1. [282] 既に適当な MIME型があれば、新しいMIME型を作る必要はどこにもありません。
    1. [283] JSON を使っているなら、 application/json とします。
    2. [284] XML を使っているなら、 text/xml とします。
    3. [285] その他適切なMIME型があれば、それを使います。
  2. [286] それ以外の場合、

MIME 型の登録

[12] MIME は元々電子メールのためのプロトコルであり、 相互運用性のためにMIME型は限られた種類のみに限定することが好ましいと考えられていました >>35。そのため MIME型IANA登録簿は用意されていましたが、 登録のハードルは高く設定されていました。

[44] しかし実際には既存の多くのファイル形式が添付ファイルHTTP でやり取りされるファイルなどの形で MIME および派生プロトコルの環境下で用いられるようになりました。 WindowsLinux 上のデスクトップ環境などでファイル形式を表す識別子 (の1つ) として MIME型が採用されたこともあり、ネットワーク上でやり取りされないファイル形式にも MIME型が割り当てられるようになりました。 この結果、IANA登録簿に登録されていない MIME型が (x- を使ったものも使わないものも含め) 相当数利用されることとなりました。

[96] 後に MIME型の登録手続きは緩和され、 vnd. 木であれば比較的簡単に登録できるようになりました。 しかし既存の MIME型IETF 側から積極的に IANA登録簿に登録しようとする動きはありません。 以前に比べれば IANA登録簿に登録される MIME型が多くなったとはいえ、 現実の利用状況と乖離しているという問題は解消されていません。

[163] 未登録の MIME型を使うべきではないと主張する人もいますが、 現実的ではありません。

[79] MIME型は、 BCP 13 の手続きによりIANAに登録するべき (ought to) です >>71

[167] MIME型として IANA登録簿に登録できるのは、 「媒体書式 (media format) 」に限られます >>166。 例えば Base64内容転送符号化なので、 MIME型として登録することはできないとされています。

[168] この制約は MIME の仕組みに由来するもので、他の文脈には有用な区別ではないかもしれませんし、 曖昧です。これがIANA登録簿と現実が乖離する一因にもなっています。

[169] gzipMIME型は長らく IANA登録簿に登録されておらず、登録後も引き続き従来の色々な未登録の MIME型が使われ続けています。 標準のMIME型が存在しないことが相互運用性の問題を引き起こしていただけでなく、 統一に失敗して複数のMIME型を恒久的に対応し続ける必要が生じてしまいました。 (しかもその重要な情報が RFC にも IANA登録簿には掲載されていません。 RFC だけ読んでも相互運用可能な実装は作れないということです。) 似たような現象が、例えば image/vnd.microsoft.icon でも起こっています。こちらも正式なMIME型が登録されて10年以上経っても統一されていません。

[189] 同様にアーカイブ系ファイル形式もほとんどが登録されていません。 application/zip は1993年と早い時期に登録されているものの、 非推奨であり multipart/mixed を使うべきとの記述があります。 もちろん今となっては頓珍漢で誰も相手にしないような記述です。

[180] 最上位型は、 IETF の手続きで追加することは可能 >>170 ながら、 新たなものが必要なことは稀である >>170 として比較的高いハードルが設定されており、 私用の仕組みも用意されていません。これまでに正式に追加されたのは model/* だけです。

[181] その他にも幾つか提案はありましたが、却下または立ち消えとなっています。 実際にはやはり他の最上位型に馴染まない MIME型は存在するので、 非標準のものが使われたり、 application/* に押し込まれたりしています。

[209] 登録されたMIME型は削除できません >>208

[247] しかし実際には application/xhtml-voice+xml のように突然削除された例もあります。

[210] 登録されたMIME型廃止 (OBSOLETE) 状態に変更することができます >>208

[211] しかしこの廃止の意味は明確になっていません。廃止されているからといって、 それを利用してはならないとの明示的な規定は無さそうです。

[213] 例えば text/javascript廃止状態になっています。 しかし現実には JavaScriptMIME型として最も広く用いられている MIME型なので、「廃止」とは一体どういう意味なのかは不明です。

[212] なお他に状態らしきものとして非推奨 (DEPRECATED>>182 の Deprecated Alias とは別) や一時 (TEMPORARY) と注記されたものが IANA登録簿上にありますが、これらが何を表しているのかは明確にはなっていません。 RFC にも言及がありません。

[265] IANA登録簿XML 版もありますが、 IANA 内の都合に合わせたもので、 一般利用者向けに整備されているわけではないように見えます。部分型と 「(TEMPORARY - ・・・)」のような注記が混ざっていて、しかもある日突然新形式の注記が混ざったりするので、 機械的な利用にはあまり向きません。

[266] text/markdown は、

markdown (temporary registered 2014-11-11, extension registered
        2015-09-17, expires 2016-11-11)
... という謎の注記付き部分型で登録されています。

[358] application/mud+json は次のような謎の注釈付きで登録されています。

    <record date="2016-11-17">
      <name>mud+json (TEMPORARY - registered 2016-11-17, expires 2017-11-17)</name>
      <xref type="draft" data="draft-ietf-opsawg-mud"/>
      <file type="template">application/mud+json</file>
    </record>

[377] その後更新されて

TEMPORARY - registered 2016-11-17, extension registered 2017-10-02, expires 2018-11-17

... となっています。

[370] 「expires」とありますが、登録簿からの削除が認められていないこととの関係は不明です。 (expires により削除された例があるのかどうかは不明です。)

[430] 登録雛形の「Intended usage」欄には、 OBSOLETE の他に、 COMMONLIMITED USE を指定できます >>170


[363] 後年になって、本登録簿とは別に予備登録簿 >>362 が設けられました。 これは手続きに時間がかかる標準木の登録に先立って、IETF が承認した標準化団体標準化の過程にあるMIME型を予備的に登録できるというものです。

[364] 予備登録簿の MIME型は、本登録に至って抹消されることもあれば、 取り下げにより削除されることもあります。

[366] 常に十数個登録された状態で、そこそこ活用されてはいますが、 検討中のあらゆるMIME型が登録されているといえるほど網羅性は高くありません。

[371] この予備登録は、本登録簿の「TEMPORARY」とは異なる制度です。どう異なるのかは不明です。

[365] IANAWebサイトの本登録簿からはリンクも言及もされていないので、 見つけにくいです。

[367] 本登録簿とは別に場当たり的に雑な制度を付け足すのは登録制度全体の破綻ですよね。。。


[384] MIME型ごとの登録情報は、例えば text/css なら https://www.iana.org/assignments/media-types/text/css のような URL で提供されています。

[385] この登録情報は登録雛形を使って IANA に登録する手続きを通過した MIME型のみしか存在していないので、例えば text/plain のものはありません。

[386] application/vnd.openxmlformats-officedocument.presentationml.template https://www.iana.org/assignments/media-types/application/vnd.openxmlformats-officedocument.presentationml'''-'''template のように、 MIME型URL で微妙に綴りが違うものもいくつかあります。

MIME 型の構文に従わない型

[5] MIME型のように「型/部分型」の構文となっていない値が MIME型と同じ文脈で使われることがあります。

[6] Content-Type: ヘッダーMIME 以前から定義していた RFC 1049 は、 / が入らない型を規定していました。

[7] AtomText construct および atom:content 要素type 属性では、 MIME型以外に特殊な意味を持つ texthtmlxhtml を指定できます。

[8] Metalinkmetaurl 要素mediatype 属性には MIME型以外に torrent を指定できます。

API

[269] DOMAPI は基本的に MIME型文字列として扱っています。 構文解析して部分を取り出したり、比較したりする標準の API はありません。

[255] MIME型を表す MimeType インターフェイスとその配列である MimeTypeArray インターフェイスがありますが、 プラグインAPI の一部ですから、汎用的なものではありません。

[270] プログラミング言語ライブラリー等の中には、MIME型を操作する API を提供するものもあります。しかし一般的には、 MIME型文字列ないしはバイト列として操作されることが多いと思われます。

[271] そのため引数の扱いや大文字小文字の扱いなどで不具合を誘発しています。 問題を避けるためにも、引数はできるだけ使うべきではありませんし、 MIME型はすべて小文字表記とするのが無難でしょう。

パターン

[86] MIME型の集合を表す構文がいくつかあります。

文脈

[94] MIME型は色々なところで利用されています。

[187] MIME型に関わる次のプロトコルがあります。

[272] Web を含むインターネットではMIME型がデータ型を表記する政治的に正しい方法とされています。 IETFW3C などの公式な標準仕様が規定する技術は、 もっぱらMIME型を用いるのが普通です。

[273] しかし現実は必ずしもそうなっているわけではありません。特に Web では、拡張子MIME SniffingMIME型と併用されています。

[274] input 要素accept 属性では、MIME型だけでなく拡張子も指定できます。


[339] data: URL構造体は、 MIME型 (MIME type) を持ち、 その値はMIME型です >>338

ファイルシステムと MIME 型

[268] XXX

RTP

[267] RTPMIME型の指定に (RTP の他の部分と整合した) 独特の構文を採用しています。 また RTP で使う MIME型とそれ以外のプロトコルで使うMIME型のほとんどは重なりません。 (RTP で使うことができるデータ形式は「framed」と呼ばれています。) 登録手続きは一応共通ですが、別の特別な RFC で規定されています (>>130)。 実質的に従来のMIME型とは異なる別のデータ形式記述方式ですが、 IETF 内で複数の似たものが存在するのは良くないとの政治的な理由からなのか、 無理矢理に統合されているように見えます。

処理

[239] 処理方法は、個々の MIME型によります。

[240] 未知の最上位型をどう処理するべきか RFC 2046 は明記していません。 が application/octet-stream のように扱うべきと思われます。

比較

[254] object 要素の処理では、引数も含めて ASCII大文字・小文字不区別で比較されます。

他の識別子との関係

[206] MIME型IANA登録簿は、拡張子魔法数Mac OS File Type といった識別子を (あれば) 登録時に記述することを推奨しています。

[207] ApacheWindows をはじめ多くの MIME型の実装は、 ファイルシステム上のファイルMIME型を決定する際にファイル名拡張子を使っています。

ただし拡張子MIME型の関係は多対多であり、確実に決定することはできません。 また拡張子がない MIME型MIME型がない拡張子も珍しくありません。

テスト

[337] web-platform-tests/mimesniff/mime-types at master · w3c/web-platform-tests () https://github.com/w3c/web-platform-tests/tree/master/mimesniff/mime-types

歴史

[101] MIME型の前身となるものは RFC 1048 で規定されていました。 後に MIME により現在の「型/部分型」の形に変更されました。

RFC 1049

[81] RFC1049とInternet媒体型の対応参照。

MIME

[236] MIME型RFC 1341RFC 1521 を経て RFC 2046 で規定されています。

[241] RFC 2046RFC 822ABNF を採用しているように見えますが、 明記されていません。

[242] 多くの引数の構文は明記されていません。旧版の RFC 1521 には ABNF があったのに、なぜか削除され、退化しています。

[237] RFC 2046 は次の通り部分的に更新されています。

[243] 登録手続きの改訂版である RFC 4288RFC 2046 の一部規定をコピペ改訂しているようですが、なぜか更新とはなっていません。 RFC 2046 と登録手続きの RFC は内容に重複がありつつ完全な整合性は無く、 解釈が難しい状態です。

[103] MIME型の登録手続きは当初 RFC 1341 >>102RFC 1521 >>106MIME 第1部の附属書で規定されていました。

[90] RFC 2046 2. Definition of a Top-Level Media Type

The definition of a top-level media type consists of:

上位媒体型の定義は次のものから構成されます。

    (1)   a name and a description of the type, including
          criteria for whether a particular type would qualify
          under that type,

(1) 型の名前と説明。特定の型をその型の下に置けるかどうかの適合基準

    (2)   the names and definitions of parameters, if any, which
          are defined for all subtypes of that type (including
          whether such parameters are required or optional),

(2) その型のすべての亜型用に定義するパラメーターがあればその名前と定義 (そのパラメーターが必須か省略可能かを含む)

    (3)   how a user agent and/or gateway should handle unknown
          subtypes of this type,

(3) 利用者代理者や関門がその型の未知の亜型をどう取り扱うべきか

    (4)   general considerations on gatewaying entities of this
          top-level type, if any, and

(4) 必要なら、この上位型の実体の関門通過に関しての考慮一般

    (5)   any restrictions on content-transfer-encodings for
          entities of this top-level type.

(5) この上位型の実体の内容転送符号化の制限

[91] RFC 2046 3. Overview Of The Initial Top-Level Media Types

The five discrete top-level media types are:

5つの個々上位媒体型は次の通りです。

    (1)   text -- textual information.  The subtype "plain" in
          particular indicates plain text containing no
          formatting commands or directives of any sort. Plain
          text is intended to be displayed "as-is". No special
          software is required to get the full meaning of the
          text, aside from support for the indicated character
          set. Other subtypes are to be used for enriched text in
          forms where application software may enhance the
          appearance of the text, but such software must not be
          required in order to get the general idea of the
          content.  Possible subtypes of "text" thus include any
          word processor format that can be read without
          resorting to software that understands the format.  In
          particular, formats that employ embeddded binary
          formatting information are not considered directly
          readable. A very simple and portable subtype,
          "richtext", was defined in RFC 1341, with a further
          revision in RFC 1896 under the name "enriched".

(1) text —— 文字情報。亜型 "plain" は特に、いかなる類の書式化命令・指令 を含まない平文 (plain-text) を示します。平文は「そのまま」表示する ことを意味します。文の完全な意味を得るのに、指定された文字集合への対応を 除いて特別なソフトウェアは必要ありません。他の亜型は応用ソフトウェアが 文の見た目をよくする裕福文に使われるかもしれませんが、内容の 一般的な着想を得るのにはこのようなソフトウェアは必須ではありません。 ですから "text" の亜型となりえるものにはその形式を理解するソフトウェア 無しに読むことが出来る言葉処理器 (ワード・プロセッサー) の形式を含みます。 特に、バイナリ書式付け情報を埋め込んだ形式は直接可読とは言えません。 とても単純で移植性ある亜型, "richtext" (裕福文) は RFC 1341 で定義されていましたが、 RFC 1896 で "enriched" (裕福化) という名前で 更に改訂されています。

訳注: embeddded は d が一個多い。

    (2)   image -- image data.  "Image" requires a display device
          (such as a graphical display, a graphics printer, or a
          FAX machine) to view the information. An initial
          subtype is defined for the widely-used image format
          JPEG. .  subtypes are defined for two widely-used image
          formats, jpeg and gif.

(2) image ——画像データ。 "image" は情報を見るのに表示機器 (画像画面, 画像印刷機, FAX 機器など) が必要です。初期亜型としては 広く使われている画像形式 JPEG を定義します。。 亜型としては 2つの広く使われている画像形式, jpeg と gif を定義します。 (訳注: 誤植というか編集ミスというか。)

    (3)   audio -- audio data.  "Audio" requires an audio output
          device (such as a speaker or a telephone) to "display"
          the contents.  An initial subtype "basic" is defined in
          this document.

(3) audio ——音声データ。 "audio" は音声出力機器 (スピーカーとか電話とか) が内容を「表示」するのに必要です。初期亜型としては "basic" をこの文書で定義します。

    (4)   video -- video data.  "Video" requires the capability
          to display moving images, typically including
          specialized hardware and software.  An initial subtype
          "mpeg" is defined in this document.

(4) video 動画データ。 "video" は動く画像を表示する能力が必要です。 典型的には特別なハードウェアとソフトウェアを含みます。 初期亜型としては "mpeg" をこの文書で定義します。

    (5)   application -- some other kind of data, typically
          either uninterpreted binary data or information to be
          processed by an application.  The subtype "octet-
          stream" is to be used in the case of uninterpreted
          binary data, in which case the simplest recommended
          action is to offer to write the information into a file
          for the user.  The "PostScript" subtype is also defined
          for the transport of PostScript material.  Other
          expected uses for "application" include spreadsheets,
          data for mail-based scheduling systems, and languages
          for "active" (computational) messaging, and word
          processing formats that are not directly readable.
          Note that security considerations may exist for some
          types of application data, most notably
          "application/PostScript" and any form of active
          messaging.  These issues are discussed later in this
          document.

(5) appliaction 他の種類のデータ, 典型的には解釈出来ないバイナリ・データ や応用により処理される情報です。亜型 "octet-stream" は解釈出来ない バイナリ・データに使われ、この場合の最も簡単な推奨動作は情報を ファイルに書き出すと利用者に申し出ることです。 "PostScript" 亜型も PostScript 物体を転送するために定義します。他の "application" で使うべきものには表計算, 基メイル予定系統, 「動的」(計算的)メッセージの言語, 直接可読でないワード・プロセッサーの形式があります。なお、 応用データの幾つかの型, とりわけ "application/PostScript" や動的 目セージの形式には安全性について考慮すべきことがあたりします。 この問題についてはこの文書の後の方で話します。

The two composite top-level media types are:

2つの合成上位媒体型は次の通りです。

    (1)   multipart -- data consisting of multiple entities of
          independent data types.  Four subtypes are initially
          defined, including the basic "mixed" subtype specifying
          a generic mixed set of parts, "alternative" for
          representing the same data in multiple formats,
          "parallel" for parts intended to be viewed
          simultaneously, and "digest" for multipart entities in
          which each part has a default type of "message/rfc822".

(1) multipart 複数の独立したデータ型の実体で構成されるデータ。 4つの亜型がはじめから定義されています。 "mixed" 亜型は 一般の混成の部分の集合を示し, "alternative" は同じデータを複数の形式で 表現していることを表し, "parallel" は同時に表示されることを意図した 部分を組み合わせたもので、 "digest" は各部分の既定値が "message/rfc822" の多部分実体で構成されるものです。

    (2)   message -- an encapsulated message.  A body of media
          type "message" is itself all or a portion of some kind
          of message object.  Such objects may or may not in turn
          contain other entities.  The "rfc822" subtype is used
          when the encapsulated content is itself an RFC 822
          message.  The "partial" subtype is defined for partial
          RFC 822 messages, to permit the fragmented transmission
          of bodies that are thought to be too large to be passed
          through transport facilities in one piece.  Another
          subtype, "external-body", is defined for specifying
          large bodies by reference to an external data source.

(2) message カプセル化メッセージ。媒体型 "message" の本文は それ自体が何らかの種類のメッセージ物体の一部又は全部です。 この物体が今度は他の実体を含むかもしれませんし、含まないかもしれません。 "rfc822" 亜型はカプセル化内容が RFC 822 メッセージである時に使います。 "partial" 亜型は RFC 822 メッセージの一部用に定義するもので、 転送機能を一片でまとめて通過させるには大き過ぎると思われる 本文を断片化して送ることが出来ます。他の亜型, "external-body" は外部データ源を使って大きな本文を示すのに定義します。

It should be noted that the list of media type values given here may be augmented in time, via the mechanisms described above, and that the set of subtypes is expected to grow substantially.

媒体型値は上述の機構でいつ増補されるかもしれませんし、 亜型の集合は本質的に増えて行くだろうことに注意して下さい。

[92] RFC 2046 6. Experimental Media Type Values
   A media type value beginning with the characters "X-" is a private
   value, to be used by consenting systems by mutual agreement.  Any
   format without a rigorous and public definition must be named with an
   "X-" prefix, and publicly specified values shall never begin with
   "X-".  (Older versions of the widely used Andrew system use the 
 "X-BE2" name, so new systems should probably choose a different name.)

文字 "X-" から始まる媒体型値は私用値で、相互の同意により同意系統で 使われます。厳密に公的に定義されていない形式は "X-" 接頭辞つきで 名前をつけなければなりませんし、公的規定値は "X-" で始めてはいけません。 (広く使われている Andrew の系統の古い版は "X-BE2" 名を使っていましたので、 新しい系統は違う名前を選ぶのがよろしいでしょう。)

   In general, the use of "X-" top-level types is strongly discouraged.
   Implementors should invent subtypes of the existing types whenever
   possible. In many cases, a subtype of "application" will be more
   appropriate than a new top-level type.

通常、 "X-" を上位型に使うのは強く非推奨です。実装者は出来る限り 既存の型の亜型をでっち上げるべきです。多くの場合、 "application" の亜型にするのが新しい上位型にするのより適切です。

HTTP および派生プロトコルでの扱い

[4] HTTP92 は、電子メールとは違って HTTP では内容折衝が使えるので、 MIME にない媒体型も認めるべきだと述べていました >>3

[93] RFC 1945 (HTTP/1.0) 3.6; RFC 2068・2616 (HTTP/1.1) Media Types

HTTP uses Internet Media Types {1945} [13] {2616} [17] in the Content-Type {1945} header field ({1945} Section 10.5 section {2068} 14.18 {2616} 14.17) {2068,2616} and Accept (section 14.1) header fields in order to provide open and extensible data typing {2068,2616} and type negotiation.

[39] HTTP は Internet 媒体型を Content-Type 頭欄と Accept 頭欄において開放的で拡張可能なデータ型指定及びデータ型折衝のために使用します。

  • media-type = type "/" subtype *( ";" parameter )
  • type = token
  • subtype = token

Parameters may {2616} MAY follow the type/subtype in the form of attribute/value pairs {2616} (as defined in section 3.6).

[40] 引数が型/亜型の後に属性/値の組の形で続いても構いません

{1925,2068}

  • parameter = attribute "=" value
  • attribute = token
  • value = token | quoted-string

The type, subtype, and parameter attribute names are case-insensitive. Parameter values may {2616} might or may might not be case-sensitive, depending on the semantics of the parameter name. {1945} LWS must not be generated Linear white space (LWS) MUST NOT be used between the type and subtype, nor between an attribute and its value. {1945} Upon receipt of a media type with an unrecognized parameter, a user agent should treat the media type as if the unrecognized parameter and its value were not present. {2068} User agents that recognize the media-type MUST process (or arrange to be processed by any external applications used to process that type/subtype by the user agent) the parameters for that MIME type as described by that type/subtype definition to the and inform the user of any problems discovered. {2616} The presence or absence of a parameter might be significant to the processing of a media-type, depending on its definition within the media type registry.

[41] 型, 亜型, 引数属性名は大文字と小文字を区別しません。 引数値は、引数名の意味によって、区別するかもしれませんし区別しないかもしれません。 型及び亜型の間ならびに属性及びその値の間には線形空白 (LWS) を入れてはなりません認識できない引数のある媒体型を受信した際は、その認識できない引数と値は現れていないものとして取扱うべきです。 ある media-type を認識する利用者エージェントは、その MIME 型の引数を型・亜型定義で記述されているように処理 (あるいは利用者エージェントが型・亜型を処理するのに使う外部応用に処理させるように調整) し、問題が見つかれば利用者に知らせなければなりません 引数の有無は、媒体型登録簿中の定義によっては、媒体型の処理に意味を持つかもしれません。

Note: that some {1945} Some older HTTP applications do not recognize media type parameters. When sending data to older HTTP applications, implementations {1945} HTTP/1.0 applications {1945,2068} should SHOULD only use media type parameters when they are {1945} necessary to define the content of a message required by that type/subtype definition.

[42] 古い HTTP 応用には媒体型引数を認識しないものがあることに注意してください。 古い HTTP 応用にデータを送るときには、型・亜型定義が必須としている媒体型引数だけを使うべきです

Media-type values are registered with the Internet Assigned Number Authority (IANA {1945} [15] {2616} [19] ). The media type registration process is outlined in RFC 1590 [13 2048 [17]] 1590 [17]]]] 2048 [17]]. Use of non-registered media types is discouraged.

[43] 媒体型値は Internet 割当番号事務局 (IANA) で登録されます。媒体型登録過程は RFC 1590 にまとめられています。未登録の媒体型の使用は非推奨です。

3.6.1; 3.6.7 Canonicalization and Text Defaults

text/*//正規化

3.6.2; 3.7.2 Multipart Types

multipart/*

[27] RFC 1945 (HTTP/1.0); RFC 2068・2616 (HTTP/1.1) 7.2.1 Type

When an Entity-Body entity-body is included with a message, the data type of that body is determined via the header fields Content-Type and Content-Encoding. These define a two-layer, ordered encoding model:

メッセージに entity-body が含まれているときには、 その本体のデータ型は頭欄 Content-Type および Content-Encoding により決定します。 この2つの頭欄は2層順序付き符号化模型を定義します。

  • entity-body := Content-Encoding( Content-Type( data ) )

A Content-Type specifies the media type of the underlying data. A Content-Encoding may be used to indicate any additional content codings applied to the type data, usually for the purpose of data compression, that is are a property of the resource requested requested resource. The default for the content encoding is none (i.e., the identity function). There is no default encoding.

Content-Type はそのデータの媒体型を規定します。 Content-Encoding は、そのデータに適用されている、 要求された資源の特性である追加の内容符号化 (通常はデータ圧縮目的。) を示すのに使うことができます。 既定の符号化はありません。

Any HTTP/1.0 HTTP/1.1 message containing an entity-body should SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type header, as is the case for Simple-Response messages field, the recipient may MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the {1945,2068} URL {2616} URI used to identify the resource. If the media type remains unknown, the recipient should SHOULD treat it as type "application/octet-stream".

entity-body を含んだ HTTP メッセージは、 その本体の媒体型を定義する Content-Type 頭欄を含めるべきです。 媒体型が Content-Type 頭欄で与えられていない場合Simple-Response メッセージの場合は、 この場合に限って、受信者は内容及び/又は資源を識別するのに使う URI の名前拡張子をを調べて媒体型を推測しても構いません。 媒体型がそれでも分からない時は、受信者はその媒体を型 application/octet-stream として扱うべきです

[29] 注記なき変更点は 1945→2068 のもの。

登録手続きの独立

[112] RFC 1590 >>111 は、MIME 以外への用法の拡大を踏まえて改めて登録手続きを規定するものでした。 RFC 1521更新する形となっていました。

[115] RFC 2048 (BCP 13) >>114MIME型 (や他の MIME 関係のプロトコル要素) の登録手続きを規定するものでした。 RFC 1521RFC 1590廃止するものでした。

[116] RFC 1590 で一旦 MIME から独立したものが、なぜか RFC 2048 でまた MIME に戻っています。

[119] RFC 3023+xml 構造化構文接尾辞を規定するもので、 MIME型の登録時に +xml に関する制約に従うことを求めています。 RFC 2048更新する形となっています。

[120] しかし登録手続きそのものへの大きな変更はありません。

[160] RFC 3023 は XML の媒体型には亜型の最後に "+xml" をつけることを推奨しています。 また、あまり喜ばしくないとしながらも、将来同様のメタ型を使う時にも "+ebml" とか "+ebml+xml" とかすることを提案しています。

[123] RFC 4288 >>121, >>122 は再び MIME から独立した登録手続きを規定するものでした。 MIME の他の登録手続きを定義する RFC 4289 と共に新 BCP 13 として RFC 2048廃止するものでした。

[245] vnd.prs.x. のようなも導入されています。

[126] RFC 6838 >>125RFC 4288廃止するものです。 更に RFC 6838構造化構文接尾辞の登録も扱っています。

[100] この RFC は登録できる MIME型の条件や意味は規定していますが、 実際にプロトコルマーク付け言語で使う構文の規定や、 登録されていない MIME型の扱いについての規定はありません。 (そうした事項は MIMEHTTP の規定が適用されるものと思われます。)

[110] 媒体型の登録手続きが MIME じゃなくなった件 (RFC 4288 + RFC 4289 obsoletes RFC 2048)、 BCP としてはどちらも BCP 13 のままみたいです。 (名無しさん 2006-07-27 11:19:42 +00:00)

model/*

[244] RFC 2077model/* を規定しています。 現在までこれが唯一 IETF が公式に新設した最上位型です。

[246] なお1993年4月1日に発行された RFC 1437matter-transport/sentient-life-form を規定していますが、 IANA登録簿には登録されていません。

RTP における MIME 型

[129] RFC 3555RTP で使う MIME型に関する登録手続きの追加の規定を含んでいました。

[130] RFC 4855RFC 3555廃止して改めて RTP に関する登録手続きを規定するものです。

実装

[32] freedesktop.org - Standards/shared-mime-info-spec http://freedesktop.org/wiki/Standards_2fshared_2dmime_2dinfo_2dspec

メモ

[31] A question on Media Type Registrations http://ietfreport.isoc.org/idref/draft-iesg-media-type/

MIME 型プロトコル (具体的には RTP) で媒体型を使いたいけど MIME のしがらみがうざいというのが最近 ietf-types 等々で議論になってます。 (名無しさん [sage] 2005-06-09 00:47:27 +00:00)

[36] RFC 2046 の6章の

Any format without a rigorous and public definition must be named with an "X-" prefix, and publicly specified values shall never begin with "X-".

この規定(?)に従うと、 RFC 2046 で定義されている媒体型はみんな X- ではじめなければならなくなってしまうw (名無しさん)

[37] >>36 ところが X- にしてしまうと後者の要件に違反してしまうw

[38]

内容型 (content type) ― Describes the content stored in a part. Content types define a media type, a subtype, and an optional set of parameters, as defined in RFC 2616.

ECMA-376 Second Edition, Part 1, 4.

[46] [Apache-SVN] Log of /httpd/httpd/trunk/docs/conf/mime.types ( 版) http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/conf/mime.types?view=log

[47] (X)HTML5 Tracking ( 版) http://html5.org/tools/web-apps-tracker?from=4553&to=4554

[48]MIME型」のような用語の意味するところは曖昧です。

[49] Web Applications 1.0 は「妥当なMIME型」や「妥当な引数なしのMIME型」 といった用語を RFC 2616 を参照しつつ独自に規定しています。

[50] RFC 4287 (Atom 1.0) は RFC 4288 を参照するだけで、 RFC 4288 は構文を完全には規定していないため、実際にどのような構文で記述するべきなのかがはっきりしません。

[51] RFC 4855 (旧 RFC 3555) は、RTP で使うためのMIME型の登録に関する規定を行っています。

[52] iモード対応HTMLタグ一覧 : <OBJECT>(PDF関連) | サービス・機能 | NTTドコモ ( 版) http://www.nttdocomo.co.jp/service/imode/make/content/browser/html/tag/object_pdf.html

[53] Registry-MIME-types - WHATWG Wiki ( ( 版)) http://wiki.whatwg.org/wiki/Registry-MIME-types

[54] Video type parameters - WHATWG Wiki ( ( 版)) http://wiki.whatwg.org/wiki/Video_type_parameters

[55] Registry-MIME-types - WHATWG Wiki ( ( 版)) http://wiki.whatwg.org/wiki/Registry-MIME-types

[56] IRC logs: freenode / #whatwg / 20110419 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20110419#l-933

[57] draft-masinter-mime-web-info-02 - MIME and the Web ( ( 版)) http://tools.ietf.org/html/draft-masinter-mime-web-info-02

[58] IRC logs: freenode / #whatwg / 20120928 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20120928#l-669

[59] draft-ietf-appsawg-media-type-suffix-regs-08 - Additional Media Type Structured Syntax Suffixes ( ( 版)) http://tools.ietf.org/html/draft-ietf-appsawg-media-type-suffix-regs-08

[60] IRC logs: freenode / #whatwg / 20121105 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20121105

[61] Packaged Web Apps (Widgets) - Packaging and XML Configuration (Second Edition) ( ( 版)) http://w3c.github.com/packed-webapps/packaging/#media-type-attribute

[62] IRC logs: freenode / #whatwg / 20130326 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20130326

[63] ( ( 版)) http://cpansearch.perl.org/src/MIYAGAWA/Plack-1.0023/lib/Plack/MIME.pm

[64] IRC logs: freenode / #whatwg / 20130424 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20130424#l-84

[65] IRC logs: freenode / #whatwg / 20130507 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20130507#l-506

[66] [whatwg] [mimesniff] Review request: Parsing a MIME type ( ( 版)) http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-May/039678.html

[69] XML Binding Language (XBL) 2.0 ( ( 版)) http://www.w3.org/TR/2007/CR-xbl-20070316/#attributes1

[70] Metadata API for Media Resources 1.0 ( ( 版)) http://www.w3.org/TR/mediaont-api-1.0/#format

[82] Decide that parameters are ignored for the purposes of simple header · c5e6750 · whatwg/fetch ( ( 版)) https://github.com/whatwg/fetch/commit/c5e67505d2badfc480d3d4e1f9eb7952ab496f34

[83] RFC Errata Report ( ( 版)) http://www.rfc-editor.org/errata_search.php?rfc=7231&eid=4031

[87] Web Applications 1.0 r8690 Checkpoint recent updates relating to changing the pipeline. This fixes a bunch of editorial mistakes I uncovered with the new scripts. Shouldn't have any normative changes. ( ( 版)) http://html5.org/r/8690

[88] shared-mime-info-spec ( ( 版)) http://www.freedesktop.org/wiki/Specifications/shared-mime-info-spec/

[89] Re: [whatwg] How to determine content-type of file: protocol ( (Gordon P. Hemsley 著, 版)) http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Jul/0173.html

[95] RFC Errata Report ( ( 版)) http://www.rfc-editor.org/errata_search.php?rfc=7231&eid=4031

[97] How to Register a Media Type for a W3C Specification ( ( 版)) http://www.w3.org/2002/06/registering-mediatype2014.html

[98] RFC 5547 - A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer ( ( 版)) https://tools.ietf.org/html/rfc5547#section-6

[99] Metadata Vocabulary for Tabular Data ( ( 版)) http://www.w3.org/TR/2015/WD-tabular-metadata-20150108/

[11] Bug 28094 – Unclear wording ( 版) https://www.w3.org/Bugs/Public/show_bug.cgi?id=28094

[33] Web Font Media Type Analysis - Google ドキュメント ( 版) https://docs.google.com/document/d/1kP3Edo3nDN_2HS6IZK6DMnrvEG1StbY5OKmbwA1ilXI/edit

[34] RFC 3709 - Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates ( 版) https://tools.ietf.org/html/rfc3709#page-10

A MIME type is used to specify the format of the file containing the logotype data.

MIME types MAY include parameters.

[188] IANA | Application for Media Type ( 版) http://www.iana.org/form/media-types

[190] RFC 5688 - A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Subtypes ( 版) https://tools.ietf.org/html/rfc5688

[214] How to Register a Media Type for a W3C Specification ( 版) http://www.w3.org/2002/06/registering-mediatype2014

[215] gecko-dev/nsMimeTypes.h at dfd4efa147e3604707e65b502e142aa8e1dce737 · mozilla/gecko-dev ( 版) https://github.com/mozilla/gecko-dev/blob/dfd4efa147e3604707e65b502e142aa8e1dce737/netwerk/mime/nsMimeTypes.h

[216] base/mime_util.cc - chromium/src/net - Git at Google ( 版) https://chromium.googlesource.com/chromium/src/net/+/master/base/mime_util.cc

[217] PluginDoc: Windows (MIME Type List) ( 版) http://web.archive.org/web/20100911055400/http://plugindoc.mozdev.org/winmime.php

[218] net/base/mime_util.cc - chromium/src - Git at Google ( 版) https://chromium.googlesource.com/chromium/src/+/master/net/base/mime_util.cc

[219] mime_util.cc - Code Search ( 版) https://code.google.com/p/chromium/codesearch#chromium/src/components/mime_util/mime_util.cc

[248] <data> | Android Developers ( 版) http://developer.android.com/guide/topics/manifest/data-element.html

MIME type matching in the Android framework is case-sensitive, unlike formal RFC MIME types. As a result, you should always specify MIME types using lowercase letters.

[249] jshttp/mime-db ( 版) https://github.com/jshttp/mime-db

[250] mime-types/ruby-mime-types ( 版) https://github.com/mime-types/ruby-mime-types

[251] 2007 Office system ファイル形式の MIME タイプをサーバーで登録する ( 版) https://technet.microsoft.com/ja-jp/library/ee309278(v=office.12).aspx

[252] shared-mime-info-spec ( 版) http://freedesktop.org/wiki/Specifications/shared-mime-info-spec/

[253] Association between MIME types and applications ( 版) http://standards.freedesktop.org/mime-apps-spec/mime-apps-spec-latest.html

[257] Packaged Web Apps (Widgets) - Packaging and XML Configuration (Second Edition) ( 版) http://w3c.github.io/packaged-webapps/packaging/#valid-mime-type

A valid media type is string that matches the production for valid-MIME-type in the following [ABNF]:

valid-MIME-type = type "/" subtype *(";" parameter)

The type, subtype, and parameter tokens are defined in the [MIME] specification.

[277] draft-ietf-acap-mediatype-01 - ACAP Media Type Dataset Class ( 版) https://tools.ietf.org/html/draft-ietf-acap-mediatype-01

[278] Metadata Vocabulary for Tabular Data ( 版) http://www.w3.org/TR/2015/REC-tabular-metadata-20151217/#transformation-scriptFormat

scriptFormat

A link property giving the single URL for the format that is used by the script or template. If one has been defined, this should be a URL for a media type, in the form http://www.iana.org/assignments/media-types/media-type such as http://www.iana.org/assignments/media-types/application/javascript. Otherwise, it can be any URL that describes the script or template format.

NOTE

The scriptFormat URL is intended as an informative identifier for the template format, and applications should not access the URL. The template formats that an application supports are implementation defined.

[279] Metadata Vocabulary for Tabular Data ( 版) http://www.w3.org/TR/2015/REC-tabular-metadata-20151217/#transformation-targetFormat

targetFormat

A link property giving the single URL for the format that will be created through the transformation. If one has been defined, this should be a URL for a media type, in the form http://www.iana.org/assignments/media-types/media-type such as http://www.iana.org/assignments/media-types/text/calendar. Otherwise, it can be any URL that describes the target format.

NOTE

The targetFormat URL is intended as an informative identifier for the target format, and applications should not access the URL.

[280] Custom content-types | - The RESTful cookbook ( 著, 版) http://restcookbook.com/Resources/using-custom-content-types/

How can I create my own custom content-types that are representations of users, categories, articles etc?

Do not use a standard text/xml content-type. A client is not capable of handling this kind of information. Instead, use a custom format in the following form:

Content-type: application/vnd+company.category+xml

Content-type: application/vnd+company.category+html

Content-type: application/vnd+company.category+json

This allows your clients to process the information (in this case: your categories) as the specified content-type. All three of these content-types are categories, but they are represented in different formats (xml, html and json). Even though this is still information that clients need to know in advance, clients know what to expect, since they can ask for the specific information (categories, in this case), without outside knowledge like the URL etc.

All application/vnd are vendor-specific content-types and are not standardized. These are for non-standard content-types only.

[287] RFC 7749 - The "xml2rfc" Version 2 Vocabulary ( 版) https://tools.ietf.org/html/rfc7749#section-2.5.6

The value is either an Internet Media Type (see [RFC2046]) or a

keyword (such as "abnf"). The set of recognized keywords varies

across implementations.

How it is used depends on context and application. For instance, a

formatter can attempt to syntax-highlight code in certain known

languages.

[355] XProc 2.0: An XML Pipeline Language () https://www.w3.org/TR/2016/NOTE-xproc20-20160721/#p.input

The content-types attribute lists one or more (space separated) content types that this input port will accept. A content type must be of the form “type/subtype+ext” where any of type, subtype, and ext can be specified as “*” meaning “any”. The “+ext” is optional. Here are some examples of content types for matching:

text/plain, plain text documents

text/*, any kind of text document.

*/*+xml, any XML content type.

*/*, any content type.

[356] Let [MIMESNIFF] define MIME-related concepts (domenic著, ) https://github.com/whatwg/html/commit/0d08aea0733e5ad21f15f626b64d413a8c447083

[357] Add MIME types section by domenic · Pull Request #26 · whatwg/infra () https://github.com/whatwg/infra/pull/26

[359] Web Annotation Data Model () https://w3c.github.io/web-annotation/model/wd2/#h-external-web-resources

The value of the property should be the media-type of the format, following the [rfc6838] specification.

[360] RFC 8098 - Message Disposition Notification () https://tools.ietf.org/html/rfc8098

[361] RFC 8075 - Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP) () https://tools.ietf.org/html/rfc8075#section-6.3

To remedy this loss of flexibility, we introduce the concept of a

"loose" media type mapping, where media types that are

specializations of a more generic media type can be aliased to their

super-class and then mapped (if possible) to one of the CoAP content-

formats.

[368] TracSyntaxColoring – Applications and Real-Time Area Wiki () https://trac.ietf.org/trac/art/wiki/TracSyntaxColoring#SyntaxColoringSupport

[369] >>368Trac の附属ドキュメントで IETF の独自コンテンツではないのですが、 IANA登録簿に載っていないMIME型ばかりの一覧表が並んでいることに、 IETF の人は何も思わないのでしょうか。

[372] Bring outdated parts of the FAQ up to date (sideshowbarker著, ) https://github.com/whatwg/html/commit/5d512fe6f54a332d13ff2d0fee59f12a8d1701b3

[373] Improve <style> and <script> processing and conformance (domenic著, ) https://github.com/whatwg/html/commit/9c612ac8641b5174849a2d3cb924fe662a8d3a09

[374] <style type>/<script type> and MIME type parameters · Issue #3022 · whatwg/html () https://github.com/whatwg/html/issues/3022

[375] Improve <style> and <script> processing and conformance by domenic · Pull Request #3024 · whatwg/html () https://github.com/whatwg/html/pull/3024

[376] MIME type interoperability — Anne’s Blog () https://annevankesteren.nl/2017/10/mime-type-interoperability

[378] MIME type parsing, comments · Issue #33 · whatwg/mimesniff () https://github.com/whatwg/mimesniff/issues/33

[379] MIME type parsing, spaces before = · Issue #34 · whatwg/mimesniff () https://github.com/whatwg/mimesniff/issues/34

[380] MIME type parsing, single quote parameter values · Issue #35 · whatwg/mimesniff () https://github.com/whatwg/mimesniff/issues/35

[381] MIME type parsing, backslash · Issue #38 · whatwg/mimesniff () https://github.com/whatwg/mimesniff/issues/38

[382] MIME type parsing, duplicate parameters · Issue #41 · whatwg/mimesniff () https://github.com/whatwg/mimesniff/issues/41

[383] MIME type parsing, stricter rules · Issue #44 · whatwg/mimesniff () https://github.com/whatwg/mimesniff/issues/44

[387] MIME type parsing, code points · Issue #45 · whatwg/mimesniff () https://github.com/whatwg/mimesniff/issues/45

[388] Do separators need to be preserved when parsing? · Issue #39 · whatwg/mimesniff () https://github.com/whatwg/mimesniff/issues/39

[389] MIME type parsing, parameter canonicalization · Issue #46 · whatwg/mimesniff () https://github.com/whatwg/mimesniff/issues/46

[390] Define a new MIME type model, parser, and serializer (annevk著, ) https://github.com/whatwg/mimesniff/commit/cc81ec48288944562c4554069da1d74a71e199fb

[391] Revamp MIME type section by annevk · Pull Request #36 · whatwg/mimesniff () https://github.com/whatwg/mimesniff/pull/36

[392] Define data: URLs by annevk · Pull Request #579 · whatwg/fetch () https://github.com/whatwg/fetch/pull/579

[341] Editorial: tweak MIME type group definitions by domenic · Pull Request #59 · whatwg/mimesniff () https://github.com/whatwg/mimesniff/pull/59

[343] Editorial: update usage of the MIME Sniffing Standard (domenic著, ) https://github.com/whatwg/html/commit/fc82f4f8774a2e7e80f6c9477bd881f6c783b186

[344] Editorial: update usage of the MIME Sniffing Standard by domenic · Pull Request #3455 · whatwg/html () https://github.com/whatwg/html/pull/3455

[345] Provisional Standard Media Type Registry () https://www.iana.org/assignments/provisional-standard-media-types/provisional-standard-media-types.xml

<record date="2018-03-19">

<name>qpplication/wasm</name>

<org>W3C</org>

<xref type="person" data="Bradley_Nelson"/>

</record>

[354] Fix overrideMimeType() again (annevk著, ) https://github.com/whatwg/xhr/commit/121cee50b6f51215f046266642964b4c53a02a7c

[426] Look at overrideMimeType() again · Issue #157 · whatwg/xhr () https://github.com/whatwg/xhr/issues/157

[427] Fix overrideMimeType() again by annevk · Pull Request #174 · whatwg/xhr () https://github.com/whatwg/xhr/pull/174

[428] 918731 - XMLHttpRequest's overrideMimeType() does not follow the standard () https://bugzilla.mozilla.org/show_bug.cgi?id=918731

[429] Editorial: rewrite send()'s body/content-type processing (domenic著, ) https://github.com/whatwg/xhr/commit/f47bbab42dabe1f52e5e9f1ed1fa6df06a6eb310

[431] Correct Unicode reference for backslash (rwlbuis著, ) https://github.com/whatwg/mimesniff/commit/dc35803b66f96ccda3da53ab45819f592b0f9d6d

[432] Indicate correct unicode by rwlbuis · Pull Request #83 · whatwg/mimesniff () https://github.com/whatwg/mimesniff/pull/83