Accept Header Builder

入力値の整形・変換・判定をブラウザ内で実行します。入力はサーバーへ送信しません。形式差分の一次切り分けに使えます。

状態

ブラウザ内で処理します。入力はサーバーへ送信しません。まずはここで一次切り分けしてください。

使い方

各項目を入力して「生成」。作ったヘッダー値をクライアント設定やテスト用リクエストに貼り付けて挙動差分を確認します。

注意（このツール）

  • 最終的な優先順位はサーバー実装とコンテンツネゴシエーション設定に依存します。
  • Accept-Language の q 値は相対優先度です。同値が並ぶと実装差が出る場合があります。

このページについて

何をするツール？

Accept / Accept-Language / Accept-Encoding をまとめて組み立て、HTTPリクエストに貼り付けられる形で出力します。

推奨（実務）

  • 用途が限定的なら Accept を絞る
  • 言語は q 値で優先度を明示
  • 圧縮は br/gzip を優先

用途別の考え方

  • APIクライアント: Accept を JSON中心に限定し、想定外MIMEを減らす
  • 多言語UI: Accept-Language は上位2〜3候補に絞り、q値で順序を明示する
  • 圧縮検証: Accept-Encoding はサーバー実装に合わせ、Content-Encoding と対で確認する
  • Accept-Language Inspect
  • Accept-Encoding Inspect

このツールでできること

  • Accept 系ヘッダーの生成
  • q 値の付与

注意点

  • Accept は広げすぎると、サーバー側の既定値で意図しない表現が返ることがあります。
  • ネゴシエーション不具合の切り分けでは、Vary ヘッダーとセットで確認してください。

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

  • 対象データを貼り付ける
  • 変換・整形・判定結果を確認する
  • 区切り文字/文字コード/paddingを確認する

参照仕様

  • RFC 9110（Accept / Accept-Language / Accept-Encoding）
  • RFC 9110（Quality Values）

FAQ

q値は必須ですか？

必須ではありません。優先順を明示したい場合に使います。

Accept を広くしすぎると何が起きますか？

意図しない表現（MIME）が返る可能性があり、デバッグが難しくなります。

参考リンク

  1. RFC 9110

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

  1. Accept-Language Inspect — Accept-Language を解析して言語優先順位を確認
  2. Content-Language Inspect — Content-Language を解析して配信言語を確認
  3. Accept-Charset Inspect — Accept-Charset を解析して文字コード要求を確認

言語/ロケール

Accept系とContent-Languageを照合してネゴシエーション不整合を確認