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.
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 :
stty. Testez le
ensuite en utilisant stty -a et stty iutf8.
stty iutf8 au script unicode_start, et la
commande stty -iutf8 au script unicode_stop.
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 :
$ tic linux-utf8 . terminfo
$ tic xterm-utfu . terminfo
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
icon --from-code=ISO-8859-1 --to-code=UTF-8 < vieux_fichier> nouveau_fichier
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
Vous pouvez avoir les variables d'environnement suivantes positionnées, contenant les noms de locales :
Remplacement pour LC_MESSAGES. Seulement utilisé par GNU gettext.
Remplacement pour toute les autres variables LC_* :
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.
Valeur par défaut pour toutes les variables LC_*
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
LANGUAGE=de:fr:en
LC_CTYPE=de_DE
vous le changeriez en
LANGUAGE=de.UTF-8:fr.UTF-8:en.UTF-8
LC_CTYPE=de_DE.UTF-8
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 :
$ localedef -v -c -i de_DE -f UTF8 /usr/share/locale/de_DE.UTF-8
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.
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 :
export LD_PRELOAD=/usr/local/lib/libutf8_plug.so
Tout cela ne sera plus nécessaire quand la glibc-2.2 sortira.
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.