15 mars 2018

Encodage des caractères

Bonjour,

Comme vous le savez sans doute, je suis un technicien. J’aime la technologie et les ordinateurs. Je pratique la programmation depuis les années 80 et les choses ont évolué sans véritablement changer. La technologie, ce sont des balanciers, des solutions sont trouvées à des problèmes qui entrainent d’autres problèmes qui mènent à d’autres solutions qui reviennent au problème d’origine.

Je voudrais aujourd’hui vous parler du codage des caractères en informatique. Oh, je sais que ce n’est pas un sujet qui vous passionne, mais vous avez été confrontés à des problèmes liés à ce codage et vous en rencontrerez encore. C’est un problème sans fin, qui si il n’est pas compris vous ennuiera encore longtemps.

A l’origine

A l’origine on peut parler du morse. Oui, ce codage des caractères avec des longs et des courts. Longs et courts c’est comme des zéros et des uns, cela s’apparente à un système binaire et donc proche de l’informatique. Mais en fait le morse n’est pas un système binaire, car il y a trois éléments et pas deux, car il y a aussi les silences entre les lettres. Un meilleur exemple de système binaire proche de l’informatique est le braille.

Le braille

Le braille est un système qui au départ comprend six points. Vous avez une matrice de deux colonnes et trois lignes contenant ou non un point. C’est exactement un système binaire sur six bits (un bit vaut un ou zéro), et donc cela permet 2x2x2x2x2x2 = 64 possibilités. Mais 64 possibilités, ce n’est pas assez pour les 26 lettres majuscules, les 26 lettres minuscules, les 10 chiffres, les caractères de ponctuation, les caractères mathématiques, etc… Comment résoudre ce problème ? On a créé des caractère spéciaux qui n’existent qu’en braille pour dire que le caractère suivant veut dire autre chose. Ainsi le caractère pour le chiffre un est le même que le caractère pour la lettre A mais précédé d’un code qui indique que ce qui suis est un caractère mathématique. On pourrait me faire remarquer que le codage ci-dessous n’est pas celui utilisé actuellement, et c’est vrai. Actuellement on utilise plus couramment le codage « Antoine » pour les chiffres. Mais le principe est le même que dans le codage original de Louis Braille.

L’octet

En informatique, l’unité utilisée est l’octet. L’octet, c’est comme un caractère braille mais avec huit points à la place de six. Huit points (bits) cela fait 2x2x2x2x2x2x2x2 = 256 combinaisons. Largement de quoi coder tous nos caractères latins. Mais il faut savoir qu’au tout début de l’informatique, il y avait des ordinateurs sur 7 bits… (et même moins). Les américains qui ne pensent qu’à eux ont créé l’ASCII (American Standard Code for Information Interchange), car il fallait bien être d’accord sur ce qu’était un A ! Un A majuscule c’est le code 65, un B 66, etc… Un espace c’est le code 32, un chiffre un c’est le code 49. C’était parfait. Mais comme les américains écrivent anglais, ils ont oublié les accents.

Tant que l’on parle anglais, pas de problème, les ordinateurs du monde entier se comprennent. Mais dès qu’il y a des accents ! Catastrophe. Chaque constructeur a utilisé son propre codage pour les 128 codes libres qui ne sont pas dans l’ASCII. Pire, chaque constructeur a fait un codage par pays. Car selon les langues ce ne sont pas les mêmes accents, voir pas les mêmes alphabets.

Cela vous concerne

Mais vous allez me dire, qu’en ai-je à faire ? J’ai lu tout ce bla-bla et qu’en fais-je ? Et bien lorsque vous récupérez un fichier Windows sous MacOSX, vous pouvez tout à fait avoir un problème avec les caractères accentués. Cela est dû au fait que Windows et MacOSX n’utilisent pas le même codage et que si le fichier que vous transférez ne contient pas le nom du codage utilisé (certains formats de fichiers peuvent contenir le nom du codage qu’ils utilisent, ainsi le programme peut faire la conversion) l’ordinateur utilisera le codage par défaut de l’ordinateur ou du programme. C’est vrai par exemple avec les fichiers CSV que vous exportez de Excel, Numbers, MySQL, ou de mon application Elèves…

Quand vous importez un fichier et que celui-ci contient des caractères bizarres à la place des caractères accentués, (voir ci-dessous) vous devez indiquer dans quel codage est votre fichier d’origine. Par exemple dans Safari, si vous êtes sur un site où il y a le problème, vous allez dans le menu « présentation », puis « encodage du texte » et vous choisissez le bon encodage.

Unicode

Conscient du problème des échanges de textes non-anglais dans le monde, les grands groupes informatiques ont décidé de faire un format commun. Ce format est Unicode, qui comprend des dizaines de milliers de caractères possibles ! Les caractères anglais évidement, mais aussi les accents du français, de l’espagnol, l’alphabet arabe et cyrillique, les vidéogramme japonais, tout !

Evidemment ce codage ne peut pas tenir sur 8 bits, il est sur 32. Mais cela quadruple la taille des fichiers et il a été évidemment trouvé une solution. Cette solution c’est l’UTF-8, de l’Unicode sur 8 bits. Comment faire ce miracle ? Comme avec le braille ! Les caractères ASCII restent valables, mais les accents et autres caractères sont codés sur plusieurs octets. Dans l’exemple ci-dessus vous pouvez voir un fichier codé en UTF-8 mais affiché comme si il était du Mac Roman. Vous voyez que les accents sont remplacés par deux caractères et que le premier est le signe racine carré. Quand vous voyez que les caractères accentués sont remplacés par plusieurs caractères, vous devez mettre votre encodage en UTF-8 et votre texte sera parfait.

Conclusion

J’attends vos retours pour savoir si ce genre d’article peut vous intéresser. C’est un peu loin de mes applications même si les exports CSV sont possibles depuis JeValide, ISBN et Elèves.

Vous aurez peut-être remarqué que la solution à taille variable du morse se retrouve cent ans plus tard dans l’UTF-8. La technologie fait souvent des allers et retours ainsi. On croit avoir résolu un problème et on en crée d’autres (par exemple en UTF-8 il faut décoder tous les octets pour savoir combien il y a de caractères ce qui peut entrainer des bugs car le nombre d’octets et le nombre de caractères diffères).

Il n’est pas toujours possible de donner une recette pour résoudre un problème, il faut parfois comprendre le problème et tout devient simple. A contrario, si on ne comprend pas le problème celui-ci ressemble à un dilemme. L’ordinateur devient une espèce d’objet magique incompréhensible, alors qu’il n’est qu’un outil qu’il faut apprendre à maîtriser.

Emmanuel CROMBEZ