Michel CARRARE - Codages ANSI et UTF-8 des caractères

C'est le codage sur 8 bits des caractères, tel qu'il est défini par l'American National Standards Institute. Chaque caractère est représentés par un entier de 0 à 256. Vous en avez la liste dans le tableau des caractères et de leur conversion URL et HTML. Il faut noter que les 32 premiers entiers (de 0 à 31) sont réservés pour des commandes systèmes et ne sont pas utilisable pour le texte. Les caractères simples (en gros ceux utilisés en anglais) occupent les places de 32 à 127. Les caractères spéciaux (en particulier tous les caractères accentués du français, la fameuse cédille et bien d'autres...) occupent les places de 128 à 255.

Les avatars de l'ANSI

En Europe occidentale, le codage ANSI est également connu sous le nom de jeu de caractères ISO-8859-1, où l'ISO est l'International Standards Organization. Si vous allez voir la source de ce document, vous verrez au début, la ligne content="text/html; charset=iso-8859-1" qui signifie que c'est ce codage qui est utilisé pour cette page. Comme nous allons le voir, L'UTF-8 est un concurrent sérieux pour l'ANSI. C'est pourquoi il est essentiel de toujours préciser le codage utilisé, sinon on s'en remet aux détecteurs de jeux de caractères, qui devinent (guess en anglais) le codage utilisé.

Le codage UTF-8

L'ANSI permet de coder 256 caractères, L'UTF-8, plus de 2 millions ! On comprend vite le niveau de la concurrence. De plus, si l'on écrit du texte sans aucun caractère spécial, l'UTF-8 ne prend pas plus de place que l'ANSI. C'est magique, n'est-ce-pas ? En fait, avec le système UTF-8, seuls les caractères au-delà de 128 sont codés sur plus d'un octet. Avant de voir comment fonctionne ce codage, précisons que les lettres UTF signifient Unicode Transformation Format et que le 8 signifie 8 bits ou plus.

Le principe UTF-8

Plus le numéro du caractère est grand, plus le nombre d'octets utilisés est grand (de 1 octet au minimum jusqu'à 4 au maximum). S'il faut plus d'un octet pour le codage, alors le nombre de 1 consécutifs dans le premier octet donne justement le nombre d'octets nécessaires :

Caractères de 0 à 127 : 1 octet
0xxxxxxx
Caractères de 128 à 2 047 : 2 octets
110xxxxx 10xxxxxx
Caractères de 2 048 à 65 535 : 3 octets
1110xxxx 10xxxxxx 10xxxxxx
Caractères de 65 536 à 2 097 151 : 4 octets
11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

Un exemple de codage UTF-8

Prenons le caractére é. En regardant dans le tableau des caractères ANSI, on découvre que son numéro est 233 en décimal, ou encore E9 en hexadécimal. D'après le paragraphe précédent, 233 étant compris entre 128 et 2 047, é aura besoin de 2 octets pour être codé en UTF-8, i.e. il utilisera le schéma suivant : 110xxxxx 10xxxxxx. Il ne reste plus qu'à remplir les 11 emplacements tenus par les x. Pour ce faire, on commence par convertir 233 en binaire, ce qui donne 1110 1001. Puis on remplit les bits du schéma de droite à gauche avec les bits du caractère pris aussi de droite à gauche :110xxx11 10101001. Enfin, on bouche les trous avec des 0, ce qui donne le résultat :11000011 10101001.

Les problèmes

Il est clair que le codage UTF-8 sur 2 octets de é est différent de son codage ANSI sur 1 octet. De fait, nous l'avons vu, seuls les 127 premiers caractères (qui représentent ce que l'on appelle l'ASCII simple) ont le même codage en ANSI et en UTF-8. Ainsi, on peut s'attendre à avoir des problèmes si le système utilisé pour l'encodage du texte n'est pas le même que celui utilisé pour sa lecture. Sans surprise, il y a des problèmes ! Le tableau suivant montre les quatre cas possibles et les deux types de problèmes que l'on peut rencontrer.


Texte codé en ANSI et lu comme de l'ANSI		Texte codé en UTF-8 et lu comme de l'ANSI



Texte codé en ANSI et lu comme de l'UTF-8		Texte codé en UTF-8 et lu comme de l'UTF-8

Codage ANSI lu comme de l'UTF-8

C'est le cas en bas à gauche dans le tableau ci-dessus. Le cas qui nous fait voyager, pour un cours instant, en Extrême-Orient grâce aux magnifiques caractères qu'il produit. Essayons de comprendre ce qui se passe. Prenons la partie étudiés par du texte codé en ANSI et voyons ce que donne se passage lorsqu'il est codé. En utilisant le tableau des caractères ANSI, on peut retrouver le code de chaque lettre formant cette partie du texte. Nous utiliserons le code hexadécimal. Nous le savons désormais, le é a pour code E9 en hexadécimal. Le t a pour code 74 (toujours en hexadécimal), le u a pour code 75... On obtient finalement, pour la partie de texte ci-dessus : E9 74 75 64 69 E9 73 20 70 61 72. Vous noterez qu'il y a bien 11 caractères, le blanc entre étudiés et par étant naturellement pris en compte. Lorsque ce code ANSI est pris pour de l'UTF-8, le premier octet rencontré est celui du é, dont on a vu plus haut dans l'exemple qu'il est formé des bits : 1110 1001. Or, dans le système de codage UTF-8, le fait que cet octet débute par trois 1 consécutifs signifie que le caractère correspondant est codé sur trois octets. Ainsi, l'analyse UTF-8 de notre extrait de texte (codé rappelons-le en ANSI) va prendre les trois premiers octets E9 74 75 (qui correspondent aux trois lettres étu) et les considérer comme un seul caractère UTF-8. Le résultat saute aux yeux : les trois lettres ont disparu et ont été remplacées par le magnifique caractère oriental que l'on voit.

Remarques sur ce type d'erreur

En étudiant l'exemple d'erreur ci-dessus d'un peu plus près, on découvre que l'interprétation UTF-8 de ce codage ANSI est fautive. En effet, les deuxième et troisième octets, 74 et 75, s'écrivent respectivement en binaire : 0111 0100 et 0111 0101. Ils commencent donc tout deux par un 0. Ceci n'est pas conforme au système de codage UTF-8 qui réclame au contraire que pour un caractère codé sur trois octets, les deux octets suivant le premier commencent par un 1. C'est pour ce genre de raison que peu d'éditeurs de texte font ce type d'erreur. Il y en a pourtant ! L'un d'eux, que nous ne citerons pas, détecte l'UTF-8 par la présence dans le corps du texte de la séquence charset=utf-8. Si un fichier contient cette phrase (ce qui est le cas de la page que vous êtes en train de lire) et est codé en ANSI (ce qui est aussi le cas de cette page), vous connaissez la suite si vous ouvrez ce fichier avec cet éditeur. N'oubliez pas qu'il est fortement conseillé, chaque fois que cela est possible, d'expliciter le codage. C'est encore le cas de cette page comme nous l'avons dit plus haut, dans le paragraphe sur les avatars de l'ANSI.

Codage UTF-8 lu comme de l'ANSI

Voyons à présent l'erreur inverse, la lecture ANSI d'un fichier UTF-8. C'est le cas en haut à droite du tableau, le cas le moins romantique et le plus courant. Vous avez certainement déjà reçu des mails avec des mots comme celui-ci : Ã©tudiÃ©s. De nombreuses machines en effet utilisent l'UTF-8 par défaut pour le texte et donc en particulier pour les mails. Or, si la machine qui reçoit le mail ne sait pas qu'il s'agit d'UTF-8 et utilise l'ANSI par défaut, le mail sera mal interprété et il apparaîtra des mots comme ci-dessus. Que se passe-t-il ? Nous avons vu dans l'exemple de codage UTF-8 expliqué plus haut, que le résultat du codage sur deux octets du caractère é était : 11000011 10101001. Si ce code est lu comme de l'ANSI, l'analyse va conclure à la présence de deux caractères, chacun codé sur un octet. Le premier octet donne le nombre décimal 195, le second donne 169. En se reportant à la table des caractères ANSI, on trouve qu'il s'agit bien des deux symboles obtenus, à savoir Ã et ©. CQFD

Remarques sur ce deuxième type d'erreur

Ce deuxième type d'erreur est surprenant puisqu'il existe normalement une signature des fichiers UTF-8. Cette signature est formée des trois octets suivants, placés en début de fichier : EF BB BF. On appelle cela un BOM, pour Byte Order Mark, marque d'ordre des octets. En fait, pour l'UTF-8, ce nom est mal choisi car l'ordre des octets est toujours le même. Il n'y a pas de big- et de little-endian pour l'UTF-8 comme il y en a pour l'Unicode 16. (Ces histoires d'endian feront d'ailleurs bientôt l'objet d'une page spéciale.) Nom bien ou mal choisi, ce BOM devrait résoudre tous les problèmes. Or, il n'en est rien, au contraire, en réalité il en ajoute plutôt. Lors du transfert d'information, en effet, il est courant que les premiers octets renseignent sur l'application devant ouvrir le fichier ou sur le protocole nécessaire à son traitement. Le BOM, en cheval de Troie, vient perturber cela, ce qui peut provoquer des cataclysmes. La conséquence est que le BOM est rarement utilisé. Quand il l'est, il arrive souvent que les programmes n'en tiennent pas compte ou qu'ils le suppriment. Enfin, dans les mails UTF-8, la plupart du temps le BOM est présent, mais au début du corps du mail, le Header (l'en-tête) ne l'ayant pas. Or, le BOM doit être au début pour faire son office (bon ou mauvais). Au milieu, il ne sert à rien, sinon à rajouter dans le mail quelques caractères bizarres du style ï » ¿. Des questions ? N'hésitez pas. Retour en haut de la page.


© 2005 Michel Carrare