Un exemple intéressant de codage de l’information est la représentation des signes de l’écriture, caractères alphabétiques, sinogrammes, hiéroglyphes, chiffres, etc., désignés par le terme générique caractère.
Aux débuts du traitement des textes par ordinateur existaient deux codes rivaux : ASCII (American Standard Code for Information Interchange) et EBCDIC (Extended Binary Coded Decimal Interchange Code). Le code ASCII utilisait 7 bits, EBCDIC 8 bits, ils ne permettaient de représenter que les caractères de l’alphabet latin (sans accents, cédilles, trémas ni autres umlauts), les chiffres, les signes de ponctuation et quelques autres symboles. Ainsi, le chiffre 1 était codé 0110001 en ASCII et 11110001 en EBCDIC, pour la lettre A on avait respectivement 1000001 et 11000001, etc.
Depuis 1991 existe une norme internationale, Unicode, constituée d’un répertoire de 137 929 caractères, qui permet de désigner chaque caractère de toutes les écritures passées et présentes [1] par un nom et un code numérique, nommé point de code (codepoint).
Il existe plusieurs normes de codage informatique pour représenter les caractères Unicode, la plus répandue est UTF-8. Il est bon de savoir que les codes UTF-8 sont de taille variable, ils comportent au minimum 8 bits (d’où le nom de la norme), mais peuvent en compter jusqu’à 32 [2]. Ainsi :
| Nom Unicode du caractère | Point de code | UTF-8 (décimal) | UTF-8 (hexadécimal) |
| Right single quotation mark ’ | U+2019 | 226 128 153 | e28099 |
| Apostrophe ’ | U+0027 | 39 | 27 |
| Latin small letter m | U+006D | 109 | 6d |
| Latin capital letter E with grave È | U+00C8 | 195 136 | c388 |
Le caractère Right single quotation mark est utilisé pour représenter l’apostrophe latine, en français par exemple, de façon plus élégante que par l’apostrophe de l’anglais, qui s’accommode bien de sa laideur parce qu’il l’utilise fort peu.
Pour la notation décimale des codes, la valeur binaire de chaque octet est convertie en base 10, ce qui donne un nombre compris entre 0 et 255, ainsi par exemple pour È :
(c3)16 = (11000011)2 = (195)10
(88)16 = (10001000)2 = (136)10
Le code hexadécimal c388 est fourni par la table de caractères, le code UTF-8 de È est donc (1100001110001000)2. C’est parce que 16 est une puissance de 2 que le code hexadécimal est obtenu simplement par la concaténation des conversions en base 16 de chaque octet. La notation hexadécimale est expliquée plus en détail ici.
Rien dans le texte binaire ne permet de détecter quel codage est utilisé, cette information doit être fournie explicitement par l’auteur du document (ou par son logiciel).
Richesse et difficultés d’UTF-8
À l’époque d’Ascii et d’EBCDIC la vie était simple, du moins pour les anglophones qui se contentent de l’alphabet latin sans accents ni autres signes diacritiques, ou en d’autres termes sans caractères composés (é est le caractère composé de e et de l’accent aigu). Des bricolages inavouables ont permis de coder sur un octet la plupart des autres écritures alphabétiques, telles que les alphabets latin avec signes diacritiques, cyrillique, arabe, hébreu, grec : en effet un octet de huit bits peut représenter 256 signes. Dans ce monde, une suite de n octets pouvait représenter une chaîne de n caractères, soit un texte lisible à l’écran par un humain.
Mais pour les locuteurs de langues écrites en sinogrammes ou en écriture devanagari il n’en allait pas ainsi, ce pourquoi on a inventé Unicode et UTF-8, cf. ci-dessus. Du coup le codage de ces écritures ne respecte plus la correspondance d’un octet pour un caractère, ce qui complique énormément le traitement des textes. Manuel Serrano, auteur du compilateur Scheme Bigloo, m’a dit que l’adaptation à UTF-8 avait été une des transitions les plus difficiles qu’il ait eues à effectuer. Une chaîne de n caractères peut avoir une longueur en octets variable selon l’alphabet, et peu prévisible pour qui ignore UTF-8. Ainsi en Scheme avec Bigloo, et pour les écritures latine, bengali, éthiopienne et chinoise :
Les caractères de Rust et les séquences biologiques
Rust ne connaît que les caractères UTF-8. Je croyais qu’ils étaient tous sur quatre octets, avec l’avantage que procureraient la simplicité et l’uniformité, mais c’est comme en Scheme, ce que me fait remarquer, en lecteur avisé, Bastien Vigneron (cf. aussi les commentaire de Martin Larralde à la fin de l’article) :
Pour les biologistes et les chimistes, les séquences nucléiques sont écrites dans un alphabet de quatre caractères, ATGC pour l’ADN, AUGC pour l’ARN. Les séquences protéiques sont écrites dans un alphabet plus complexe, de vingt acides aminés (22 si l’on en compte deux très rares). Les banques de séquences comportent également des identifiants, des références bibliographiques et d’autres informations (features), toujours écrites en anglais, donc à l’origine codées en Ascii.
Une séquence biologique est donc une chaîne, potentiellement très longue, de caractères pris dans un alphabet simple. On trouve en effet dans les banques de séquences nucléiques des génomes bactériens entiers, soit des millions de nucléotides. Traiter ces séquences en UTF-8 semble un gaspillage éventuellement important. C’est pourquoi j’ai tenté d’écrire un programme Rust où les séquences seraient codées par des vecteurs d’octets, type de données tout à fait disponible dans le langage. Voici le résultat, et les conclusions que j’ai tirées de cette expérience.
Les données
Voici à titre d’exemple un fichier au format FASTA qui donne le code d’un gène d’une orchidée :
– gi|2765658| donne l’identifiant GenBank de la séquence ;
– emb|Z78533.1| donne son identifiant EMBL (European Molecular Biology Laboratory).
Le programme
Ce petit programme d’exemple lit deux séquences dans des fichiers texte simples d’une seule ligne (le traitement du format FASTA reste à écrire), afin éventuellement de les aligner, mais ici et pour l’instant je me contente de les afficher. Les noms des deux fichiers qui contiennent chacun une séquence sont passés en arguments sur la ligne de commande d’invocation du programme, et lus dans une structure (struct) de type Config. Pour éviter les quatre octets du type caractère de Rust, les caractères du texte de la séquence sont déclarés du type u8 (unsigned 8), soit un type numérique de taille 1 octet.
Comme d’habitude, le plus compliqué ce sont les entrées-sorties, bien que ce ne soit que technique.
Exemple d’exécution et conclusion
Comme les caractères des séquences sont de type unsigned 8, ils apparaissent naturellement sous forme numérique, il faudrait une fonction de transcodage pour les afficher sous forme de texte alphabétique.
Quelle conclusion tirer de cette expérience ? Est-ce se compliquer la vie inutilement ? De nos jours l’espace en mémoire ou sur disque n’est plus une denrée aussi rare que dans les années 1970, et appliquer un algorithme d’alignement de séquences à des génomes entiers de plusieurs millions de nucléotides ne semble pas un exercice raisonnable (mais ici les biologistes me contrediront peut-être).
Les commentaires de Bastien Vigneron ci-dessus et de Martin Larralde ci-dessous me suggèrent qu’UTF-8 n’est pas vraiment une bonne idée et que je devrais persister pour un type Vec. En effet, la question n’est pas tant celle de la place mémoire que celle de sa variabilité : avoir des chaînes de longueurs variables et, surtout, imprévisibles est supportable pour de l’édition de textes, mais pas pour du calcul.