Keith Devens .com - Weblog: Understanding charsets on the web

Friday, February 11, 2005

Understanding charsets on the web

Sam Ruby: Meta Charset Update. Anyone who wants to understand charset issues on the web should go through most of what he links. The main thing I took away is that the charset specified in HTTP has primacy. And that makes sense. Since that makes sense, and since things seem to be working the right way most of the time, what Mark Pilgrim had to say last year doesn't seem so bad.

Permalink | 5 Comments | Tags: linkblog, Programming | id 6520

11:39 (utc-5)
edited: 11:39 (utc-5)

Comments

I wish things were so clear. In fact, the W3C recommends otherwise for XML.

And when you factor in web browsers that are broken, you end up doing like http://www.google.com/ does, which is to omit the charset for HTML and put it in the meta tag.

Well, that makes sense too. HTTP has primacy but if you don't specify the charset at the protocol level it defers to the content. Though, I didn't know that they recommend not using text/xml for XML... so, it seems we should all be using application/xml by default .

As for how Google does it -- that doesn't bother me too much since we're not dealing with logical inconsistencies, merely implementation bugs. But the W3C's recommendations for XML presumably apply to XHTML as well, so I suppose that implies we should all be specifying the charset only in the (X)HTML anyway?

∴ Keith | 11-Feb-2005 1:19pm est | http://keithdevens.com/ | #6988

What is wrong with using application/xml by default? text/xml has issues and will be deprecated eventually.

Those W3C recommendations seem a bit weird. Not sure why they do that. I'm also not sure since when the W3C is the authority to advice people on what to do on the HTTP level.

Nothing's wrong with application/xml by default. It's just that it's like, "Now you're telling us?". If text/xml is no good I'd have preferred they never created it. Now I have to change my code, and what's worse is that I don't know if there are any compatibility issues between text/xml vs. application/xml. For example, will anyone have a problem if I start serving my RSS feed as application/xml instead of text/xml?^[1] So, because I don't know, I'll have to check accept headers for application/xml and serve text/xml as a fallback.

Plus, if text/xml has problems and will be deprecated eventually, why isn't it deprecated now? That's what deprecated means. It doesn't make sense for anything to be in the position of "going to be deprecated".

Footnotes:
[1]: And XML-RPC? Though, XML-RPC is always POST, so maybe the issues with text/xml don't matter?

∴ Keith | 11-Feb-2005 6:12pm est | http://keithdevens.com/ | #6991

There are no problems. application/xml is accepted as well. It just is that text/xml has a default charset of US-ASCII and application/xml does not. (Default is UTF-8.)

Feel free to post a comment below. Please see my comment policy.

Formatting Rules (No HTML):

**bold**, *italic*, _underlined_, --strikeout--
"text"="url" creates a link, and URLs are auto-highlighted
Blockquote: Like e-mail, begin paragraph with > (greater-than sign)
Lists: begin paragraph with *,-, or + (unordered), or # (ordered)
Code block: ?!code:language=perl|php|sql|javascript|etc.{\n}...{\n}?!/code

RSS feed RSS feed for Keith's Weblog
Atom feed Atom feed for Keith's Weblog
Weblog archive
Recent comments
on 3 posts