Content-Type

Baseline Widely available

This feature is well established and works across many devices and browser versions. It’s been available across browsers since July 2015.

HTTP の Content-Type は表現ヘッダーで、コンテンツへのエンコードが適用される前の、リソースの元のメディア種別を示すために使用します。

レスポンスにおいては、 Content-Type ヘッダーはクライアントに返されたコンテンツの実際の種類を伝えます。 POST や PUT などのリクエストにおいては、クライアントは Content-Type ヘッダーを使用してサーバーに送信しようとしているコンテンツの種類を指定します。 サーバーの実装や設定がコンテンツの種類に関して厳密な場合、 415 クライアントエラーレスポンスが返る可能性があります。

Content-Type ヘッダーは Content-Encoding とは異なります。 Content-Encoding は、受信者がもとの形にデコードする方法を得るのに役立ちます。

メモ: この値は、ブラウザーがレスポンスに対して MIME スニッフィング（またはコンテンツスニッフィング）を行う場合に無視されることがあります。 ブラウザーが MIME スニッフィングを行うことを防止するためには、 X-Content-Type-Options ヘッダーの値を nosniff に設定してください。 詳しくは MIME タイプの検証を参照してください。

ヘッダー種別 表現ヘッダー
禁止ヘッダー名 いいえ
CORS セーフリストレスポンスヘッダー はい
CORS セーフリストリクエストヘッダー はい*

* 値には、CORS 危険リクエストヘッダーバイトである "():<>?@[\]{},、削除コード 0x7F、制御文字 0x00 から 0x19 （0x09 を除く）を含むことはできません。 また、 MIME タイプの解釈値（引数を除いたもの）が application/x-www-form-urlencoded, multipart/form-data, text/plain のいずれかである必要があります。

構文

Content-Type: <media-type>

例を示します。

http
Content-Type: text/html; charset=utf-8
Content-Type: multipart/form-data; boundary=ExampleBoundaryString

ディレクティブ

<media-type>

リソースやデータの MIME タイプです。 以下の引数を付けることができます。

  • charset: 標準で使用する文字エンコーディングを示します。 この値は大文字小文字を区別しませんが、小文字を推奨します。
  • boundary: 本文がマルチパートである場合、 boundary ディレクティブが必要です。 メッセージの複数の部分の境界を区切るために使用します。 これはさまざまなシステム（メールゲートウェイなど）を通過しても大丈夫だと知られている文字の中から 1～70 文字で構成されます（ホワイトスペースで終了しません）。 ふつう、ヘッダーの境界は 2 本のダッシュで始まり、最後の境界には最後にも 2 本のダッシュが入ります。

例

正しいコンテンツタイプで資産を提供

例えば、次の2つのレスポンスの例では、JavaScript および CSS の資産は、JavaScript では text/javascript を、CSS では text/css を使用して配信されます。 これらのリソースに正しいコンテンツタイプを入力することで、ブラウザーにそれらをより安全に、より高いパフォーマンスで処理してもらうことができます。 詳しくはサーバーで MIME タイプを正しく設定するを参照してください。

http
HTTP/1.1 200
content-encoding: br
content-type: text/javascript; charset=utf-8
vary: Accept-Encoding
date: Fri, 21 Jun 2024 14:02:25 GMT
content-length: 2978

const videoPlayer=document.getElementById...
http
HTTP/3 200
server: nginx
date: Wed, 24 Jul 2024 16:53:02 GMT
content-type: text/css
vary: Accept-Encoding
content-encoding: br

.super-container{clear:both;max-width:100%}...

HTML フォームにおける Content-Type

HTML フォームを送信する POST リクエストでは、リクエストの Content-Type は <form> 要素の enctype 属性で指定します。

html
<form action="/foo" method="post" enctype="multipart/form-data">
  <input type="text" name="description" value="Description input value" />
  <input type="file" name="myFile" />
  <button type="submit">Submit</button>
</form>

リクエストは次の例のようになります。簡潔にするために一部のヘッダーを除外しています。 リクエストでは、説明のために ExampleBoundaryString の境界を使用していますが、実際にはブラウザーは、このようにもっと長い ---------------------------1003363413119651595289485765 のような文字列を作成します。

http
POST /foo HTTP/1.1
Content-Length: 68137
Content-Type: multipart/form-data; boundary=ExampleBoundaryString

--ExampleBoundaryString
Content-Disposition: form-data; name="description"

Description input value
--ExampleBoundaryString
Content-Disposition: form-data; name="myFile"; filename="foo.txt"
Content-Type: text/plain

[content of the file foo.txt chosen by the user]
--ExampleBoundaryString--

URL エンコードのフォーム送信における Content-Type

フォームにファイルのアップロードが含まれず、よりシンプルなフィールドを使用している場合、フォームデータがリクエスト本体に記載される場合は、 URL エンコード方式のフォームの方が便利な場合があります。

html
<form action="/submit" method="post">
  <label for="comment">Comment:</label>
  <input type="text" id="comment" name="comment" value="Hello!" />
  <button type="submit">Submit</button>
</form>
http
POST /submit HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

comment=Hello!

REST API で JSON を使用した場合の Content-Type

多くの REST APIは、 application/json をコンテンツタイプとして使用しており、これはマシン間の通信やプログラムによる操作に便利です。 次の例は、リクエストが成功した結果を示す 201 Created レスポンスを示しています。

http
HTTP/1.1 201 Created
Content-Type: application/json

{
  "message": "New user created",
  "user": {
    "id": 123,
    "firstName": "Paul",
    "lastName": "Klee",
    "email": "p.klee@example.com"
  }
}

仕様書

Specification
HTTP Semantics
# status.206
HTTP Semantics
# field.content-type

ブラウザーの互換性

BCD tables only load in the browser

関連情報