This means that such script files can use any character from almost any language of the world. For example, they can contain a line:
var text = "Ein schönes Beispiel eines mehrsprachigen Textes: 日本語";
This mixes German and Japanese characters.
Earlier versions always interpreted JS files loaded from XUL as ISO-8859-1 (Latin-1) characters. (Unicode escapes, as discussed below, have always worked.)
How the character encoding is determined
chrome:// URL as part of an extension. In such a case, if a Byte Order Mark is used, it determines the character set of the script. Otherwise, the character encoding will be the same as the one used by the XUL file (which can be specified using an
encoding attribute in the
<?xml?> element). By default this will use UTF-8, which can represent almost all characters in the world.
If the script file is loaded from HTTP, the HTTP header can contain a character encoding declaration as part of the
Content-Type header, for example:
If no charset is specified, the same rules as above apply.
If you want the same code to work in both Gecko 1.8 and earlier versions, you must limit yourself to ASCII. However, you can use unicode escapes – the earlier example rewritten using them would be:
var text = "Ein sch\u00F6nes Beispiel eines mehrsprachigen Textes: \u65E5\u672C\u8A9E";
An alternative might be to use property files via nsIStringBundle or the XUL <stringbundle> element; this would allow for localization of the XUL. This can not be done in XUL files loaded from the web, only in privileged code, e.g. in extensions.