Wprowadzenie
Gecko 1.8, używane w Firefoksie 1.5 oraz innych aplikacjach, wprowadza wsparcie dla znaków non-ASCII w plikach JavaScript ładowanych z plików XUL.
Oznacza to, że pliki takiego skryptu mogą zawierać znaki języków z całego świata. Przykładowo poniższa linia:
var text = "Ein schönes Beispiel eines mehrsprachigen Textes: 日本語";
zawiera zarówno znaki niemieckie, jak i japońskie.
Wcześniejsze wersje zawsze interpretowały pliki JS ładowane z XUL jako ISO-8859-1 (Latin-1). Sekwencje ucieczki Unicode zawsze działały poprawnie, (jak przedstawiono poniżej).
Jak określa się kodowanie znaków w Gecko 1.8 oraz późniejszych
Podczas ładowania pliku JavaScript z adresu chrome://
zostaje użyty znacznik kolejności bajtów (Byte Order Mark - BOM) w celu określenia kodowania znaków w skrypcie. W przeciwnym razie zostanie użyte kodowanie znaków takie samo co w plikach XUL (określone za pomocą atrybutu encoding
znacznika <?xml?>
). Domyślnie jest to kodowanie UTF-8 reprezentujące wszystkie znaki języków na świecie.
Jeśli plik skryptu ładowany jest poprzez HTTP, to nagłówek HTTP może zawierać deklarację kodowania znaków zawartą w części Content-Type
, na przykład:
Content-Type: application/x-javascript; charset=UTF-8
Jeśli żaden parametr nie został określony obowiązują powyższe zasady.
Kompatybilność wersji
Jeśli chcesz, by ten sam kod działał w Gecko 1.8 oraz wersjach wcześniejszych, musisz ograniczyć się do znaków ASCII. Jednakże możesz użyć sekwencji ucieczki – powyższy przykład przepisany za ich pomocą będzie wyglądał następująco:
var text = "Ein sch\u00F6nes Beispiel eines mehrsprachigen Textes: \u65E5\u672C\u8A9E";
Alternatywą może być użycie plików własności poprzez nsIStringBundle lub element XUL <stringbundle>; umożliwi to lokalizację XUL. Sposób ten nie może być użyty w plikach XUL ładowanych z sieci, a jedynie w uprzywilejowanym kodzie - na przykład w rozszerzeniach.