HOWTO Unicode: Configuration des locales
3. Configuration des locales
3.1 Les fichiers et le kernel
Vous pouvez maintenant utiliser n'importe quel caractère Unicode dans
les noms de fichiers. Ni le kernel ni aucun utilitaire système
ne nécessite de modifications.
Ceci parce que les noms de fichiers dans le kernel peuvent être
n'importe quoi qui ne contient ni octet nul, ni '/' (utilisé
pour délimiter les sous-répertoires).
Quand ils sont encodés en utilisant UTF-8, les caractères non-ASCII ne
seront jamais encodés en utilisant un octet nul ou un slash.
La seule conséquence est que les noms de fichiers et de répertoires
occupent plus d'octets qu'ils ne contiennent de caractères.
Par exemple, un nom de fichier contenant cinq caractères grecs
apparaîtra pour le kernel comme un nom de fichier de 10 octets.
Le kernel ne sait pas (et n'a pas besoin de savoir) que ces octets sont
affichés en grec.
C'est une théorie générale, qui est vraie tant que vos fichiers restent
sur un système Linux.
Sur les systèmes de fichiers utilisés depuis d'autres
systèmes d'exploitation, mount possède des options pour contrôler la
conversion des noms de fichiers de/vers UTF-8 :
Les autres systèmes de fichiers (nfs, smbfs, ncpfs, hpfs, etc.) ne
convertissent pas les noms de fichiers. Par conséquent ils
accepteront les noms de fichier Unicode encodés en UTF-8 seulement si
l'autre système d'exploitation les supporte.
Rappelez vous que pour qu'une option de montage soit appliquée aux
prochains montages, vous devez l'ajouter à la quatrième colonne de la
ligne correspondante dans /etc/fstab.
3.2 Le kernel et les ttys
Les ttys sont en quelque sorte des tubes bidirectionnels entre deux
programmes, autorisant des choses comme la répétition (echoing) ou
l'édition de la ligne de commande.
Quand dans un xterm, vous exécutez la commande "cat" sans arguments,
vous pouvez entrer et éditer autant de lignes que vous voulez, elles
seront répétées en retour ligne par ligne.
Les actions d'édition du kernel ne sont pas correctes, en particulier les
touche Backspace et Tab ne seront pas traitées correctement.
Pour résoudre ce problème, vous devez :
- Appliquer le patch
linux-2.0.35-tty.diff
ou
linux-2.2.9-tty.diff
ou
linux-2.3.12-tty.diff
et recompiler votre kernel.
- Si vous utilisez la glibc2, appliquer le patch
glibc211-tty.diff
et recompiler votre libc. Si vous n'êtes pas aussi aventureux,
il suffit de patcher une version déjà installée avec le
fichier inclus :
glibc-tty.diff
- Appliquer le patch
stty.diff
à GNU sh-utils-1.16b, et recompiler le programme
stty . Testez le
ensuite en utilisant stty -a et stty iutf8 .
- Ajouter la commande
stty iutf8 au script unicode_start, et la
commande stty -iutf8 au script unicode_stop.
- Appliquer le patch
xterm.diff
à xterm-109, et recompiler "xterm", puis le tester en lançant
xterm -u8 / xterm +u8 et en lançant stty -a
et un cat interactif à l'intérieur.
Pour que ce changement soit persistant même à travers rlogin et
telnet, vous devrez aussi :
- Définir des nouvelles valeurs pour la variable d'environnement TERM,
"linux-utf8" comme alias pour "linux", et "xterm-utf8" comme alias
pour "xterm". Si vous avez la bibliothèque ncurses sur votre système et
la base de données /usr/lib/terminfo (ou /usr/share/terminfo), faites
cela en éxecutant
sur un compte utilisateur (cela créera les entrées terminfo dans votre
repertoir $HOME/.terminfo).
Voilà
linux-utf8.terminfo et
xterm-utf8.terminfo.
Je ne recommande pas de lancer ces commandes en tant que root, parce
que cela créera les entrées terminfo dans /urs/lib/terminfo, où, elles
seront probablement effacées lors de la prochaine mise à jour de votre
système.
Si votre système possède un fichier /etc/termcap, vous devriez aussi
éditer ce fichier : copiez les entrées linux et xterm, et donnez leur
les nouveaux noms "linux-utf8" et "xterm-utf8".
Le fichier
termcap.diff
contient un exemple.
- À chaque fois que vous appelez "unicode_start" et "unicode_stop"
depuis la console, exécutez aussi "export TERM =linux-utf8", ou
"export TERM=linux", respectivement.
- Appliquer le patch
xterm2.diff
à xterm-0.9, recompiler "xterm", et et enlever toutes les lignes
"XTerm*termName" des fichiers /usr/X11R6/lib/X11/app-defaults/XTerm
et $HOME/.Xdefaults. Maintenant xterm donne à TERM la valeur
"xterm-utf8" plutôt que "xterm".
- Appliquer les patches
netkit.diff,
netkitb.diffet
telnet.diff
puis recompiler "rlogind" et "telnetd". Maintenant rlogin et telnet
mettent tty en mode d'édition UTF-8 à chaque fois que la variable
d'environnement TERM est "linux-ut8" ou "xterm-utf8".
3.3 Conversion de données générales
Vous aurez besoin d'un programme pour convertir vos fichiers texte
locaux (probablement ISO-8859-1) en UTF-8.
L'alternative serait de continuer à utiliser des textes qui utilisent
différents encodages sur la même machine, mais ce n'est pas une bonne
solution sur le long terme.
Un de ces programmes est "iconv", qui est livré avec la
glibc-2.1. Tapez simplement
Voici deux scripts shell très pratiques, appelés
"i2u"
i2u.sh (pour conversion de ISO à UTF) et
"u2i"
u2i.sh (pour conversion de UTF à ISO).
[skip adapt..]
Si vous n'avez pas la glibc-2.1 et iconv installés, vous pouvez
utiliser GNU recode 3.5 à la place.
"i2u"
i2u_recode.sh est
"recode ISO-8859-1..UTF-8"
"u2i"
u2i_recode.sh est
"recode UTF-8..ISO-8859-1".
ftp://ftp.iro.umontreal.ca/pub/recode/recode-3.5.tar.gz
ftp://ftp.gnu.org/pub/gnu/recode/recode-3.5.tar.gz
Notes : vous devez utiliser GNU recode 3.5 ou plus. Pour compiler GNU
recode sur des plateformes sans glibc-2 (c'est à dire sur toutes les
plateformes sauf les systèmes Linux récents), vous devez le
configurer avec "--disable-nls", autrement l'édition des liens
échouera.
Sinon, vous pouvez aussi utiliser CLISP à la place.
Voici "i2u" et "u2i" en version lisp :
i2u.lsp et
u2i.lsp.
Note : Vous devez avoir une version de CLISP qui date au plus de juillet 1999.
ftp://clisp.cons.org/pub/lisp/clisp/source/clispsrc.tar.gz
D'autres programmes de conversion de données existent, mais ils sont
moins puissants que GNU recode. Ce sont
3.4 Les variables d'environnement locales
Vous pouvez avoir les variables d'environnement suivantes
positionnées, contenant les noms de locales :
- LANGUAGE
Remplacement pour LC_MESSAGES. Seulement utilisé par GNU gettext.
- LC_ALL
Remplacement pour toute les autres variables LC_* :
- LC_CTYPE, LC_MESSAGES, LC_COLLATE, LC_NUMERIC, LC_MONETARY, LC_TIME
Ce sont des variables individuelles pour : le type des caractères et
leur encodage, les messages en langue maternelle, les règles de
classement, le format des nombres, le format des montants monétaires,
l'affichage de la date et de l'heure.
- LANG
Valeur par défaut pour toutes les variables LC_*
(Voir `man 7 locale ' pour une description détaillée.)
Chacune des variables LC_* et LANG peuvent contenir un nom de locale
de la forme suivante :
language[_territory[.codeset]][@modifier]
Où language est un code de langue
ISO 639
(en minuscules), territory est un code de pays
ISO 3166
(en majuscules), codeset désigne une table de caractères, et modifier
d'autres attributs particuliers (par pour exemple indiquer un dialecte
particulier d'une langue, ou une orthographe non standard).
LANGUAGE peut contenir plusieurs noms de locale, séparés par deux
points (:).
Pour dire à votre système et à toutes les applications que vous
utilisez UTF-8, vous devez ajouter un suffixe d'UTF-8 à vos noms de
locales. Par exemple, si vous utilisiez
vous le changeriez en
3.5 Créer les fichiers pour le support des locales
Si vous avez la glibc-2.1 ou glibc-2.1.1 ou glibc-2.1.2 installée,
vérifiez d'abord en utilisant "localedef -help" que le répertoire
système pour le tables de caractères est /usr/share/i18n/charmaps.
Puis appliquez au fichier /usr/share/i18n/charmaps/UTF8 le patch
glibc21.diff
ou
glibc211.diff
ou
glibc212.diff, respectivement.
Puis créez les fichiers de support pour toute les locales UTF-8 que
vous voulez utiliser, par exemple :
Généralement vous n'avez pas besoin de créer des variables appelées
"de" ou "fr" sans suffixe pour le code du pays, parce que ces
locales sont normalement utilisées seulement par la variable LANGUAGE,
et pas par les variables LC_*. De plus LANGUAGE est seulement utilisé
en remplacement de LC_MESSAGES.
3.6 Ajouter le support pour la bibliothèque C
La glibc-2.2 supportera les locales multi-octets (de plusieurs
octets), en particulier les
locales UTF-8 créées plus haut. Mais les glibc-2.1 et 2.1.1 ne la
supportent pas réellement. Par conséquent le seul effet réel de la
création des fichiers /usr/local/share/de_DE.UTF-8/* ci dessus est que
setlocale(LC_ALL,"") retournera "de_DE.UTF-8", conformément à vos
variables d'environnement, au lieu d'enlever le suffixe "UTF-8".
Pour ajouter le support pour la locale UTF-8, vous devriez compiler et
installer la bibliothèque 'libutf8_plug.so', depuis
libutf8-0.5.2.tar.gz.
Puis vous pouvez positionner la variable d'environnement LD_PRELOAD
pour qu'elle pointe sur la bibliothèque installée :
Alors, dans chaque programme lancé avec cette variable d'environnement
positionnée, les fonctions de libutf8_plug.so seront appelées à la
place des originales dans /lib/libc.so.6. Pour plus d'informations sur
LS_PRELOAD, voyez "man 8 ld.so".
Tout cela ne sera plus nécessaire quand la glibc-2.2 sortira.
3.7 Conversion des catalogues de messages
Maintenant ajoutons un contenu à ces nouvelles locales. Les commandes
/bin/sh suivantes convertiront vos catalogues de messages au format
UTF-8. Elles doivent être lancées en tant que root, et nécessitent les
programmes 'msgfmt' et 'msgunfmt' de GNU gettext-0.10.35
convert-msgcat.sh.
Ceci non plus ne sera plus nécessaire une fois que la glibc-2.2 sera
sortie, parce qu'alors la fonction gettext convertira les chaînes de
caractères de façon appropriée depuis la table de caractères du
traducteur vers la table de caractères de l'utilisateur, en
utilisant soit iconv soit librecode.
[22 février 2002, JDNet]
|