Character Encoding

Unicode and Other Character Sets

The default character set for XML, XHTML, and HTML 4.0 documents is Unicode (http://www.w3.org/International/O-unicode.html), a standard defined, oddly enough, by the Unicode Consortium (www.unicode.org). Unicode is a comprehensive character set that provides a unique number for every character, "no matter what the platform, no matter what the program, no matter what the language." Unicode is thus the closest thing we have to a universal alphabet, although it is not an alphabet but a numeric mapping scheme.

Even though Unicode is the default character set for web documents, developers are free to choose other character sets that might be better suited to their needs. For instance, American and Western European websites often use ISO-8859-1 (Latin-1) encoding. You might be asking yourself what Latin-1 encoding means, or where it comes from. Okay, to be honest, you're not asking yourself any such thing, but we needed a transition, and that was the best we could do on short notice.

What Is ISO 8859?

ISO 8859 is a series of standardized multilingual single-byte coded (8 bit) graphic character sets for writing in alphabetic languages, and the first of these character sets, ISO-8859-1 (also called Latin-1), is used to map Western European characters to Unicode. ISO 8859 character sets include Latin-2 (East European), Turkish, Greek, Hebrew, and Nordic, among others.

The ISO 8859 standard was created in the mid-1980s by the European Computer Manufacturer's Association (ECMA) and endorsed by the International Standards Organization (ISO). Now you know.

Mapping Your Character Set to Unicode

Regardless of which character set you've chosen, to map it to the Unicode standard, you must declare your character encoding, as discussed in the second rule of XHTML presented earlier. (You see, there was a point to all this.) Sites can declare their character encoding in any of three ways:

• A server administrator ("systems guy") might set the encoding via the HTTP headers returned by the web server. The W3C recommends this approach, but it is rarely followed—maybe because systems guys would rather play networked games than muck around with HTTP headers. Come to think of it, who wouldn't?
• For XML documents (including XHTML), a designer/developer might use the optional XML prolog to specify the encoding. This, too, is a W3C recommendation, but until more browsers learn to handle it properly, we can't recommend it.
• In HTML or XHTML documents, a designer/developer might also specify the encoding via the "Content-Type" meta element. As opposed to the server administrator method (which fails when the server administrator forgets to do his job) and the XML prolog method (which fails when browsers choke on it), the "Content-Type" method can be counted on to work. That is the approach we recommended earlier in this chapter. Now you know why.