Les encodages de caractères

Nous avons vu que les ordinateurs stockent des nombres :

• une image est représentée par une suite de nombres,
• un texte est représenté par une suite de nombres.

On a donc besoin d'une table de conversion lorsqu'on veut écrire un texte ou qu'on veut le lire . Sans la technique de conversion, impossible de savoir les nombres qu'il faut écrire à la place du texte initial ou comment décoder les chiffres qu'on est en train de lire !

La transformation caractère en nombre est ce qu'on nomme l'encodage.

La transformation nombre vers caractère est ce qu'on nomme le décodage.

Dans la mesure où cette introduction aux différents encodages ne concernent que la gestion des caractères imprimables, j'ai volontairement omis les différences entre les caractères de contrôle de différents encodages. Si vous voulez plus d'information sur ceux-ci, Wikipedia est votre ami. Leurs documents sont très complets au sujet des encodages.

Aujourd'hui, nous allons pouvoir comprendre ceci :

1 - ASCII

Pour rappel, voilà le code ASCII qui encode 128 caractères avec des valeurs allant de 0 à 127. Cet encodage était le premier standard de représentation des caractères. Il fut publié en 1968. Pour représenter ses 128 caractères, il nécessitait 7 bits (presque un octet). Cela représentait une place mémoire non négligeable à l'époque : on était à quelques centaines de kilo-octets (ko) à l'époque. De quoi encoder un petit livre uniquement, ou une image de qualité très médiocre.

Un petit bout de la table ASCII

Sous cette forme de tableau avec une ligne par caractère, cela va donner 128 lignes. On représentera plutôt la correspondance via un tableau à deux entrées. Voilà la table totale entre nombre décimal et caractère pour le code ASCII :

J'ai fait apparaître les caractères non imprimables par le symbole ¤¤¤. Il s'agit de codes de contrôle (saut à la ligne, retour chariot ...). On parle de caractères non imprimables.

Table ASCII en version décimale

Comme vous le voyez, les caractères codés sont peu nombreux et aucun ne comporte d'accent.

Pour lire le code en base 10 d'un caractère, il suffit de remplacer le x de l'unité par sa valeur lue sur la colonne. Ainsi, R possède le code 82 car il est à l'intersection de la ligne 8_ et de la colonne _2.

Comme vous le voyez, la base 10 n'est pas la base naturelle de l'ASCII : on ne peut pas remplir des cases 128 et 129 qui n'existe pas en ASCII pur. En réalité, il est plus commode de représenter les codes des caractères en base 16 (hexadécimal).

Table ASCII en version hexadécimale

R correspondait à  82  en décimal. Ici, on lit  52 ! Bon, en réalité, c'est 52 en base 16 et ça donne donc 5*16 + 2*1 = 82. Ouf. On obtient bien le même code.

Pour éviter de confondre les deux, on peut écrire ceci : R correspond à (  82  )₁₀ ou (  52  )₁₆.

Le précurseur était l'iso-646 dont l'ASCII est une variante.

Comme vous le voyez, il est facile de comprendre que  A5  ou  7F  sont des nombres hexadécimaux. Mais si on écrit juste 52, on ne peut pas savoir s'il s'agit de 52 en base 10 (en décimal) ou 52 en base 16 (en hexadécimal).

Les langages informatiques ont tous une notation permettant de distinguer les deux. Ils n'utilisent pas la méthode de l'indice car dans un fichier texte pur, il est impossible d'avoir des indices ou des exposants.

Pour les langages dérivés du C, on utilise le préfixe 0x. Ainsi  0x52   désigne 52 en base 16.

A partir de maintenant, nous utiliserons cette notation. Dans les différents tableau, vous pouvez néanmoins obtenir le code décimal d'un caractère en restant stationnaire au dessus de la case.

La technologie évoluant, l'espace mémoire devint un peu plus important, on créa des tables ASCII étendues à 8 bits. La première moitié de la table est presque toujours comptatible avec ASCII (au moins sur les caractères imprimables). On introduit de nouveaux caractères sur les lignes suivantes pour coder les caractères sur 8 bits et atteindre donc 256 possibilités, codées de 0 à 255. C'est pourquoi on parle pour ces encodages et les suivants d'encodage 1 octet ou encodage 8 bits ou encore ASCII étendu si les premières lignes sont les mêmes que l'ASCII. Par contre, là où ASCII est un vrai standard 7 bits, il n'existe pas une table unique d'encodage sur 8 bits.

2 - cp437 et cp850

Les cp sont les encodages "code page" créés par IBM sur les premiers ordinateurs personnels. L'une des plus connue est la page de code 437 utilisé par IBM pour le système DOS et ces consoles. Aujourd'hui, la plupart des consoles des ordinateurs américains fonctionnent avec cet encodage. En Europe, c'est la page de code 850, une variante du 437 qui est utilisée sur beaucoup de consoles.

En rose, on visualise les cases ayant une valeur différente du standard 8 bits qui a servi de base à l'UNICODE : le latin-1 (qui apparait plus tard chronologiquement).

Si on ne donne que la seconde moitié : la cp437 en version courte. On y trouve beaucoup de symboles car à cette époque, l'affichage se faisait intégralement en caractères : les graphiques (comme les séparateurs de tableaux) devaient donc être réalisés avec des caractères également.

Pour la cp850, on obtient parfois d'autres caractères, plus utilisés pour le public d'Europe de l'Ouest.

3 - iso-8859-1 ou latin-1

D'autres encodages gardèrent les 128 premiers identiques à l'ASCII et rajoutèrent les caractères utiles aux langues utilisées dans une large zone géographique. Comme vous pouvez le noter, la table ASCII ne possèdent pas beaucoup d'accents et les deux tables précédentes ne permettent pas d'écrire correctement toutes les langues d'Europe de l'Ouest...

L'un des encodages les plus utilisés fut l'encodage iso-8859-1, également nommé latin-1. Cet encodage fut l'encodage utilisé historiquement sur les systèmes Windows, UNIX et Amiga. Cette table d'encodage est compatible avec les 256 premiers caractères de l'Unicode.

La première version date de 1986.

En hexa, on obtient de 00 à FF

Cette table est entièrement compatible avec l'Unicode.

L'encodage iso-8859-1 en version courte (Europe de l'Ouest). Orienté langage, on trouve les caractères utilisés pour écrire en Europe de l'Ouest et pas les caractères permettant de faire du graphisme comme dans cp850.

L'encodage iso-8859-2 ou latin-2 en version courte (Europe Centrale)

L'encodage iso-8859-3 ou latin-3 en version courte (Europe du Sud). Quelques valeurs ne sont pas attribuées et sont représentées pas un point d'interrogation.

L'encodage iso-8859-11 ou Thai. Sans surprise, tous les caractères ou presque ont changé dans la seconde partie du code (les caractères 128 à 255).

L'encodage iso-8859-15 ou latin-9 : Il s'agit d'une sort de mise à jour de iso8859-1 ou latin-1 qui remplace quelques caractères peu utilisés par l'euro € et les lettres Š, š, Ž, ž, Œ, œ, et Ÿ, qui permettent de finaliser réellement les caractères utilisés en Français, Finlandais et Estonien.

4 - windows-1252 ou cp1252 ou ANSI

Après l'exemple des pages de code des constructeurs, et d'un exemple de code régional (le iso-8859-1 pour l'Europe de l'Ouest), voilà celles des concepteurs de systèmes d'exploitation. Commencons par le plus connu à l'époque.

Windows a développé une variante de l'iso-8859-1 nommé windows-1252. Avec le monopole de Windows à l'époque, cette table d'encodage est un peu devenu un standard. Beaucoup la nommèrent ANSI, confondant la page avec la vraie signification d'ANSI : ANSI veut dire en réalité American National Standards Institute (Institut de normalisation américaine) et il s'agit d'un organisme qui supervise le développement des normes américaines. La table cp1252 ou windows-1252 n'a rien à voir avec l'organisme qui a normalisé l'encodage ASCII, mais l'usage est resté et la documentation technique de Windows n'a rien fait pour clarifier la situation. Ainsi, cet encodage a été souvent nommé ANSI et beaucoup continuent à croire qu'il s'agit de la version "officielle" de l'extension de l'ASCII. Je le répète donc : cet encodage n'est pas la version officielle de l'ASCII étendu sur 8 bits.

La différence avec l'encodage précédent n'apparait que sur les lignes 8_ et 9_ qui sont des caractères de contrôle en iso-8859-1 et où windows-1252 vient glisser quelques caractères imprimables ou n'utilise pas de caractères de contrôle (les cases avec le point d'interrogation).

Attention, la notion d'encodage ANSI fait surtout référence à l'encodage de base du système d'exploitation Windows pour les systèmes américains. Or, même avec Windows il n'agit pas toujours du 1252 qui est installé en tant qu'encodage de base. Il existe de multiples variantes en fonction de la zone géographique du matériel. Pour rajouter un peu à la confusion des différentes versions des encodages iso-8859, Windows a donc créé ses propres variations. Windows-1251 est ainsi l'encodage pour le cyrillique.

L'encodage Windows-1252 en version réduite

Pour information, voilà par exemple le windows-1251 pour le cyrillique.

5 - mac-roman

De la même façon, il y avait des encodages Apple pour Mac, comme le mac-roman, l'équivalent pour l'Europe de l'Ouest de l'iso-8859-1 et de windows-1252.

Remarque : le caractère F0 correspond au sigle d'Apple et n'apparait pas dans l'Unicode.

6 - Unicode

Tant que les ordinateurs ne communiquaient pas entre eux, ou qu'ils le faisaient dans la même langue, cela ne posait pas (trop) de problème. Mais avec l'apparition de la communication globale via Internet, un langage de programmation pouvait créer fonctionner avec un certain encodage à l'interne (par exemple cp1252), créer un fichier texte encodé en latin-3. Et ce fichier pouvait être lu en Turquie par quelqu'un ayant un encodage de type mac-turkish. Bref, les risques d'avoir des affichages bizarres (au mieux), des programmes qui plantent ou des bases de données complétement anéanties (le pire qui soit) devenait non négligeable.

Voici les 256 premiers caractères (qui sont dans le même ordre que latin-1) puis quelques exemples de ce qu'on peut trouver dans l'Unicode. N'hésitez pas à visiter des pages dédiées à Unicode si vous voulez savoir ce qu'on peut y trouver. Plus de 65000 caractères, c'est long à décrire.

Quelques associations numéros - caractères UNICODE

Pour obtenir le numéro en décimal, il suffit de rester stationnaire au dessus du caractère.

Le problème de l'UNICODE : le stockage du numéro !

Avec 2 octets, on a 2¹⁶ = 65536 caractéres différents encodables.

Avec 3 octets, on a 2²⁴ = 16 777 216 caractères différents encodables.

Actuellement, on aurait besoin de 21 bits pour donner un numéro à chaque caractère des tables UNICODES. Soit 3 octets. Un fichier texte qu'on encoderait avec 3 octets par caractère prendrait donc trois fois plus de place qu'un fichier utilisant l'un des encodages qui utilise un octet par caractère.

Or plus un fichier est lourd, plus il prend de temps à transférer et plus il utilise de ressources.

Il a donc fallu trouver un moyen de stocker ces numéros sans nécessairement prendre 3 octets à chaque fois.

7 - UTF-8

C'est sur cette question de taille qu'ont travaillé les créateurs de l'UTF-8. Que veut dire d'ailleurs UTF-8 ?

Si on résume, le principe du code est simple :

• On peut encoder tous les caractères de l'Unicode
• Les caractères très courants (ceux de l'ASCII) nécessite 1 octet de stockage
• Les caractères assez courants nécessitent deux octets de stockage
• Les caractères les moins courants nécessitent de trois octets ou plus

De cette façon, si tout est configuré en UTF-8, les fichiers restent relativement légers car la majorité des caractères restent codés sur 1 octet mais on n'a plus à jongler entre une multitude de tables à un octet.

Un fichier UTF-8 est donc légérement plus lourd qu'un fichier encodé avec une table d'encodage à un octet.

Voici quelques exemples d'encodage UTF-8. On vous donne :

• La valeur décimale du caractère en Unicode
• La valeur hexadécimale du caractère en Unicode
• Le caractère affiché
• La ou les valeurs décilmales des octets pour un encodage UTF-8
• La ou les valeurs hexadécimales des octets pour un encodage UTF-8
• La mauvaise traduction qu'on pourrait faire d'un encodage UTF-8 décodé avec le Latin-1

En regardant la caractère UNICODE numéro 233, vous devriez comprendre la blague avec Perceval : l'UTF-8 encode le é avec deux octets de valeurs  195  et  169 . Si on tente de décoder ceci avec les règles du latin-1, où un octet correspond à un caractère, on va faire afficher les caractères correspondants au code  195  (Ã) puis au code  169  (©).

C'est le genre de choses qu'on peut voir assez fréquemment sur les vieux sites non mis à jour : on tente de décoder un texte en utilisant un autre encodage que celui utilisé pour enregistrer le texte !

Ca fonctionne aussi avec Martine. Vous pouvez tenter une recherche Qwant sur Martine+UTF-8.

C'est pour cela qu'il faut toujours écrire noir sur blanc l'encodage utilisé pour créer une page html, un programme Python, un programme Javascript ... Sinon, on risque de mal décodé les octets représentant le texte si on utilise la mauvaise table de décodage.
Résultat : les caractères ASCII risquent de bien s'afficher, mais pas les autres.

8 - Représentation UTF-8 des 1024 premiers caractères UNICODE

De 256 à 511