Please note, this is a STATIC archive of website developer.mozilla.org from 03 Nov 2016, cach3.com does not collect or store any user information, there is no "phishing" involved.

Revision 1106855 of Accept-Charset

  • Revision slug: Web/HTTP/Headers/Accept-Charset
  • Revision title: Accept-Charset
  • Revision id: 1106855
  • Created:
  • Creator: teoli
  • Is current revision? No
  • Comment

Revision Content

{{HTTPSidebar}}

The Accept-Charset request HTTP header advertises which character set the client is able to understand Using content negotiation, the server then selects one of the proposal, use it and inform the client of its choice within the {{HTTPHeader("Content-Type")}} response header. Browser usually don't set this header as the default value defined for each content type is usually correct and transmitting it would allow for easier fingerprinting.

If the server cannot serve any matching language, it can theoretically send back a {{HTTPStatus("406")}} Not Acceptable error code. But, for UX reasons, this is rarely done and the standard way is to ignore the Accept-Charset header in this case.

In early versions of HTTP/1.1, a default charset (ISO-8859-1) was defined. This is no more the case and now each content type may have its own default.

Header type {{Glossary("Request header")}}
{{Glossary("Forbidden header name")}} yes

Syntax

Accept-Charset: <charset>

// Multiple types, weighted with the q-factor syntax:
Accept-Language: utf-8, iso-8859-1;q=0.5

Directives

<charset>
A character set like utf-8 or iso-8859-15
*
Any charset no mentioned elsewhere in the header; '*' being used as a wildcard.
;q= (q-factor weighting)
Any value used is placed in an order of preference expressed using relative quality factor called the weight.

Examples

Accept-Charset: iso-8859-1

Accept-Charset: utf-8, iso-8859-1;q=0.5

Accept-Language: utf-8, iso-8859-1;q=0.5, *;q=0.1

Specifications

Specification Title
{{RFC("7231", "Accept-Charset", "5.3.3")}} Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context

Browser compatibility

{{Compat}}

See also

  • HTTP content negotiation
  • Header with the result of the content negotiation: {{HTTPHeader("Content-Type")}}
  • Other similar headers: {{HTTPHeader("TE")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Language")}}, {{HTTPHeader("Accept")}}

Revision Source

<div>{{HTTPSidebar}}</div>

<p>The <strong><code>Accept-Charset</code></strong> request HTTP header advertises which character set the client is able to understand Using <a href="/en-US/docs/Web/HTTP/Content_negotiation">content negotiation</a>, the server then selects one of the proposal, use it and inform the client of its choice within the {{HTTPHeader("Content-Type")}} response header. Browser usually don't set this header as the default value defined for each content type is usually correct and transmitting it would allow for easier fingerprinting.</p>

<p>If the server cannot serve any matching language, it can theoretically send back a {{HTTPStatus("406")}} <code>Not Acceptable</code> error code. But, for UX reasons, this is rarely done and the standard way is to ignore the <code>Accept-Charset</code> header in this case.</p>

<div class="note">
<p>In early versions of HTTP/1.1, a default charset (<code>ISO-8859-1</code>) was defined. This is no more the case and now each content type may have its own default.</p>
</div>

<table class="properties">
 <tbody>
  <tr>
   <th scope="row">Header type</th>
   <td>{{Glossary("Request header")}}</td>
  </tr>
  <tr>
   <th scope="row">{{Glossary("Forbidden header name")}}</th>
   <td>yes</td>
  </tr>
 </tbody>
</table>

<h2 id="Syntax">Syntax</h2>

<pre class="syntaxbox">
Accept-Charset: &lt;charset&gt;

// Multiple types, weighted with the q-factor syntax:
Accept-Language: utf-8, iso-8859-1;q=0.5</pre>

<h2 id="Directives">Directives</h2>

<dl>
 <dt><code>&lt;charset&gt;</code></dt>
 <dd>A character set like <code>utf-8</code> or <code>iso-8859-15</code></dd>
 <dt><code>*</code></dt>
 <dd>Any charset no mentioned elsewhere in the header; <code>'*'</code> being used as a wildcard.</dd>
 <dt><code>;q=</code> (q-factor weighting)</dt>
 <dd>Any value used is placed in an order of preference expressed using relative <a href="/en-US/docs/Glossary/Q-factor">quality factor</a> called the <em>weight</em>.</dd>
</dl>

<h2 id="Examples">Examples</h2>

<pre>
Accept-Charset: iso-8859-1

Accept-Charset: utf-8, iso-8859-1;q=0.5

Accept-Language: utf-8, iso-8859-1;q=0.5, *;q=0.1
</pre>

<h2 id="Specifications">Specifications</h2>

<table class="standard-table">
 <tbody>
  <tr>
   <th scope="col">Specification</th>
   <th scope="col">Title</th>
  </tr>
  <tr>
   <td>{{RFC("7231", "Accept-Charset", "5.3.3")}}</td>
   <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context</td>
  </tr>
 </tbody>
</table>

<h2 id="Browser_compatibility">Browser compatibility</h2>

<p class="hidden">The compatibility table in this page is generated from structured data. If you’d like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data/README.md">https://github.com/mdn/browser-compat-data/README.md</a> and send us a pull request.</p>

<p>{{Compat}}</p>

<h2 id="See_also">See also</h2>

<ul>
 <li>HTTP <a href="/en-US/docs/Web/HTTP/Content_negotiation">content negotiation</a></li>
 <li>Header with the result of the content negotiation: {{HTTPHeader("Content-Type")}}</li>
 <li>Other similar headers: {{HTTPHeader("TE")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Language")}}, {{HTTPHeader("Accept")}}</li>
</ul>
Revert to this revision