Chapitre 5 sur 8

Encodage du texte : de l'ASCII à Unicode

Nous le savons, la machine n’utilise que le binaire pour représenter les informations qu’elle traite et stocke. Il faut donc une convention permettant d’encoder et de décoder vers et depuis le binaire.

Afin de faire correspondre un caractère à une suite de bits, on utilise des pages de code.

Une page de code est un standard informatique qui vise à donner un numéro à chaque caractère d’une langue, ou de quelques langues proches. Elle constitue donc une méthode simple de pratiquer du codage des caractères.

Wikipedia

Initialement, chaque fabriquant avait sa propre convention. Étant donné que les documents étaient rarement transférés d’une machine à l’autre, cela ne posait pas vraiment de problème.

Cependant, cela devint rapidement gênant car il est difficile de changer de machine et la compatibilité entre périphériques est douloureuse.

ASCII

C’est ainsi qu’en 1963 sort l’ASCII. Sa première application est pour un téléscripteur, un genre d’imprimante. L’ASCII est codé sur 7 bits, soit 128 possibilités. C’est suffisant pour les caractères non accentués de l’alphabet latin ainsi que la ponctuation et quelques caractères de contrôle.

Néanmoins, dès que l’on veut écrire dans d’autres langues que l’anglais, c’est vite compliqué. Les langues latines peuvent s’écrire de façon partielle en omettant les accents, mais tous les autres alphabets sont alors impossibles à retranscrire.

ISO 8859

L’ASCII est codé sur 7 bits, il reste donc un bit dans l’octet pour coder d’autres informations, permettant de porter la capacité à 256 caractères. Il est donc possible d’étendre l’ASCII, tout en restant compatible avec la table d’origine et ses 127 caractères.

Taille du byte

Comme nous avons pu le voir dans le chapitre sur les unités informatiques, au début, la taille d’un octet n’était pas fixée. Chaque fabriquant faisait un peu à sa sauce.

Ce n’est que dans les années 70 qu’arrivent les premiers microprocesseurs de 8 bits. À cette période, l’usage du byte de 8 bits, l’octet, se répand.

Étant donné que les 128 caractères supplémentaires ne permettent pas de stocker énormément de données, il n’est pas possible de se mettre d’accord sur un standard universel. Les grecs veulent des caractères cyrilliques, les français veulent les caractères accentués etc.

On aboutit ainsi à un standard définissant une multitude de tables, chacune adaptée à une langue ou groupe de langues. Ce sont les tables de la norme ISO 8859.

Microsoft intègre les Windows code pages [EN] dans son système d’exploitation. Ce sont pour la plupart des variantes des tables ISO, mais certaines sont profondément modifiées et d’autres n’ont absolument pas d’équivalent.

Chaque langue possède désormais une page de code lui permettant d’utiliser ses propres signes. L’encodage le plus utilisé est l’ISO 8859-1, aussi appelé Latin-1 et son “équivalent” le Windows-1252. Il prévaut pour l’anglais et la plupart des langues latines.

Ces tables ne sont cependant par parfaites. Elles sont conçues pour l’échange d’informations et non pour l’exhaustivité. Ainsi, il manque certains signes, même en français, nous n’avons pas le “œ” ni le “ÿ” et leurs majuscules respectives. L’euro non plus n’est pas présent dans la table ISO 8859-1.

Arrivée d’internet

Dans les années 90, l’arrivée d’internet et la massification des échanges internationaux de documents montre les limites de l’usage des page de code ISO 8859.

Échange de fichiers

Étant donné qu’il est complexe de “deviner” l’encodage d’un document, un document écrit dans un encodage et plus tard ouvert avec un logiciel qui l’interprète dans un autre encodage, ne sera pas en mesure d’afficher l’ensemble des caractères hors de la plage ASCII.

On peut facilement faire ce test avec un simple éditeur de texte, on créé un fichier que l’on sauvegarde en Windows 1252. Presque tous les éditeurs de code le permettent : Atom, Notepad++, Komodo, Sublime, VSCode…

Ça va les amis ? Petit test des accents é è à ù, yeah !

Comme rien n’indique l’encodage du fichier, le logiciel va l’ouvrir dans son encodage par défaut. Je le ferme et le ré-ouvre avec Atom. Ce dernier tente de l’interpréter en UTF-8, l’encodage n’est pas le bon donc j’obtiens un joli Mojibake.

�a va les amis ? Petit test des accents � � � �, yeah !

Il est possible de tenter de “deviner” l’encodage utilisé au travers d’une analyse statistique :

si les caractères ne sont pas valides, ce n’est pas le bon encodage,
si les caractères sont valides et qu’ils sont souvent utilisés ensembles dans les textes utilisant un encoding donné, alors on a probablement le bon encodage.

Cependant, là encore, le taux de réussite n’est pas de 100%. En résumé, dès que des documents sont partagés de manière internationale entre pays n’utilisant pas les mêmes encodages, ça devient compliqué…

Le web

Le web – web ≠ internet, vous le savez sans doute – est par excellence un média international. Des personnes de tous les pays lisent des documents produits dans tous les pays. Il fallait évidemment trouver un moyen de préciser l’encodage du document.

Sur le web, c’est donc un peu plus smart. Il y a en effet deux mécanismes permettant de préciser l’encodage :

le header HTTP,
le meta tag dans le head du document HTML.

La méthode du header HTTP est en soi la plus robuste : avant même de commencer à interpréter le document, le navigateur sait quel est l’encodage de ce dernier. Néanmoins, nous allons le voir, elle manque de flexibilité dans certains cas.

Prenons le cas d’un hébergeur proposant de l’hébergement mutualisé. Il configure son serveur web, lequel est partagé entre une multitude d’utilisateurs postant des documents dans une pluralité de langues et d’encodages.

Par ailleurs, ces utilisateurs n’ont souvent même pas conscience de ce qu’est un encodage et encore moins de celui qu’ils utilisent. Il faut donc un moyen de préciser l’encodage directement depuis le document lui-même.

Cette manière de faire permet à tous les générateurs de documents (FrontPage power à l’époque !) de préciser l’encodage utilisé pour la page directement dans cette dernière. De cette manière, le navigateur est informé de l’encoding utilisé indépendamment de ce qui est déclaré par le serveur. Si les deux ne correspondent pas, c’est le second qui prend le dessus.

Déclarer l’encoding… de manière encodée

En HTML, le meta tag est déclaré en début de document, dans la partie head comme ci-dessous.

<!DOCTYPE html>
<head>
    <meta charset="UTF-8">
    …
</head>

Le début d’un document HTML vous est probablement familier. Réalisez-vous cependant que pour lire cette balise meta, il faut décoder le document ? C’est le serpent qui se mort la queue.

Heureusement, comme la balise est au tout début du document, il y a de fortes chance pour qu’on ne rencontre aucun caractère qui ne soit pas dans la table ASCII avant la meta charset. Cela permet une lecture sans problème pour tous les encodages compatibles ASCII, donc ISO-8859-x, les tables Windows et l’UTF-8.

Néanmoins, si la page est encodée dans un encodage non rétrocompatible avec l’ASCII (tous les encodings multi-octets), il sera impossible pour le navigateur de déterminer l’encodage par cette méthode, car le fichier sera indéchiffrable.

De nouveau, le logiciel peut alors tenter de “deviner” en essayant plusieurs encodages afin de voir si l’un d’eux semble donner du texte valide. Vous pouvez ainsi tenter d’encoder en UTF-16, vous vous apercevez que votre navigateur – j’ai testé Firefox – l’ouvre sans problème, même si vous avez déclaré de l’UTF-8.

Unicode

Nous voyons bien que la situation commençait à devenir compliquée. Par ailleurs, même si le web s’en sortait plutôt mieux que le reste, choisir un encodage, c’était se limiter à un jeux de caractères.

Citer la bible en araméen sur Wikipedia, pas possible… ça devient vite très restrictif. Le monde a donc besoin d’un nouveau standard permettant de tout encoder. Il permet de mélanger les signes de diverses langues et peut être l’encodage choisi par défaut en toute situation.

La première version d’Unicode sort en 91 – à peu prêt en même temps que la naissance du web. Cette première version définit un encodage unique sur 16 bits.

Il n’est pas compatible avec l’ASCII et prends deux fois plus de place que les encodages déjà en usage, quel que soit le caractère représenté. Pour ces deux raisons, il n’est pas largement adopté.

Deux standards en compétition

Au départ il y a d’un côté l’ISO avec sa norme ISO/CEI 10646 et le Consortium Unicode de l’autre. Tous deux travaillent sur un projet de jeu de caractère universel mais empruntent des chemins différents. Non contentes de la complexité de la norme ISO, les entreprises du logiciel forcent l’organisme à abandonner leur approche. Vous pouvez lire cette histoire plus en détails sur Wikipedia.

Ainsi, dès l’Unicode 1.1, ces deux organismes travaillent de concert afin d’avoir des normes communes et compatibles. L’Unicode est donc un standard attribuant à chaque caractère représentable un unique point de code (uni-code) et définissant différentes méthodes d’encodage (les UTF-n), de comparaison, de tri et de normalisation.

À ce titre parler “d’encodage Unicode” est très flou, car la norme standardise plusieurs encodages. Dans le prochain chapitre, nous allons aborder dans le détail les différents encodages Unicode et découvrir le fonctionnement des règles de tri et comparaison.