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 mais ne présentent qu'un choix limité d'encodages. C'est le cas de l'option -X d'Enscript-1.6.6, de l'option -input-charset de Cdrtools-3.02a09 non corrigé et des encodages disponibles pour l'affichage du menu de Links-2.29. Si l'encodage requis n'est pas dans la liste, le programme devient généralement totalement inutilisable. Pour les programmes non interactifs, on peut contourner cela en convertissant le document dans un encodage d'entrée pris en charge 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 de trouver 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-7.2 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 textuels, ce n'est pas possible. En effet, la supposition du programme peut être complètement invalide pour les documents où le système d'exploitation Microsoft Windows a fixé des normes de facto. Un exemple de ce problème réside dans les attributs 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 ce 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-7.2, JOE-4.6 et à tous les lecteurs multimédias à l'exception de Audacious-4.3.1.

Un autre problème dans cette catégorie est quand une personne ne peut pas lire les documents que vous leur avez envoyés car leur système d'exploitation est programmé pour gérer différemment les encodages de caractères. Cela peut souvent se produire quand l'autre personne utilise Microsoft Windows, qui ne fournit qu'un encodage de caractère pour un pays donné. Cela pose des problèmes avec les documents TeX encodés en UTF-8 créés sous Linux par exemple. 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é de l'encodage 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 le 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. Cette information est bien cachée 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). En conséquence, ces derniers créent des noms de fichiers qui sont ensuite mal affichés par ls ou refusent d'accepter des noms de fichiers affichés correctement par ls. Pour la bibliothèque GLib-2.76.4, 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.

Les paquets Zip-3.0 et UnZip-6.0 ont ce problème car ils codent l'encodage attendu du nom de fichier en dur. UnZip contient une table de conversion codée en dur entre les encodages CP850 (DOS) et ISO-8859-1 (UNIX) et utilise cette table lors de l'extraction des archives créées sous DOS ou Microsoft Windows. Cette supposition ne marche cependant que pour les États-Unis et pas pour 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 endommagés ou rogner volontairement les noms de fichiers existants pour satisfaire les attentes de ces 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-9.4p1). 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 de l'UNICODE à l'encodage de la locale du destinataire.

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

Sévérité : haute ou critique

De nombreux programmes ont été écrits à une époque plus 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 octet, 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 conséquence évidente 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, ne réagissent pas à la touche « Effacement » en effaçant un caractère et laissent les mauvais caractères affichés 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 au besoin). Pour chaque utilisation des fonctions « strlen » et équivalent, il faut aussi trouver ce que veut vraiment dire un nombre d'octets, de caractères ou la largeur de la chaîne. Il est parfois plus rapide d'écrire un programme ayant la même fonctionnalité en partant de zéro.

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

Le paquet installe des pages de manuel dans un encodage incorrect ou 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 avec Shadow qui a déjà été 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 manuel 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 exécutant 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 cependant 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.