LibSass et Unicode

Actuellement, LibSass s'attend à ce que toutes les entrées soient encodées en UTF8 (et ne génère que ce format), même si vous avez des caractères Unicode. La conversion entre les encodages n'est pas prise en charge, même si vous la déclarez avec une règle @charset. Le texte ci-dessous a été initialement publié comme un problème sur le suivi LibSass. Depuis, l'état est obsolète : LibSass s'attend désormais à ce que vos entrées soient compatibles UTF8/ASCII. Il a été prouvé que la lecture des encodages ANSI (par exemple, les encodages sur un octet) en UTF8 peut entraîner des comportements inattendus, pouvant dans le pire des cas entraîner des dépassements de tampon ou des erreurs de segmentation. Par conséquent, LibSass vérifie désormais que vos entrées sont bien encodées en UTF8 !

Déclaration des encodages de caractères en CSS

Ceci explique comment l'encodage des caractères d'un fichier CSS est déterminé. Comme il ne traite que des fichiers locaux, ils n'ont jamais d'entête HTTP. La priorité devrait donc être la règle «charset», le marqueur d'ordre des octets (BOM) ou la détection automatique (avec retour final à la valeur par défaut du système/UTF-8). Cela peut paraître simple à mettre en ouvre, mais qu'en est-il des règles d'importation ? Les spécifications CSS n'interdisent pas le mélange de différents encodages ! Ils ont résolu ce problème en convertissant tous les fichiers en UTF-8 en interne. Lors de l'écriture, une option permet d'indiquer à l'outil l'encodage souhaité (UTF-8 par défaut). Il est également possible de définir s'il doit écrire un BOM ou non et s'il doit ajouter la déclaration de l'ensemble de caractères.

Leur outil étant écrit en Perl, il dispose de nombreux utilitaires pour gérer différents ensembles de caractères Unicode. La plupart des logiciels libres utilisent ICU ou libiconv pour effectuer la conversion entre différents encodages. Ils n'ont pas encore une idée de la facilité/difficulté d'intégration, quelle que soit la plateforme (cela semble faisable). L'encodage ANSI (codage sur un octet) vers UTF-8 se résume à une table de conversion (pour chaque page de code prise en charge).

État actuel de la prise en charge Unicode de LibSass

LibSass est/devrait être entièrement compatible UTF (et donc ASCII simple).

LibSass 3.5 garantit que votre entrée est soit en ASCII simple (caractères inférieurs à 127), soit en UTF-8. Il ne gère rien d'autre, mais garantit donc que la sortie est valide. Avant la version 3.5, il était possible de mélanger différentes pages de codes, ce qui provoquait des comportements inattendus.

Détection automatique de l'encodage actuel

LibSass lit actuellement tous les types de BOM et génère une erreur s'il détecte un élément qu'il ne sait pas gérer ! Il semble qu'il supprime le BOM UTF-8 facultatif (s'il en trouve un). À mon avis, il serait appréciable que les utilisateurs puissent configurer cela (y compris si une règle de l'ensemble de caractères doit être ajoutée à la sortie). Cependant, il ne prend pas réellement en compte les @charsets : il suppose toujours que votre entrée est en UTF-8 et ignore tout @charset donné !

Ce qui n'est pas pris en charge actuellement :

• Utilisation d'encodages non compatibles ASCII (comme UTF-16, Latin-1,...)
• Utilisation de caractères non ASCII dans différents encodages et dans différentes inclusions

Ce qui manque pour prendre en charge les cas ci-dessus

• Un moyen de convertir entre les encodages (comme libiconv/ICU)
• Recherche de l'ensemble de caractères dans le fichier (source disponible)
• Gestion de la conversion à l'importation (et à l'exportation)
• Facultatif : Rendre l'encodage de sortie configurable
• Facultatif : Ajouter une nomenclature (BOM) facultative/obligatoire (configurable)

Fonctionnalité de faible priorité

Il suppose que l'implémentation actuelle devrait gérer plus de 99 % des cas d'utilisation réels. A) Les caractères Unicode sont encore rarement utilisés (car ils peuvent être écrits avec un échappement).

Il suppose que le plus gros problème réside dans la dépendance de la bibliothèque libiconv/ICU (ou autre). Comme elle contient de nombreuses règles de conversion, je pense que c'est la seule façon de gérer cela correctement. Une fois ce problème résolu, il devrait être assez simple d'implémenter les éléments manquants (dans parser.cpp : Parser::parse devrait renvoyer l'encodage et ajouter Parser::sniff_charset, puis convertir le flux d'octets source en UTF-8).

Il espère que les affirmations ci-dessus sont vraies. Unicode n'est vraiment pas le sujet le plus simple à appréhender.