MIMEタイプ リファレンス

MIMEタイプとは何か

MIMEタイプはメディアタイプとも呼ばれ、ファイルやメッセージ本文にどのような種類のデータが含まれているかをソフトウェアに伝える短いラベルです。元はメール（名称はMultipurpose Internet Mail Extensionsの略）から生まれましたが、今日ではウェブのあらゆる場所に登場します。形式は常に type/subtype です。大きなカテゴリ、スラッシュ、そして具体的なフォーマットで構成されます。text/html は「テキスト、HTML形式」、image/png は「画像、PNG形式」、application/json は「アプリケーションデータ、JSON形式」を意味します。

最上位のタイプは、IANAの公式レジストリが管理する固定セットから選ばれます。text、image、audio、video、application、font、model、multipart、そして haptics のような新しいものも含まれます。サブタイプは具体的なフォーマットです。ベンダーは vnd. プレフィックスを付けて独自のサブタイプを追加できます（例：application/vnd.ms-excel）。また、実験的なタイプには歴史的に x- プレフィックスが使われてきましたが、この慣例は現在では推奨されていません。

MIMEタイプが重要な場面

MIMEタイプが最も重要な場面はHTTPの Content-Type レスポンスヘッダーです。サーバーがページ・画像・APIのデータを送信する際、このヘッダーがブラウザにバイトの解釈方法を伝えます。ヘッダーが text/html であればブラウザはマークアップをレンダリングし、application/json であれば fetch() 呼び出しでパースでき、application/pdf であれば内蔵のビューアーが開きます。同じヘッダーはリクエスト側にも送られます。フォームやAPIボディをPOSTするとき、Content-Type はサーバーに送信内容の読み方を伝えます。

HTTPの外でも、MIMEタイプはいくつかのシステムを動かしています。メールクライアントはそれを使って、添付ファイルをプレビューする画像として扱うか、保存するバイナリとして扱うかを判断します。ファイルアップロードハンドラーは宣言されたタイプを検査してファイルを受け入れるか拒否するかを決めます。オペレーティングシステムやブラウザは、ファイル拡張子だけでなくタイプを使ってデフォルトのアプリケーションを選択します。同じ考え方は、サーバーがHTTPステータスコードと並行して結果やエラーを報告する仕組みにも通じています。正しくない Content-Type を持つ200レスポンスは、404と同様に壊れた状態と言えます。

日常的に使うもの

実際のトラフィックの大部分を占めるのは、ごくわずかなタイプです。

• text/html — ウェブページ（拡張子 .html）
• text/css — スタイルシート（.css）
• text/javascript — JavaScriptの推奨タイプ（.js、.mjs）
• application/json — RFC 8259で定義された唯一の公式JSONタイプ（.json）
• image/png、image/jpeg、image/webp、image/svg+xml — 一般的な画像形式
• application/pdf — PDFドキュメント（.pdf）
• application/octet-stream — 不明または任意のバイナリデータのキャッチオール
• text/plain — より具体的なタイプを持たないプレーンテキストのデフォルト

JSONについては注意が必要です。正しいタイプは application/json のみです。古いコードでは text/json、text/plain、application/x-javascript が使われることがありますが、これらは廃止されており、一部のクライアントはパースを拒否します。JSONにcharsetパラメーターも不要です。仕様によりUTF-8が義務付けられているため、application/json; charset=utf-8 と記述しても冗長なだけで無害です。形式と拡張子のより詳しい一覧は、参照テーブルをご覧ください。

Content-Typeが間違っているとなぜ問題が起きるか

ブラウザとクライアントは宣言されたタイプを信頼するため、誤ったタイプは具体的な問題を引き起こします。JSON APIのレスポンスを text/html として送信すると、ブラウザがレンダリングしようとするか、厳格なクライアントがコードの実行前にパースエラーを投げる可能性があります。CSSやJavaScriptファイルを間違ったタイプで送信すると、X-Content-Type-Options: nosniff というセキュリティ機能によってブラウザがそれを適用することを拒否し、ページのスタイルやスクリプトが静かに壊れます。

ダウンロードも典型的な失敗パターンです。ファイルを表示するのではなくダウンロードさせたい場合、タイプは Content-Disposition ヘッダーとともに重要です。application/octet-stream として送られたPDFは汎用ファイルとしてダウンロードされ、ビューアーで開かれません。text/plain として送られた画像は文字化けして表示されます。アップロード側では、ラベルを誤ったファイルが単純な拡張子チェックを通過してしまう可能性があります。そのため、堅牢なバリデーターはクライアントが提供するタイプを信頼せず、実際のバイト（マジックナンバー）を検査します。

歴史的に、ブラウザはヘッダーが正しくないように見えるときに実際のタイプを推測（「スニッフィング」）しようとしていました。この動作がセキュリティホールを引き起こしたため、現代のベストプラクティスは常に正確な Content-Type を送信し、nosniff でスニッフィングを無効にすることです。端的に言えば、すべてのレスポンスにタイプを意図的に設定すれば、レンダリング・ダウンロード・パースのバグのほとんどは解消されます。

よくある質問