MIMEタイプ参照

MIMEタイプ（Multipurpose Internet Mail Extensions）は、ドキュメント、ファイル、バイトストリームの性質と形式を示すインターネット標準です。ブラウザとサーバーはMIMEタイプを使用してコンテンツの処理方法を決定します。例えば、image/jpegを受信するとブラウザは画像を表示し、application/pdfはPDFプレビューを開く可能性があります。正しいMIMEタイプの設定はWebアプリケーションの正常な動作に不可欠です。

MIMEタイプ（Multipurpose Internet Mail Extensions）は、データ形式の標準化された識別子であり、もともとはRFC 2045/RFC 2046で電子メール添付ファイル向けに定義され、後にHTTP（RFC 7231 §3.1.1.5）でWebコンテンツネゴシエーションに採用された。MIMEタイプは type/subtype の構造を持ち、type は大カテゴリ（text、image、audio、video、application、multipart、font、model）を宣言し、subtype は正確な形式を指定する（例：text/html、image/png、application/json）。オプションのパラメータはセミコロンの後に続く（text/html; charset=utf-8）。 Internet Assigned Numbers Authority（IANA）は iana.org/assignments/media-types で公式MIMEタイプレジストリを維持している。登録はRFC 6838に従い、仕様ドキュメント、セキュリティ上の考慮事項、相互運用性ノートが必要なレビュープロセスを経る。未登録タイプは x- プレフィックス（例：application/x-tar）を使用できるが、これは実験的またはベンダー固有のフォーマットの慣例であり、RFC 6648では適切な登録を優先し x- プレフィックスの回避を推奨している。 HTTPでは、Content-Typeヘッダーがクライアントにレスポンスボディの解釈方法を伝える。サーバーが Content-Type: image/svg+xml を返すとブラウザはSVGレンダラーを起動し、Content-Type: application/octet-stream はブラウザがフォーマットを判別できないためダウンロードプロンプトを表示する。ブラウザはMIMEスニッフィングでもMIMEタイプ情報を活用する。サーバーがContent-Typeを省略したり汎用タイプを送信したりした場合、ブラウザはレスポンスの先頭数バイト（マジックバイト）を調査して実際のフォーマットを推測することがある。この動作は X-Content-Type-Options: nosniff ヘッダーで制御でき、スニッフィングを無効化してサーバーに正しいタイプの宣言を義務付ける。 ファイルアップロードでは、Acceptヘッダーがサーバーにクライアントが期待するMIMEタイプを伝え、input要素のaccept属性はファイルピッカーを特定タイプに制限する（例：accept="image/png, image/jpeg"）。サーバー側では、アップロードされたファイルを宣言されたMIMEタイプとファイル署名（マジックバイト）の両方で検証すべきである。どちらも単独では信頼できないためだ。image.png という名前で Content-Type: image/png のファイルに実行可能なコードが含まれている可能性がある。本ツールは、与えられたファイル拡張子に対する正規のMIMEタイプを検索するリファレンスとして、8カテゴリにわたる100以上の一般的なフォーマットをカバーしている。

• RFC 2046構造：type/subtype — typeは大カテゴリを示し、subtypeは正確な形式を示す。オプションパラメータはセミコロンの後に続き（text/html; charset=utf-8）、仕様上は大文字小文字を区別しないが、慣例として小文字が使用される。
• IANA登録（RFC 6838）：新しいメディアタイプには仕様ドキュメント、セキュリティ上の考慮事項セクション、相互運用性ノートが必要。レビュープロセスにより、タイプが十分に文書化され、レジストリ登録前に競合が回避されることが保証される。
• HTTP Content-Typeヘッダー：サーバーはレスポンスボディのMIMEタイプを宣言し、ブラウザはそれに基づいて適切なレンダラー（HTMLパーサー、画像デコーダー、PDFビューアー）を選択するかダウンロードを開始する。誤ったContent-Typeは「ファイルが表示されずにダウンロードされる」バグの最も一般的な原因。
• MIMEスニッフィングとX-Content-Type-Options：Content-Typeが欠落しているか汎用の場合、ブラウザはマジックバイトを調査してフォーマットを推測することがある。X-Content-Type-Options: nosniffはこの動作を無効化し、正確なContent-Typeの一致を要求する。これはセキュリティ上のベストプラクティス。
• application/octet-stream：汎用バイナリフォールバックタイプ。ブラウザは不透明なストリームとして扱いダウンロードを開始するため、サーバーがフォーマットを判別できない場合に最も安全なデフォルトとなるが、本来表示可能なコンテンツのブラウザ内プレビューが不可能になる。
• ファイルアップロード検証：inputのaccept属性はクライアント側でファイルピッカーをフィルタリングするが、サーバー側の検証では宣言されたContent-Typeとファイルのマジックバイトの両方を確認する必要がある。拡張子、MIMEタイプ、ファイル署名の不一致は悪意あるアップロードの危険信号。
• ベンダー固有および実験的タイプ：x-プレフィックス慣例（application/x-tar、video/x-matroska）は正式な登録プロセスに先行するもの。RFC 6648では可能な限りIANA登録済みタイプへの移行を推奨しているが、多くのタイプが広く使用され続けている。