Problèmes liés aux locales

L'encodage nécessaire n'est pas une option valide du programme

Sévérité : Critique

Certains programmes exigent que l'utilisateur spécifie l'encodage de caractères pour leurs données d'entrée et de sortie et ils ne présentent qu'un choix limité d'encodages. C'est le cas de l'option -X d'a2ps-4.14 et de Enscript-1.6.6, de l'option -input-charset de Cdrtools-3.02a09 non corrigé et des encodages offerts pour l'affichage du menu de Links-2.16. Si l'encodage requis n'est pas dans la liste, le programme devient en général totalement inutilisable. Pour les programmes non interactifs, on peut contourner cela en convertissant le document dans un encodage d'entrée supporté avant de le soumettre au programme.

Une solution à ce type de problème consiste à implémenter le support nécessaire de l'encodage manquant avec un correctif du programme d'origine ou un remplaçant.

Le programme suppose l'encodage basé sur la locale de documents externes

Sévérité : Haute pour des documents non-textes, basse pour des documents textes

Certains programmes, nano-2.9.8 ou JOE-4.6 par exemple, supposent que les documents sont toujours dans l'encodage impliqué par la locale actuelle. Si cette supposition peut être valide pour les documents créés par l'utilisateur, ce n'est pas sûr pour ceux externes. Quand cette supposition échoue, les caractères non-ASCII s'affichent mal et le document peut devenir illisible.

Si le document externe est entièrement basé sur du texte, il peut être converti dans l'encodage de la locale actuelle en utilisant le programme iconv.

Pour les documents non basés sur du texte, ce n'est pas possible. En fait, la supposition du programme peut être complètement invalide pour les documents où le système d'exploitation Microsoft Windows a de facto réglé les standards. Un exemple de ce problème réside dans les drapeaux ID3v1 des fichiers MP3 (voir la page ID3v1Coding du Wiki BLFS pour plus de détails). Dans ces cas-là, la seule solution est de trouver un programme remplaçant qui n'a pas le problème (comme un qui vous permettra de spécifier l'encodage supposé du document).

Au sein des paquets BLFS, ce problème s'applique à nano-2.9.8, JOE-4.6 et à tous les lecteurs multimédias, sauf Audacious-3.10.

Un autre problème dans cette catégorie est quand on ne peut pas lire les documents qu'on vous a envoyés car leur système d'exploitation a été réglé pour gérer différemment les encodages de caractères. Cela peut se produire souvent quand l'autre personne utilise Microsoft Windows, qui ne fournit qu'un encodage de caractère par pays donné. Par exemple, cela pose des problèmes avec les documents TeX encodés en UTF-8 créés sous Linux. Sur Windows, la plupart des applications supposeront que ces documents ont été créés en utilisant l'encodage 8 bits de Windows par défaut.

Dans les cas extrêmes, les problèmes de compatibilité d'encodages de Windows ne peuvent être résolus qu'en lançant des programmes Windows sous Wine.

Le programme utilise ou crée des noms de fichiers dans un mauvais encodage

Sévérité : Critique

Le standard POSIX suppose que l'encodage des noms de fichiers est l'encodage impliqué par la catégorie de locale LC_CTYPE actuelle. Ces informations sont bien cachées sur la page qui spécifie le comportement des programmes Tar et Cpio. Certains programmes ne le font pas par défaut (ou n'ont tout simplement pas assez d'informations pour le faire). Il en résulte qu'ils créent des noms de fichiers qui sont ensuite mal affichés par ls, ou ils refusent d'accepter des noms de fichiers affichés correctement par ls. Pour la bibliothèque GLib-2.56.1, on peut corriger le problème en réglant la variable d'environnement G_FILENAME_ENCODING sur la valeur spéciale "@locale". Les programmes basés sur Glib2 qui ne respectent pas cette variable d'environnement sont bogués.

Zip-3.0, UnZip-6.0 ont ce problème car ils ont en dur l'encodage accepté du nom de fichier. UnZip contient en dur une table de conversion entre les encodages CP850 (DOS) et ISO-8859-1 (UNIX) et il utilise cette table lorsqu'il extrait des archives créées sous DOS ou Microsoft Windows. Cette supposition ne marche cependant que pour les États-Unis et pas pour tous ceux qui utilisent une locale UTF-8. Les caractères non-ASCII seront rognés dans les noms de fichiers extraits.

La règle générale pour éviter ce type de problème est d'éviter d'installer des programmes cassés. Si c'est impossible, vous pouvez utiliser l'outil convmv en ligne de commande pour corriger les noms de fichiers créés par ces programmes cassés, ou rogner volontairement les noms de fichiers existants pour satisfaire les présupposés casses de tels programmes.

Dans d'autres cas, un problème similaire vient de l'importation de noms de fichiers d'un système utilisant une locale différente avec un outil non conscient de la locale (comme OpenSSH-7.7p1). Pour éviter de rogner les caractères non-ASCII lors du transfert de fichiers vers un système ayant une locale différente, vous pouvez utiliser une des méthodes suivantes :

Les quatre dernières méthodes fonctionnent car les noms de fichiers sont automatiquement convertis de la locale de l'expéditeur en UNICODE et stockés ou envoyés sous cette forme. Ils sont alors convertis de façon transparente d'UNICODE dans l'encodage de la locale du destinataire.

Le programme casse les caractères ou ne compte pas bien les cellules de caractères

Sévérité : Haute ou critique

De nombreux programmes ont été écrits dans une ère ancienne où les locales multi-octets n'étaient pas courantes. De tels programmes supposent que les types de données C "char", qui sont un des octets, peuvent être utilisés pour stocker des caractères uniques. De plus, ils supposent que n'importe quelle séquence de caractères est une chaîne valide et que chaque caractère occupe une seule cellule de caractère. De telles suppositions échouent complètement dans les locales UTF-8. La manifestation visible est que le programme tronque les chaînes de façon prématurée (c'est-à-dire aux octets 80 au lieu des caractères 80). Les programmes basés sur le terminal ne placent pas bien le curseur à l'écran, ils ne réagissent pas à la touche « Effacement » en effaçant un caractère et ils laissent les mauvais caractères affiché lors du rafraîchissement de l'écran, transformant généralement l'écran en désordre complet.

La correction de ce type de problème est une tâche pénible du point de vue d'un programmeur, comme tout cas de modernisation d'un design défectueux par de nouveaux concepts. Dans ce cas, il faut concevoir de nouveau toutes les structures de données pour s’accommoder du fait qu'un caractère complet peut s'étendre sur un nombre variable de « char » (ou basculer sur wchar_t et convertir comme nécessaire). Pour chaque appel aux fonctions « strlen » et équivalent, il faut aussi trouver ce que voulait vraiment dire un nombre d'octets, de caractères ou la largeur de la chaîne. Il est parfois plus rapide d'écrire depuis zéro un programme ayant la même fonctionnalité.

Au sein des paquets de BLFS, ce problème s'applique àxine-ui-0.99.10 et tous les shells.

Le paquet installe des pages de manuel dans un mauvais encodage ou dans un non affichable

Sévérité : basse

LFS s'attend à ce que les pages de manuel soient dans l'encodage spécifique à la langue (en général 8-bit), comme indiqué sur la page Man DB de LFS. Cependant, certains paquets installent des pages de manuel traduites dans l'encodage UTF-8 (comme Shadow, déjà traité), ou des pages de manuel dans des langues non présentes dans la table. Tous les paquets BLFS n'ont pas fait l'objet d'une évaluation de leur respect des exigences de LFS (la grande majorité a été vérifiée et des corrections ont été mises dans le livre pour les paquets connus pour installer des pages de manuel non conformes). Si vous trouvez une page de manuel installée par un paquet BLFS qui est dans un mauvais encodage, merci de la supprimer ou de la convertir selon vos besoins et de le signaler à l'équipe BLFS comme un bogue.

Vous pouvez facilement vérifier le respect par toutes les pages de man de votre système en copiant le petit script shell suivant à un endroit accessible,

#!/bin/sh
# Begin checkman.sh
# Usage: find /usr/share/man -type f | xargs checkman.sh
for a in "$@"
do
    # echo "Checking $a..."
    # Pure-ASCII manual page (possibly except comments) is OK
    grep -v '.\\"' "$a" | iconv -f US-ASCII -t US-ASCII >/dev/null 2>&1 \
        && continue
    # Non-UTF-8 manual page is OK
    iconv -f UTF-8 -t UTF-8 "$a" >/dev/null 2>&1 || continue
    # Found a UTF-8 manual page, bad.
    echo "UTF-8 manual page: $a" >&2
done
# End checkman.sh

puis en lançant la commande suivante (modifiez la commande ci-dessous si le script checkman.sh n'est pas dans votre variable d'environnement PATH) :

find /usr/share/man -type f | xargs checkman.sh

Remarquez que si vous avez des pages de manuel installées ailleurs que dans /usr/share/man (comme dans /usr/local/share/man), vous devez modifier la commande ci-dessus pour inclure cet emplacement supplémentaire.