Content-Type Inspect

何をするツール？

Content-Type ヘッダーを分解し、MIMEタイプとパラメータ（charset/boundary など）を一覧表示します。

APIレスポンスやファイル配信の不具合切り分けに向きます。

Content-Type の基本

• MIMEタイプは「type/subtype」（例: application/json）です。
• charset は文字エンコーディングを指定します。
• multipart/form-data には boundary が必要です。

構文（読み方）

Content-Type は「MIMEタイプ; key=value; key=value...」の形です。先頭がMIMEタイプで、その後ろにパラメータが続きます。

• application/json; charset=utf-8
• text/html; charset=UTF-8
• multipart/form-data; boundary=----...

なぜMIMEタイプが重要？

MIMEタイプは、ブラウザやクライアントが「どう解釈するか」を決める重要なヒントです。間違うと表示/ダウンロード/パースが想定とズレます。

• APIがHTML（text/html）で返っている → 実はエラーページ
• JSONなのに charset が変で文字化けする

使いどころ

• JSONなのに text/html として返っている
• ファイルダウンロードが壊れる/文字化けする
• フォーム送信の boundary が合わずサーバーが解析できない

パラメータの例

• text/html; charset=UTF-8
• application/json; charset=utf-8
• multipart/form-data; boundary=----WebKitFormBoundary...

charset（文字コード）の考え方

テキスト系のレスポンス（text/* や HTML/CSVなど）では charset 指定が重要です。未指定だとクライアント側の推測に依存し、文字化けの原因になります。

• HTML: text/html; charset=UTF-8
• CSV: text/csv; charset=UTF-8

multipart と boundary

multipart/form-data はフォーム送信やファイルアップロードで使われます。boundary は本文の区切り文字列で、ヘッダーと本文が一致しないとサーバー側で解析できません。

• 手書きで組む場合、boundaryを本文にも反映する必要がある
• 通常はブラウザ/HTTPライブラリが自動生成する

よくある落とし穴

• charset が未指定で文字化けする
• MIMEタイプが間違っていてブラウザが誤解釈する
• boundary が一致せず multipart の解析に失敗する

切り分け手順（おすすめ）

• DevTools/ログから Content-Type をコピーして解析
• 期待するMIMEタイプ/charsetと一致しているか確認
• multipartならboundaryの有無と整合を確認

関連ツール

• HTTP Header Parser：ヘッダー一覧からContent-Typeを取り出す
• Request Headers Parser：送信側のContent-Type（フォーム送信など）確認
• JSON Formatter/JSONC Formatter：JSONの整形・検証

このツールでできること

• MIMEタイプの抽出
• charset/boundary などのパラメータ表示
• 入力の正規化と一覧化

注意（運用）

• 中継機器でヘッダーが書き換わることがあります。取得地点を揃えて比較してください。
• 最終判断はサーバーログと設定（信頼プロキシ、ルーティング）で確認してください。

参照仕様

• RFC 9110（HTTP Semantics）
• RFC 2045/2046（MIME）

FAQ

参考リンク

1. RFC 9110
2. RFC 2046
3. MDN: Content-Type
4. MDN: MIME types

次に見る（診断順）

site_map ルールに基づいて、次に確認すべきページを表示しています。

1. X-Content-Type-Options Inspect — X-Content-Type-Options を解析して nosniff を確認
2. Response Headers Parser — レスポンスヘッダーを構造化解析
3. HTTP Header Parser — 生ヘッダーを構造化して一覧化
4. Link Header Inspect — Link ヘッダーを解析して rel/as/type を確認
5. Security Headers Audit — 主要セキュリティヘッダーの有無を一括監査
6. nosniffでJS/CSSがブロックされる時の診断手順 — Content-Type と nosniff の不一致、404/302混入、配信経路の上書きを切り分ける
7. Response Headers系ツールの使い分け — Retry-After / Server-Timing / Link / Content-Type / nosniff を症状別に切り分ける
8. Set-Cookie Builder — 属性付き Set-Cookie ヘッダーを生成

同テーマの導線

レスポンスヘッダー診断

生ヘッダーから Retry-After / Server-Timing / Link / Content-Type を段階的に解析

• HTTP Header Parser — 生ヘッダーを構造化して一覧化
• Response Headers Parser — レスポンスヘッダーを構造化解析
• Set-Cookie Inspect — Set-Cookie 属性を解析して配布方針を確認
• Cookie Domain/Path Matcher — Domain/Path/Secure 条件でCookie送信可否を判定
• SameSite Cookie Simulator — SameSite と文脈からCookie送信可否をシミュレーション
• Set-Cookie Conflict Checker — 同名Cookie競合と上書きリスクを検出
• Cookie Size Checker — Cookie ヘッダーサイズを見積もり上限超過を点検
• Retry-After Inspect — Retry-After を解析して再試行待機を確認
• Server-Timing Inspect — Server-Timing を分解して遅延指標を確認
• Link Header Inspect — Link ヘッダーを解析して rel/as/type を確認
• X-Content-Type-Options Inspect — X-Content-Type-Options を解析して nosniff を確認
• HTTP Status Inspect — HTTPステータスコードを解析して対処方針を確認