Take the 2-minute tour ×
Webmasters Stack Exchange is a question and answer site for pro webmasters. It's 100% free, no registration required.

I have a HTML page that correctly (the encoding of the physical on disk matches it) announces it's Content-Type:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta http-equiv="Content-Type" content=
    "text/html; charset=utf-8">
    <title> ...

Opening the file from disk in browser (Google Chrome, Firefox) works fine.

Requesting it via HTTP, the webserver sends a different Content-Type header:

$ curl -I http://example.com/file.html
HTTP/1.1 200 OK
Date: Fri, 19 Oct 2012 10:57:13 GMT
...
Content-Type: text/html; charset=ISO-8859-1

(see last line). The browser then uses ISO-8859-1 to display which is an unwanted result.

Is there a common way to override the server headers send to the browser from within the HTML document?

share|improve this question

3 Answers 3

up vote 6 down vote accepted

"Is there a common way to override the server headers send to the browser from within the HTML document?"

AFAIK no, you do what you can do already. The defined charset via Header trumps your definition in the META tag.

If you have access to the server, e.g. Apache, it is configured by this statement (see the comment lines):

# Read the documentation before enabling AddDefaultCharset.
# In general, it is only a good idea if you know that all your files
# have this encoding. It will override any encoding given in the files
# in meta http-equiv or xml encoding tags.

#AddDefaultCharset UTF-8

[Update]

To second w3d's comment here you'll find some ways to change the charset via htaccess-Directives for the Apache server.

share|improve this answer
2  
+1 HTTP headers override HTML meta tags. If @hakre has access to the server-side then they could also override the Content-Type header on a per page basis. –  w3d Oct 19 '12 at 11:48
3  
Right, here’s the normative reference that specifies that HTTP headers trump meta tags: w3.org/TR/REC-html40/charset.html#h-5.2.2 –  Jukka K. Korpela Oct 19 '12 at 14:05
    
Thanks for the answer. @Korpela: Yes, I had that in memory with the HTML specs. It's exactly the other way round as I need it :(. –  hakre Oct 19 '12 at 14:09
    
Regarding .htaccess (sorry, this maybe should be a new question instead), is it possible to remove the ;charset=... from the http header as well. The site works very well with Content-Type: text/html, different files have different encodings on the server. (I fear this is not possible, too, because I think I did look for that some weeks ago but the outcome was not quite final). Just in case you can shed some light right ahead. –  hakre Oct 19 '12 at 14:12
    
@hakre If the ForceType Directive of Apache works for you, place it into a <Files> Container and individually name files or certain directories. Just leave the ";charset=" part after the mime type then, this should do it. –  initall Oct 19 '12 at 14:41

You should set something like this in your root .htaccess

<FilesMatch "\.(htm|html|xhtml|xml|php)$">
    AddDefaultCharset utf-8
</FilesMatch>
share|improve this answer

No, it's not possible from within the HTML. The servers response header take precedence over the document's meta-tag. As it's specified in 5.2.2 Specifying the character encoding - HTML 4.01 Specification :

To sum up, conforming user agents must observe the following priorities when determining a document's character encoding (from highest priority to lowest):

  1. An HTTP "charset" parameter in a "Content-Type" field.
  2. A META declaration with "http-equiv" set to "Content-Type" and a value set for "charset".
  3. The charset attribute set on an element that designates an external resource.

So this requires configuration on the server-side. However as the chapter continues:

User agents may provide a mechanism that allows users to override incorrect "charset" information. However, if a user agent offers such a mechanism, it should only offer it for browsing and not for editing, to avoid the creation of Web pages marked with an incorrect "charset" parameter.

In my case the the server's Content-Type header contains the right mime-type but the wrong charset.

As it turned out, my Apache httpd configuration had set the AddDefaultCharset turned on which was adding the ; charset=ISO-8859-1 part. Placing into the websites root directory .htaccess the following line:

AddDefaultCharset Off

the charset information was removed:

$ curl -I http://example.com/file.html
HTTP/1.1 200 OK
Date: Fri, 19 Oct 2012 15:07:52 GMT
...
Content-Type: text/html

(see last line, no ; charset=... part). This in combination with the html meta-tag triggers the said browser heuristics to take over the charset from the meta tag. The website is properly decoded.

Tested with:

  • Google Chrome v. 22.0.1229.94
  • Firefox v. 16.0.1
  • Lynx Version 2.8.7rel.1 (05 Jul 2009)

These three browsers had problems with the original configuration and work now (all on Fedora 17).

  • Opera 12.02
  • Internet Explorer 6 (Win XP SP3)

Didn't have the problem in the first place. Both were preferring UTF-8 from the meta-tag over the ISO-8859-1 setting from the server.

  • Netscape 2.01 Gold

Does not support UTF-8 so is always choosing Western(Latin1) regardless of the server setting and the meta-tag.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.