Traduction(s) : English - Français


Debian et UTF8

Question introductive

Heu... ça veut dire quoi « passer en ?UTF8 » ? Pourquoi ?

Tester votre installation

wget http://www.linux-cjk.net/Console/garabik/UTF-8-demo.txt.gz

zcat UTF-8-demo.txt.gz

Passer à UTF-8 sous debian

Cette page est née des échanges sur la liste de diffusion debian-user-french à propos d'UTF-8. Elle comporte des liens vers les fils de discussions originaux, qui peuvent éventuellement apporter un complément d'information.

Cette page est focalisée sur les problèmes de transition, certains des problèmes évoqués n'apparaîtront (heureusement) pas à l'installation d'une Debian toute fraîche.

Méthode suivie

La page de Guillaume "LoneWolf" Estival (en anglais) explique la marche à suivre.

En résumé :

  apt-get install locales
  dpkg-reconfigure locales

  dpkg-reconfigure locales

Au final, cela donne :

    $ locale
    LANG=fr_FR.UTF-8
    LC_CTYPE="fr_FR.UTF-8"
    LC_NUMERIC="fr_FR.UTF-8"
    LC_TIME="fr_FR.UTF-8"
    LC_COLLATE="fr_FR.UTF-8"
    LC_MONETARY="fr_FR.UTF-8"
    LC_MESSAGES="fr_FR.UTF-8"
    LC_PAPER="fr_FR.UTF-8"
    LC_NAME="fr_FR.UTF-8"
    LC_ADDRESS="fr_FR.UTF-8"
    LC_TELEPHONE="fr_FR.UTF-8"
    LC_MEASUREMENT="fr_FR.UTF-8"
    LC_IDENTIFICATION="fr_FR.UTF-8"
    LC_ALL=

Attention, ne pas utiliser la variante @euro dans ce cas-là.

Cela peut entraîner une série de petits dysfonctionnements

J'ai plein de caractères moches en mode console.

Les console 2 à 6 n'acceptent pas les caracteres encodés en UTF-8 car elles sont créées à la fin du processus d'init, bien après que /etc/init.d/console-tools.sh a été exécuté (271013). Mais le lancement du script /usr/bin/unicode_start, contenu dans les paquets console-data et kbd, regle le probleme. Il y a eu deux conversations à ce sujet sur debian-user-french.

J'ai des caractères bizarres dans mes noms de fichiers.

Les programmes ont parfois du mal à savoir comment sont encodés les noms de fichiers. Avec GNOME, il faut éventuellement rajouter dans son environnement G_FILENAME_ENCODING=@locale. Pour régler définitivement le problème, il est aussi possible de convertir les noms de fichier à l'aide de l'utilitaire convmv.

Xmms n'affiche plus sa liste de lecture.

La solution est de dire à xmms d'utiliser une autre police de caractère pour sa liste, comme -adobe-helvetica-medium-r-normal-'''-'''-80-'''-'''-p-*-iso10646-1. L'important est de sélectionner une police unicode. Pour ce faire, utilisez xfontsel et sélectionnez "iso10646" dans le menu "rgstry", puis "1" dans "encdng". Vous verrez alors apparaître le nombre de polices correspondant tout en haut. Affinez alors votre sélection en choisissant la taille en points, la famille et la graisse de la police...

Man ne fonctionne plus très bien.

En fait si, mais il utilise less comme pageur, et certaines de ses versions sont fâchées avec l'utf8. Dans certains cas, le problème a été réglé avec l'installation de la version 382.

Less ne fonctionne pas, malgré la mise à jour à une version récente.

Plus le temps passe, plus les fichiers de configurations accumulent des vieilleries. Bien vérifier les fichiers .bashrc et .bash_profile. La commande env|grep LESS= permet de voir si des variables d'environnement ont été positionnées. Tester less dans une environnement où ces variables sont vides.

Grep est beaucoup plus lent.

C'est surtout visible sur des ordinateurs peu véloces. Mettre LC_ALL=C devant la commande peut régler le problème.

Aspell ne détecte pas automatiquement l'encodage.

Il faut donc gentiment lui préciser que l'on est en utf-8, avec l'option --encoding=utf-8. Ne vous laissez pas impressionner par les bugs à l'affichage, ils ne se retrouvent pas dans le fichier.

On peut aussi ajouter la ligne encoding UTF-8 dans son fichier ~/.aspell.conf

Emacs devient un peu fou quand on essaye de saisir une lettre accentuée.

Il faut demander à Emacs de prendre en compte les locales indiquées par les variables d'environnement. D'autres solutions plus compliquées ont été discutées sur ?DebianUserFrench. Les caractères latins accentués passent si on met les commandes appropriées dans son .emacs. La saisie de certains caractères orientaux comme les hiraganas est possible, mais les kanjis refusent obstinément de renter. Alternative : il existe d'ailleurs un moyen de demander à vi de se comporter comme emacs: c'est le paquet vimacs.

J'ai vu vi afficher des caractères utf8, mais chez moi, ça ne veut pas.

Il existe plusieurs versions de vi. Pour voir celle que vous utilisez, il faut entrer ls -l /etc/alternatives/vi dans un terminal. nvi, la version par défaut, ne fonctionne pas. Il vous faut vim, ViIMproved.

Le moindre fichier nouveau contenant des accent est encodé en utf8.

Cela pose de très gros problèmes de partage de données ! Heureusement, il existe des convertisseurs. Pour me simplifier la vie, j'ai mis alias unutf='recode UTF-8..ISO-8859-15' dans mon .bashrc.

Des caractères utf8 sont envoyés aux terminaux virtuels distants, alors qu'ils ne les comprennent pas.

Il faut insérer un filtre entre le shell et le terminal distant, avec la commande suivante luit (paquet xutils). Par exemple, LC_ALL=fr_FR luit ssh -C login@machine.

Slrn n'affiche plus les accents.

Il semble que, à la date d'avril 2005, slrn et unicode étaient encore fâchés.

Zsh devrait supporter utf8, mais rien ne se passe.

Le support de l'UTF-8 est apparu dans zsh 4.3 (paquet zsh-beta de Sid), mais il faut l'activer dans la configuration en mettant 'setopt printeightbit' dans le fichier .zshrc.

J'ai beau utiliser Unicode, certains caractères ne s'affichent pas.

C'est normal, aucune de police de caractères ne contient tous les caractères. Il faut donc installer des polices supplémentaires.