= Technique title =
This technique gives hints to avoid problems with CategoryBpCharacterEncodingSupport.
Most web servers don't specify a character encoding for the resources they serve. For instance, they will serve .html files as "text/html", without specifying the "charset" parameter.
In absence of this parameter, a client will try find another way to get the character encoding of the said resource.
XML provides a well-defined character encoding declaration in the XML prolog <?xml version="1.0" encoding="iso-8859-1"?>, and has a well-defined default when such a declaration is not provided (utf-8 or utf-16). This applies in particular to XHTML served as application/xhtml+xml.
CSS has a system to declare its character encoding (using the @charset rule), but this is only in CSS2 and thus is not supported in the Default Delivery context; by default, resources served as text/css are assumed to be iso-8859-1 by the HTTP specification, which means if you don't override that information, your CSS won't be accepted in the default delivery context.
In practice, most CSS style sheets are compatible with UTF-8 since few CSS uses non-US-ASCII characters. To make sure your CSS gets analyzed properly:
if you can, get your CSS to be served with a Content-Type set to "text/css; charset=utf-8" (e.g. in Apache AddType .css text/css;charset=utf-8)
if you can't change the way the CSS are served, add a charset attribute to the link that include them into your pages: <link rel="stylesheet" href="example.css" charset="utf-8" />
Back to BestPracticesList