[gull] Locale, accent et Kubuntu

[Marc SCHAEFER]

On Thu, Dec 08, 2005 at 12:35:35AM +0100, Jean-Bruno Luginbühl wrote:
> Je tente de l'intégrer dans notre réseau, mais j'ai des problèmes avec
> les noms de fichier accentués. J'ai tenté la connexion à un serveur de

Le codage des caractères accentués et autres est quelque chose de très
simple et normal, mais qui a fait couler beaucoup d'encre.

Personnellement, depuis environ 1985 j'utilise quelque chose qui
ressemble beaucoup à ISO-8859-1. Le jeu de caractère proposé par les
terminaux DEC VT2xx ainsi que p.ex. par l'Amiga, puis par la plupart des
systèmes UNIX 8-bit-clean.

Entre temps divers systèmes ont proposé diverses saloperies comme le
CP-347 (ou est-ce 437?) de MS-DOS, OS/2 et la console `COMMAND.COM'
ou `CMD.EXE' des diverses et variées incarnations de Microsoft Windows.

Bien sûr, le jeu ISO-8859-1 (ainsi que bien sûr son précédecesseur sans
accent ASCII) est très réducteur. Il n'apporte aucun support pour les
caractères spéciaux (lettres grecques, latines, hébreu, arabe, etc), et
ne permet pas l'affichage simultané de ces divers jeux.

Des environnements ASCII 7 bit comme LaTeX ont proposé des solutions à
ce problème (des séquences d'échappement comme \truc) qui ont l'avantage
de garder la simplicité (KISS) tout en étant extrêmement puissantes (mode
équation p.ex)).

On aurait pu se limiter à ce genre de solutions, ou d'utiliser des
entities HTML (é etc) dans les documents de `traitement de
texte'.

Mais non, il a été décidé deux choses à la suite:

   1. proposer des jeux incompatibles à ISO-8859-1 (sauf sous-ensemble
      ASCII 7 bit) pour représenter des caractères spéciaux (est
      européen, arabe, etc). Comme la plupart des OS n'ont pas de
      type MIME / d'encodage associés aux fichiers, les applications
      doivent deviner le jeu ...  sur le WWW c'est bon si le serveur
      est configuré correctement si le client n'est pas trop stupide.

   2. la norme UNICODE, qui représente chaque `symbole' jusqu'à 24 bits
      (16 millions de possibilité), ce qui évite ce problème d'ambiguité
      de décodage mais en amène d'autres!

UNICODE est certes un progrès marketing, mais elle viole une règle
de base de l'informatique je j'aime:

   simple things must be simple; complex things must be possible.

En UNICODE, simple things are simply complex. Complex things are as
complex or sometimes more.

Par exemple, si l'on utilise p.ex. UTF-8, le `simple' code accentué
ouest-européen se code sur 16 bits (1 caractère d'échappement, puis
1 caractère de code). L'ASCII 7 bit reste, cependant, compatible.

En plus, il y a plusieurs façon de coder un caractère, suivant le
préfixe utilisé: on peut le représenter sur 3, voire 4 bytes.

Sans penser aux problèmes d'implémentation (strlen(buf) != taille en
`caractères'), il y a aussi le problème qu'un caractère comme le simple
'a' peut être un caractère qui a cette tête mais n'a rien à voir en
code.  Il y a déjà eu des attaques sur le `punycode' DNS de ce style, il
y en aura d'autres.

Il y a aussi des fioritures qui ressemblent au LaTeX: les caractères
composés (p.ex. ' et e donne quelque chose comme é). Les applications
sont libres d'utiliser l'une et l'autre formes (qui se codent
différemment!)

(PS: désolé si je ne respecte pas la terminologie, je n'ai pas lu la
norme en entier)

Enfin, il y a la problème de la compatibilité des documents. Il est
certes facile de faire un recode latin1..utf8, et il est même possible
de détecter par heuristique le codage d'un document (p.ex. chez un
client qui avait mal configuré son serveur Samba, les noms de fichiers
étaient en CP-347, ISO-8859-1 et UTF-8, j'ai fait un petit script de
recollage de morceaux), mais malgré tout cela est une complexité
relativement ennuyeuse pour finalement aucun avantage visible pour un
client standard. (*)

(*) ça a à peu près la même valeur qu'une mise à jour de sécurité ou de
distribution sur une machine qui fonctionne. Dur à faire admettre que
c'est indispensable.

Malheureusement, il est clair qu'un jour où l'autre il fera faire le
pas!

En attendant, solution technique:

   # dpkg-reconfigure locales
        ajouter fr_CH ISO8859-1
        demander de le mettre par défaut dans le système

ensuite les contenus et les noms de fichiers seront en ISO8859-1.

(en principe cela modifie les variables LANG, et LC_, cf `locale'
globalement. Personnellement je suis assez adapte de POSIX pour tout,
sauf pour LC_CTYPE. On trouve plus facilement les messages d'erreur en
anglais avec Google. J'ai remarqué que le JDK de Sun (propriétaire), dès
qu'il voit une seule variable LC_* à fr_CH, passe tout en français.
Strange, passons :->).

J'ai rapidement installé Ubuntu 5.10 via QEMU (c'est un peu lent, mais
ça marche, et cela permet de localiser le tout dans un fichier et on
peut faire `rm' après!), et j'ai appliqué ces modifications.

Constatations:

   - le navigateur de fichiers de GNOME semble respecter mon choix,
     au moins pour les fichiers locaux.

   - l'xterm respecte mon choix

   - vi respecte mon choix

   - par contre gedit veut absolument sauver en UTF-8. Apparemment
     c'est un bug (?). En cherchant un peu via Google j'ai vu
     un work-around.

   - par contre certains scripts d'initialisation du système qui
     ont été traduits (première erreur) utilisent un echo 8 bit
     qui est codé en dur en UTF-8 (deuxième erreur), mais bon, le
     shell n'a aucune idée de ce qu'est un jeu de caractère.

Donc apparemment, même en Ubuntu 5.10, il doit être possible de rester
en ISO-8859-1.

> serveur de fichier (Debian Woody, avec NFS et Samba), je n'y arrive pas

woody est `oldstable', d'ici quelques mois il faudra mettre à jour à
sarge, sinon les mises à jour de sécurité ne seront plus garanties, et
peut-être qu'une mise à jour ensuite sera plus difficile.

Cf le paragraphe ci-dessus concernant la `valeur pour le client'.
Heureusement Debian a des cycles de mise à jour de distribution lents.

> [global]

si l'accès se fait *uniquement* par Samba, dans ce cas il est possible
d'utiliser l'inclusion conditionnelle paramétrée de configurations de
Samba. En clair, inclure un fichier genre %s.inc, où %s est le nom du
serveur (voir la doc de Samba pour vérifier la syntaxe), et dans le cas
de kubuntu configurer une conversion UTF8.

En NFS .... NFS comme le reste d'UNIX de base n'a pas de notion de
jeu de caractères et se borne à transmettre les données et métadonnées
telles quelles, 8-bit clean.