[gull] Caractères accentués Linux-Windows

[Marc Mongenet]

Note: message en UTF-8, comme l'original.

Grégoire Métral wrote:
> Bonjour,
> 
> Je me débats avec un problème d'accents dans les noms de fichiers lors 
> d'échanges avec des systèmes Windows. J'utilise 2 systèmes qui 
> réagissent différemment: une RedHat 8.0 (RH) -- serveur en prod. -- et 
> une Mandrake 10.0 (MDK) -- système en test.
> 
> Sur la MDK, un fichier créé depuis Linux me donnera des résultats 
> conformes à mon attente:
>     $ touch édition.txt
> Le fichier apparaît dans Windows et Linux comme "édition.txt".
> 
> Toujours sur MDK, un fichier créé depuis Windows (partage samba) donnera 
> un résultat conforme sur Windows, mais légèrement modifié sur Linux:
>     $ ls
>     édition.txt
> (si jamais les caractères passent mal, il s'agit d'un A majuscule avec 
> tilda suivi du symbole "copyright")

Je ne connais pas la solution pratique, mais en théorie ça donne ceci :

Le mauvais passage observé ici est le résultat d'un programme qui
croit recevoir des caractères encodés en ISO-8859-1 (aussi appelé
ISO Latin 1) alors qu'il les reçoit en fait encodés en UTF-8.

ISO-8859-1 encode chaque caractère sur un octet. UTF-8 utilise un
nombre variable d'octets par caractère. On peut encore noter que
ISO-8859-1 est à la fois un répertoire de caractère et un encodage.
UTF-8 est uniquement un encodage parmi d'autres destiné à encoder le
répertoire Unicode. Le répertoire Unicode est un sur-ensemble du
répertoire ISO-8859-1 qui est lui-même un sur-ensemble du répertoire
ASCII.

Sans doute Windows envoie du UTF-8 à MDK, MDK le stocke et le renvoie
sans modification (donc aucun problème vu de Windows), mais l'affichage
sous MDK croit recevoir du ISO-8859-1 du disque alors que c'est du UTF-8,
d'où le 'é' affiché 'é'. En effet, UTF-8 encode 'é' sur deux octets.

ISO-8859-1
'é' sur un octet = 233 = 11101001
'Ã' sur un octet = 195 = 11000011
'©' sur un octet = 169 = 10101001

UTF-8
'é' sur deux octets = 195 169 = (110)00011 (10)101001

UTF-8 permet d'encoder 7 bits significatifs sur un octet 0vvvvvvv,
donc tous les caractères ASCII se retrouvent encodés comme d'habitude
et on ne remarque pas forcément un mauvais réglage. En revanche UTF-8
a besoin de deux octets pour encoder 8 bits significatifs et là on
observe un problème en cas de mauvais réglage.

UTF-8 permet d'encoder jusqu'à 11 bits sur 2 octets 110vvvvv 10vvvvvv,
c'est ce qui est fait ici.

Note : Pour tout savoir sur la conception (par Ken Thompson et
Rob Pike) et l'implémentation d'UTF-8, il y a une histoire à
<http://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt>.

> Sur la RH, le fichier créé depuis Linux me donnera comme résultat 
> "├®dition.txt" (les symboles varient un peu selon l'affichage), et un 

Les deux caractères '├®' sont encodés 226 148 156 194 174, soit
(1110)0010 (10)010100 (10)011100 (110)00010 (10)101110.
Comment 11101001 a pu se transformer en cela ?

Si on prend (110)00010 (10)101110, on remarque que les bits
significatifs sont 10101110, soit la même valeur que le second
octet d'encodage UTF-8. On aurait donc eu des caractères encodés
en UTF-8, puis pris pour des caractères ISO-8859-1 et réencodés
en UTF-8 (double-encodage en UTF-8) ? Mais je sèche sur le premier
caractère (1110)0010 (10)010100 (10)011100.

Marc Mongenet