Le code ASCII

Nous n'avons pas le choix, nous devons adopter une convention qui associera un nombre à un symbole d'écriture, puisque nous disposons de machines qui ne savent manipuler que des nombres. Nous créerons ainsi une table d'équivalence entre des valeurs numériques et des symboles d'écriture. Toutes les parties qui communiqueront entre elles en adoptant la même convention arriveront donc, en principe, à se comprendre.

Figurez-vous que l'informatique n'a pas toujours été aussi compliquée. Voici un exemple de terminal informatique fort courant à une certaine époque . Cette magnifique bestiole, appelée « télétype » du nom de l'entreprise qui la fabriquait (Les plus jeunes ne peuvent pas connaitre, la machine date de 1967), servait à dialoguer avec un ordinateur, par le truchement d'une liaison série RS232, que nous connaissons toujours, même si ses jours sont désormais comptés. En ces temps reculés de l'informatique, le tube cathodique n'était pas un périphérique courant. On utilisait volontiers à la place une imprimante, le plus souvent à boule ou à marguerite. Cette machine disposait par ailleurs d'un lecteur/perforateur de ruban en papier (trou/pas trou –> 1/0). Mais pour intéressantes qu'elles soient, ces considérations archéologiques nous écartent de notre sujet initial…

La liaison RS232 prévoit de transmettre en série (bit par bit) un mot de 8 bits en utilisant le bit de poids le plus fort (bit 7) comme bit de parité, pour effectuer un contrôle de validité de la donnée. Le principe est simple : dans un octet, le bit de parité est ajusté de manière à ce que le nombre de 1 soit toujours pair (ou impair, ça dépend de la convention adoptée).

Dans ce cas de figure, il n'y a que 7 bits (b0 à b6)  qui sont significatifs d'une donnée, le dernier bit servant juste à ajuster la parité.

»L' American Standard Code for Information Interchange » (ASCII) s'est donc ingénié à coder chaque caractère d'une machine à écrire sous la forme d'une combinaison de 7 bits. En décimal, nous obtenons des valeurs comprises entre 0 et 127.

Comme la base binaire (0 ou 1), si elle est très commode pour un calculateur électronique, l'est beaucoup moins pour le cerveau humain, nous allons utiliser une autre base qui, si elle n'est guère plus « parlante », offre tout de même l'avantage d'aboutir à une écriture beaucoup plus compacte. Cette base devra être une puissance de 2, la plus courante étant la base hexadécimale, parce que chaque « digit » hexadécimal va représenter une combinaison de 4 bits :

Mais il est aussi possible d'utiliser de l'octal, sur trois bits.

Pourquoi pas la base 10 à laquelle nous sommes habitués depuis notre plus tendre enfance ? Parce que, malheureusement, 10 n'est pas une puissance de 2 et qu'un « digit » décimal ne représente donc pas toutes les combinaisons que l'on peut faire avec un groupe de n bits. 4 c'est trop (hexadécimal) et 3 c'est pas assez (octal). Plus mathématiquement, on ne peut pas trouver de valeur entière de n telle que 10=2ⁿ. Essayez donc de résoudre n=Log(10)/Log(2).

Certains ont mis en œuvre un codage appelé BCD (Binary Coded Decimal). Le principe est simple : chaque « digit » décimal (de 0 à 9) est codé sur un quartet. Certaines combinaisons de bits sont donc impossibles.

• 9 va donner 1001
• 10 donnera 0001 0000 et non pas 1010 

Mais revenons à notre code ASCII ; 7 bits sont-ils suffisants ? Oui et non…

D'abord, dans une machine à écrire, il n'y a pas que des caractères imprimables. Il y a aussi des « caractères de contrôle », comme le saut de ligne, le retour-charriot, le saut de page, la tabulation, le retour arrière… Tous ces caractères doivent aussi être codés pour que l'ordinateur puisse efficacement piloter une imprimante.

De plus, pour transmettre convenablement un texte, il faudra quelques sémaphores pour indiquer par exemple quand commence le texte, quand il finit…

Enfin, suivant les langues, même lorsqu'elles exploitent l'alphabet latin, certaines lettres sont altérées différemment. L'anglais n'utilise pas d'accents mais la plupart des autres langues les exploitent plus ou moins parcimonieusement.

Au final, si 7 bits suffisent généralement pour une langue donnée, éventuellement en faisant l'impasse sur certains symboles peu usités comme [ ou ], nous ne pourrons pas coder l'ensemble des caractères nécessaires pour la totalité des langues utilisant l'alphabet latin.

La norme iso-646 définit un code ASCII sur 7 bits. Ce code, parfaitement adapté à l'anglais US, l'est moins pour les autres langues. Nous assistons donc à la création d'une multitude de « dialectes ASCII », où certains caractères sont remplacés par d'autres suivant les besoins locaux. Les lecteurs les plus « anciens » se rappelleront peut-être des configurations hasardeuses de certaines imprimantes pour arriver à ce qu'elles impriment un français lisible…

Les « caractères » sur fond bleu sont les caractères non imprimables. Pour bien lire le tableau, il faut construire le code hexadécimal en prenant d'abord le digit de la ligne, puis le digit de la colonne. Par exemple, la lettre « n » a pour code hexadécimal 6E.

Comme vous le constatez, il n'y a aucune lettre accentuée dans ce codage. Ce dernier a donc été joyeusement « localisé » pour satisfaire aux exigences des divers pays utilisant l'alphabet latin. Cette situation aboutit rapidement à une impasse, les fichiers ainsi construits n'étant plus exportables dans d'autres pays. De plus, vous constaterez aisément que l'ajout de caractères supplémentaires (le « é », le « ç », le « à » etc.) implique obligatoirement la suppression d'autres caractères (le « [ », le « ] », le « # » etc.). Ceux qui ont quelques notions de programmation comprendront à quel point c'est facile d'écrire du code avec un jeu de caractères amputé de ces symboles. Dans la pratique, les programmeurs étaient condamnés à utiliser un clavier US.

Avec les avancées de la technique, le huitième bit qui servait pour le contrôle de parité, contrôle rendu de plus en plus inutile, va être utilisé pour coder plus de caractères. Deux fois plus, finalement.

Ainsi, le codage « iso-latin-1 », également connu sous le nom de « iso-8859-1 » propose à peu près le codage suivant

Comme vous pouvez le constater ici :

• les codes ASCII de 0 à 7F (127 en décimal) demeurent inchangés ;
• les codes supérieurs (ceux qui ont le bit 7 à 1) représentent quelques symboles supplémentaires, ainsi qu'une panoplie de lettres accentuées qui satisfont aux exigences des langues de l'Europe de l'Ouest.

Pourquoi « à peu près » ? Le codage ci dessus est une interprétation de la norme iso-8859-1 par notre ami Microsoft qui a un peu bricolé pour ajouter quelques symboles de plus, dont celui de l'euro… La conséquence en est qu'une fois de plus, Windows n'est compatible qu'avec lui-même. Fort heureusement, nous verrons qu'il demeure possible d'adopter un codage plus officiel avec les applications communicantes, mais avec des limites. Notez que si l'on peut reprocher à Microsoft de ne pas suivre les normes, il faut aussi reprocher aux normes d'êtres imparfaites et assez peu réactives.

Pour ajouter à la complexité, la norme iso-8859 définit pas moins de 15 versions différentes, pour satisfaire à tous les besoins mondiaux. A titre d'information, la norme iso-8859-15 devrait pouvoir être utilisée pour l'Europe de l'Ouest avec plus de « bonheur » que l'iso-8859-1.

Finalement, ce bit de plus ne fait que déplacer le problème sans toutefois l'éliminer, nous ne disposons toujours pas d'un système normalisé universel.

Croyez-vous que la situation est suffisamment confuse comme ça ? Vous vous trompez ! D'autres choses existent, souvent venant de chez IBM.

Je me contenterai de vous citer la définition issue du « jargon français » :

Extended Binary Coded Decimal Interchange Code.
Jeu de caractères utilisé sur des dinosaures d'IBM. Il existe en 6 versions parfaitement incompatibles entre elles, et il y manque pas mal de points de ponctuation absolument nécessaires dans beaucoup de langages modernes (les caractères manquants varient de plus d'une version à l'autre…) IBM est accusé d'en avoir fait une tactique de contrôle des utilisateurs. (© Jargon File 3.0.0).

Il existe quelques « moulinettes » capables de convertir tant bien que mal des fichiers codés sous cette forme en fichiers ASCII.

Bien que l'EBCDIC soit aujourd'hui tout à fait confidentiel, puisqu'il ne concerne que les vieilles machines IBM, il faut en tenir compte pour les échanges de données inter plateformes, jusqu'à extinction totale de la race (nous ne devons plus en être très loin).

Lorsque IBM a créé le PC (Personal Computer, faut-il le rappeler ?), des jeux de caractères ont été créés sur 8 bits, spécifiquement pour ces machines. Ci-dessous la page de code 437 (CP437). Attention, ce tableau se lit dans l'autre sens, le quartet de poids faible est celui de la ligne et le quartet de poids fort est celui de la colonne.

Tous les petits « grigris » à partir du code B0 étaient destinés à faire de l'art ASCII étendu. De jolies interfaces pseudo graphiques sur des terminaux en mode texte.

Si cette page de code est compatible avec l'ASCII US 7 bits (iso-646) il n'en est rien pour le reste, avec aucune iso-8859. Cette situation a été assez pénalisante, aux débuts de Windows, où l'on devait souvent jongler avec les fichiers issus d'applications DOS et Windows.

Et si l'on construisait une table de codage sur 16 bits et pourquoi pas même 32 bits ? Là, on aurait de la place pour entrer dans une seule et unique table tous les symboles que l'espèce humaine a pu inventer…

Rassurez-vous, on y a déjà pensé, ceci s'appelle l'UNICODE et le projet fait même l'objet d'une normalisation, iso-10646-1.

Pourquoi faire, me direz-vous ? Avons-nous besoin de manipuler dans un même document tous les symboles d'écriture que ce monde a inventé ?

Il y a au moins deux bonnes raisons qui militent en faveur d'UNICODE :

• si tout le monde utilise UNICODE, il n'y a plus de problèmes, tout le monde peut écrire dans sa langue maternelle en utilisant la même convention ;
• les pauvres gens qui font de la traduction de documents d'une langue dans une autre n'auront plus à jongler en permanence avec les divers iso-8859 pour rédiger leur travail.

Cependant UNICODE utilisé brutalement aboutirait à un quadruplement du volume pour un document donné, chaque caractère étant désormais encodé sur 32 bits et non plus 8, le tout avec probablement plein de zéros et quelques octets constants dans chaque document. Une solution à ce petit problème s'appelle UTF-8. Notez que pour nous, européens, qui utilisons l'alphabet latin, UTF-8 ne sera pas trop pénalisant en termes de volume de données. Pour d'autres, chinois ou japonais par exemple, le problème sera différent.

Cette normalisation, bien que complexe, est en voie de devenir l'usage courant. Ce n'est pas encore le cas partout, et comme ce codage n'est compatible avec les autres que sur les 127 premiers symboles (ASCII), nous n'avons pas encore fini de voir des choses comme « De la difficulté avérée du bon aménagement des caractères dans l'encodage numérique » fleurir dans nos e-mails et sur certaines pages du web.

La raison ? Le texte a été encodé en UTF-8 et, pour une raison quelconque, a été interprété par le client comme de l'iso-8859-1. Notez que l'inverse peut aussi se produire et reste aussi inesthétique.

Comme vous le voyez, nous sommes encore loin de disposer d'un système de codage efficace des divers symboles utilisés dans le monde pour communiquer. La situation parait déjà assez désespérante, sinon désespérée, mais rassurez-vous, nous n'avons pas encore tout vu. Notons tout de même que :

• les dernières moutures de MS Windows (Vista, Seven) semblent vouloir se conformer à UTF-8 ;
• la plupart des distributions GNU/Linux sont configurées par défaut pour utiliser UTF-8 ;
• les « browsers » modernes savent afficher correctement du code UTF-8 pour peu qu'ils soient informés correctement qu'ils reçoivent un tel codage.

Dans ces conditions, le pire est peut-être déjà derrière nous ? Pour autant, nous ne sommes pas encore sortis de ce bourbier.

Les passionnés de la chose trouveront ici beaucoup de détails sur les divers codages existants.