Les symptômes

Si vous lisez des choses comme "répertoire" au lieu de "répertoire", il s'agit d'UTF-8 interprété comme du Latin-1.

Si vous lisez des choses comme "r.ertoire" au lieu de "répertoire", il s'agit de Latin-1 interprété comme de l'UTF-8. (Vous verrez peut-être un carré ou autre symbole au lieu du point entre r et e, la chose caractéristique est le fait que le p de répertoire soit absent.)

Le cas que j'ai rencontré

Quand on installe Debian Linux l'installeur demande quelle langue est souhaitée. Les francophones choisissent naturellement le français dans la liste. Debian 3 choisit alors le français codé en ISO-Latin-1 (en fait la variante à laquelle on a ajouté le symbole euro qui n'existait pas à l'époque de la création d'ISO-Latin-1). Ubuntu, une variante intéressante de Debian, choisit le français codé en UTF-8.

Solution rapide pour ce cas : à l'installation d'une Debian comme d'une Ubuntu, choisir les deux variantes du français : "fr_FR.UTF-8" et "fr_FR.ISO-8859-15@euro" (et même d'autres si vous pensez avoir des systèmes qui les utilisent, cela ne devrait pas faire de mal). Si la machine est déjà installée lire la suite.

La suite concerne un serveur SSH sous Linux ou équivalent par exemple Cygwin ou MacOS. La solution 2 est spécifique à Debian (et ses variantes). La solution 3 peut marcher sur certains systèmes (testée seulement sur Debian).

Les "anciens" : serveur ou client Debian ou cygwin, la plupart des clients ssh dont ceux sous Windows

Les "modernes" : serveur ou client Ubuntu ou Mac OS X

Désaccord dans un sens

Cas typique

Si votre client ssh est une machine sous Windows ou un système pas tout récent le texte en provenance du serveur Linux sera interprété comme du Latin-1. Si le serveur est par exemple un système Ubuntu Linux, vous lisez "répertoire".

Solution 1

Utiliser si possible un client ssh qui peut comprendre que le texte lui parvenant est en UTF-8 et lui signifier que c'est votre choix. Problème résolu.

Solution 2

Elle consiste à demander au serveur de s'exprimer dans l'ancien système ISO-Latin-1. Je ne la recommande pas mais dans certains cas elle peut ne poser aucun problème (jusqu'au moment où vous aurez un client moderne).

Si l'administrateur peut intervenir il peut faire

dpkg-reconfigure -plow locales

Une liste de code de langues apparaît. Parmi les façon de coder le français, "fr_FR.UTF-8" sera probablement sélectionnée. Cocher aussi "fr_FR.ISO-8859-15@euro" et confirmer.

L'outil demande alors quelle option doit être choisie par défaut. Si vous souhaitez que tout votre système s'exprime en latin-1 par défaut (la vieille option), choisissez-là. Vous lirez alors quelque chose comme :

Generating locales (this might take a while)...

fr_FR.ISO-8859-15@euro... done
fr_FR.UTF-8... done

Tentez une nouvelle connexion, le problème sera probablement résolu.

Solution 3

S'il n'est pas question que tous les utilisateurs de la machine aient ce réglage par défaut, il est possible de dire au serveur que vous souhaitez qu'il s'exprime en latin-1 pour vous seulement. Malheureusement il faut d'abord appliquer la solution 2 (au moins le début) pour que le codage soit disponible. Sinon vous pouvez toujours demander le réglage en question, s'il n'est pas disponible vous aurez de l'anglais...

Si vous tapez

set | grep LANG

vous lirez probablement quelque chose qui ressemble à

LANG=fr_FR.UTF-8
LANGUAGE=fr_FR:fr:en_GB:en

à défaut essayez

set | grep LC

qui chez moi donne le pas très intéressant

MAILCHECK=60

essayer alors

export LANG=fr_FR@euro

puis votre application, par exemple

aptitude update

Les accents sont corrects et je lis parmis le texte résultant :

E: Impossible de bloquer le répertoire des listes... Êtes-vous root ?

Pour que ce changement soit permanent il vous faudra éditer votre .bash_profile et y ajouter la mention

export LANG=fr_FR@euro

Désaccord dans l'autre sens

Cas typique

Si votre client ssh est une machine sous Ubuntu ou MacOS X le texte en provenance du serveur Linux sera interprété comme de l'UTF-8. Si le système Linux s'exprime en ISO-Latin (ancien) vous lisez "r.pertoire" (chaque caractère accentué est incorrect et "avale" le caractère suivant).

Solution 1

Votre client ssh est moderne et comprend l'UTF-8. Il est possible de lui demander d'interpréter en ISO-latin1 (je dois placer une image comme exemple). Problème résolu.

Solution 2

Si l'administrateur peut intervenir il peut faire

dpkg-reconfigure -plow locales

Une liste de code de langues apparaît. Parmi les façon de coder le français, "fr_FR.ISO-8859-15@euro" sera probablement sélectionnée. Cocher aussi "fr_FR.UTF-8" et confirmer.

L'outil demande alors quelle option doit être choisie par défaut. Si vous souhaitez que tout votre système s'exprime en UTF-8 par défaut (la bonne option pour l'avenir), choisissez-là. Vous lirez alors quelque chose comme :

Generating locales (this might take a while)...

fr_FR.ISO-8859-15@euro... done
fr_FR.UTF-8... done

Tentez une nouvelle connexion, le problème sera probablement résolu.

Solution 3

S'il n'est pas question que tous les utilisateurs de la machine aient ce réglage par défaut, il est possible de dire au serveur que vous souhaitez qu'il s'exprime en UTF-8 pour vous seulement. Malheureusement il faut d'abord appliquer la solution 2 (au moins le début) pour que le codage soit disponible. Sinon vous pouvez toujours demander le réglage en question, s'il n'est pas disponible vous aurez de l'anglais...

Si vous tapez

set | grep LANG

vous lirez probablement quelque chose qui ressemble à

LANG=fr_FR@euro
LANGUAGE=fr_FR:fr:en_GB:en

à défaut essayez

set | grep LC

qui chez moi donne le pas très intéressant

MAILCHECK=60

essayer alors

export LANG=fr_FR.UTF-8

puis votre application, par exemple

aptitude update

Les accents sont corrects et je lis parmis le texte résultant :

E: Impossible de bloquer le répertoire des listes... Êtes-vous root ?

Pour que ce changement soit permanent il vous faudra éditer votre .bash_profile et y ajouter la mention

export LANG=fr_FR.UTF-8

Conclusion

L'UTF-8 est la voie vers des systèmes informatique vraiment internationaux. Les systèmes logiciels les plus modernes le reconnaissent. Je n'ai pas du tout couvert ici l'usage pourtant plus répandu de l'UTF-8 : sur le web. J'espère que cet article répond au besoin pour lequel il a été écrit.