MIME / Content-Type リファレンス

MIME タイプリファレンスとは？#

MIME タイプ（メディアタイプや Content-Type とも）は、ドキュメントがどんなバイトを含むかを受信側に伝える短いラベルです — text/html は Web ページ、application/json は JSON データ、image/png は PNG 画像です。形式は常に type/subtype で、大分類、スラッシュ、固有名の順です。HTTP はこれらのラベルに依存して、レスポンスを描画、ダウンロード、解析、拒否のいずれにするか決めます。ブラウザは、適切なハンドラを選ぶために依存します（<img> は画像タイプを、<script> は JavaScript タイプを期待します）。メールはファイル添付のために依存します。

形式は単純に見えますが、現実の景観は紛らわしいものです。7 つのトップレベルカテゴリ（application、audio、font、image、model、text、video）があり、多くのファイルが複数の拡張子に一致し（.jpg、.jpeg、.jpe はすべて image/jpeg）、一部のタイプには古い形式とモダンな形式があり（application/javascript と text/javascript）、間違ったものを選ぶと現実のバグを引き起こします — text/plain で配信されたスタイルシートは適用されず、application/octet-stream で配信されたフォントは読み込まれません。本ページは、常に正しいラベルを選べる検索可能な参照表です。

使い方#

1. 何でも検索。 検索 ボックスが表全体を絞り込みます。3 つの問い方があります。
   • 先頭にドットを付けた ファイル拡張子 — .jpg、.woff2、.mp4 — で、その拡張子に対応するタイプだけが得られます。
   • タイプやサブタイプ そのもの — image、json、svg — で、名前で絞り込みます。
   • 単語 — archive、font、spreadsheet — で、解説文を検索します。
2. 行を読みます。 列は Content-Type（完全な type/subtype）、拡張子（それに対応する一般的なファイル接尾辞）、カテゴリ（7 つのトップレベルグループのいずれか）、説明（そのタイプの目的を 1 行で記したもの）です。
3. 正しいものを選びます。 ある拡張子には通常、正統なタイプが 1 つあります。2 つ存在する場合（JavaScript のケースが古典的）、解説がどちらが現行かを説明します。

主な機能#

• 7 カテゴリを 1 つの表に。 application、audio、font、image、model、text、video のタイプが一緒に並ぶため、ページを変えずにフォントの疑問から動画の疑問へ飛べます。
• 拡張子ファーストの検索。 現実のよくある作業は「.xlsx ファイルがあるが、Content-Type を何に設定すべきか？」です — .xlsx と打てば application/vnd.openxmlformats-officedocument.spreadsheetml.sheet に直接届きます。
• モダンな名前とレガシーな名前の両方。 古い形式が現実でまだ見られる場合、両方をメモ付きで収録するため、HTTP ヘッダーのどちら向きにも認識できます。
• ベンダータイプも収録。 Microsoft Office、ZIP、gzip、7z、RAR、WebAssembly、Web App Manifest、GraphQL — 長い application/vnd.* や application/*+json/application/*+xml 形式を網羅します。
• ローカルで瞬時。 データセットはページに組み込まれ、すべての検索はクライアント側のフィルタで、リクエストは発生しません。

実例#

JavaScript は最も紛らわしいエントリです。このタイプは長年名前が変わり、サーバーは今でも両方を送るためです。javascript で検索すると 2 行が得られます。

• text/javascript — js、mjs — 「標準のモダンな MIME タイプ。」
• application/javascript — js — 「レガシーな JavaScript MIME タイプ（今でも広く見られる）。」

短い結論: text/javascript が、現在の HTML と Fetch の標準が使うべきだと示すものであり、モダンなサーバーが出力するものです。application/javascript は古い RFC 4329 の名前で、今でも古い Content-Type ヘッダーや古いドキュメントに現れます。両者は同じ意味で、ブラウザは同じように扱います — ただし新しいサーバー設定では text/javascript を優先してください。

覚えておく価値のある検索がいくつかあります。いずれも 1 回の検索で手に入ります。

• .json → application/json
• .svg → image/svg+xml（画像だが、+xml 接尾辞が XML ベースであることを示す）
• .woff2 → font/woff2（application/ ではなく、専用の font/ トップレベルカテゴリに注意）
• .wasm → application/wasm（WebAssembly のバイナリ — charset なしで正確にこの通り配信しないとコンパイルされない）
• .pdf → application/pdf

タイプが不明な場合、サーバーは application/octet-stream にフォールバックします — 「何らかのバイナリデータで、何も想定しないで」という汎用タイプです。ブラウザは通常、それを表示しようとする代わりにダウンロードします。

よくある質問#

text/javascript と application/javascript のどちらを使うべきですか？#

新しいコードでは text/javascript を送ってください。それが現在の WHATWG HTML と Fetch の仕様が求めるものであり、ブラウザが <script> を実行するか決めるとき実際に照らし合わせるものです。application/javascript はどこでもまだ動きます（古い標準）が、レガシーな形式です。新しいサーバー、MIME データベース、ビルドツールを設定するなら、text/javascript を既定にしてください。

なぜ SVG のタイプには +xml が付いていますか？#

+xml 接尾辞は構造化構文接尾辞で、そのタイプの直列化が下層で XML であることを示します。つまり image/svg+xml は「画像であり、具体的には XML で記述されたもの」を意味します。同じ慣習が application/ld+json（リンクデータ、JSON で直列化）や application/graphql+json にも現れます。接尾辞を理解するツールは、汎用の XML や JSON パーサーにフォールバックできます。

application/octet-stream は何のためですか？#

「任意のバイナリデータ、タイプ不明」の総称です。サーバーはファイルを識別できないときこれを返し、安全なクライアントの振る舞いは、表示や実行を試みるよりダウンロードすることです。ブラウザで開くはずのファイルがダウンロードとして始まったことがあれば、それがふさわしい Content-Type の不在（octet-stream への崩れ）がよくある原因です。

ファイルの Content-Type は実際にどう設定しますか？#

ファイルがどこから配信されるかによります — 静的ファイルサーバーは MIME データベース経由で拡張子から読み取り、Web フレームワークはコード内で（多くは response.setContentType(...) やヘッダー割り当てで）設定し、CDN はアップロードやオブジェクトメタデータで公開します。スタックごとに呼び出しは異なりますが、正しくなければならないのは通信路上の最終的な文字列 1 つだけで、それこそが本ルックアップが与えるものです。