Christopher Schultz: > The problem is when the web server sends a response, it sends it using a > particular character set (let's just say UTF8 for argument's sake). If > you also report that the character set is UTF8 in the META tags, then > it's only valid if the client saves the file to the disk with that same > character encoding. If a different encoding is being used, then the file > is "lying" about its own encoding.
Agreed, a wrong charset in a meta tag is brain-dead. Nevertheless, one should keep in mind the charset reported in meta tags is in practice *not* *only* used when the file is read from disk. Firefox 3, IE 7 and Opera use the charset from the meta tag if the server doesn't add a charset to the value of the Content-Type response header field (Tomcat's DefaultServlet doesn't, for example). BTW: Although the behaviour of the browsers does comply with the HTML 4 W3C recommendation you cited in an earlier post, they, IMO, violate RFC 2616 (HTTP/1.1) which says in section 3.7.1 that a missing charset in the Content-Type header field means that the content is encoded in ISO-8859-1 (for text/* media types, of course) - and the DefaultServlet violates the RFC too. Regards mks --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
