mozilla
Vos résultats de recherche

    Caractères internationaux dans du JavaScript XUL

     

    Introduction

    Gecko 1.8, qui est utilisé dans Firefox 1.5 et d'autres applications, a ajouté un support pour les caractères non-ASCII dans les fichiers JavaScript chargés depuis des fichiers XUL.

    Cela signifie que de tels fichiers de script sont capables d'utiliser virtuellement tous les caractères de n'importe quelle langue dans le monde. Par exemple, ils pourraient contenir une ligne :

    var text = "Ein schönes Beispiel eines mehrsprachigen Textes: 日本語";
    

    Celle-ci mélange des caractères allemands et japonais.

    Les versions précédentes interprétaient toujours les fichiers JS chargés depuis XUL en ISO-8859-1 (Latin-1) aussi bien en local qu'en fichiers distants. Les échappements Unicode, comme expliqué ci-dessous, ont toujours fonctionné.

    Comment l'encodage des caractères est déterminé depuis Gecko 1.8

    Lorsque le fichier JavaScript est chargé depuis une URL chrome://, un Byte Order Mark) est utilisé pour déterminer l'encodage des caractères du script. Autrement, l'encodage sera le même que celui utilisé par le fichier XUL (et spécifié par l'attribut encoding dans la balise <?xml?>). Par défaut, l'encodage sera l'UTF-8 qui peut représenter virtuellement l'ensemble des caractères dans le monde.

    Si le fichier de script est chargé via HTTP, l'en-tête HTTP peut contenir une déclaration d'encodage de caractères comme faisant partie de Content-Type, par exemple :

    Content-Type: application/x-javascript; charset=UTF-8
    

    Si aucun paramètre charset n'est spécifié, les mêmes règles que précédemment sont appliquées.

    Compatibilité inter-versions

    Si vous voulez que le même code fonctionne à la fois avec Gecko 1.8 et ses versions antérieures, vous devez vous limiter à l'ASCII. Toutefois, vous pouvez employer les échappements unicode. Le précédent exemple réécrit deviendrait :

    var text = "Ein sch\u00F6nes Beispiel eines mehrsprachigen Textes: \u65E5\u672C\u8A9E";
    

    Une alternative serait d'utiliser des fichiers de propriétés via nsIStringBundle ou l\'élément XUL <stringbundle> ; ils permettent la localisation du XUL. Ce n'est toutefois pas permis dans des fichiers XUL chargés depuis le Web mais seulement dans un code avec privilèges, c'est-à-dire dans des extensions.

    Étiquettes et contributeurs liés au document

    Contributors to this page: fscholz, Mgjbot, Chbok, Electrolysis, BenoitL, teoli
    Dernière mise à jour par : teoli,