Vous avez dit "caractère" ?

Ces derniers jours, j’ai cherché à mieux comprendre comment gérer UTF-8 dans une de mes applications hobby et j’ai appris pas mal de choses :)

D’abord, j’avais oublié que ASCII était codé sur 7 bits et non pas 8 bits. C’est grâce à ça que UTF-8 est automatiquement compatible avec ASCII (UTF-8 est codé avec des blocs de 8-bits, il leur a suffit de dire que le premier bit est 0 pour les 127 premiers Unicodes encodé en UTF-8).

Les 7 bits m’ont surpris, car ce n’est pas dans nos habituelles puissances de 2. Mais en fait, ASCII fait partie d’une époque où la mémoire et les disques étaient vraiment très cher et il valait donc vraiment mieux ne pas être trop gourmand.

J’ai également appris que pour le langage C, le type char n’est pas forcément dédié aux caractères, mais plutôt à un stockage d’au moins 8 bits[^1].

En pratique, les tailles minimum pour les types C, sont: char avec au moins 8 bits (1 octet), short et integer 16 bits, long 32 bits et long long 64 bits.

Donc, pour pouvoir stocker des entiers sur (au moins) 8 bits (et non pas sur au moins 16 bits), il faut utiliser char. C’est pour stocker ces entiers que l’on a aussi signed char et unsigned char, même si ça n’a pas de sens d’avoir un "caractère signé" a priori :)

Ensuite, j’ai enfin trouvé à quoi sert GString dans GLib et pourquoi c’est toujours dit "compatible UTF-8" partout dans la documentation des fonctions liées à GString: d’après sa description[^2], il faut juste interpréter une GString comme un tableau dynamique de bytes avec la sûreté d’avoir le caractère NUL de terminaison de string et d’avoir une propriété len qui donne le nombre d’octet jusqu’à ce caractère NUL. En plus ce type est associés à plusieurs fonctions généralistes de gestion de texte.

Et là, je me suis dit, mais en fait ça ressemble énormément à std::string de C++: un tableau dynamique d’octets avec une propriété len. Mais si je me souviens bien, il y a d’autres types de string en C++ pour la gestion Unicode ? À quoi servent-ils ?

Eh bien, il y a effectivement std::wstring et 3 autres. wstring utilise le type wchar_t qui est un "wide character", mais qui n’est de nouveau pas définit explicitement dans le standard C.

En cherchant (encore !) des explications sur StackOverflow à propos de wchar, j’ai trouvé ce lien des "personnes qui sont contre leur utilisation": https://utf8everywhere.org/

Ils donnent beaucoup d’information à propos d’UTF-8 vs UTF-16 vs UTF-32 et pourquoi ils pensent que c’était inutile d’inventer wchar_t que finalement seul std::string était utile au C++[^3].

En reprenant son pendant GString en C, j’ai enfin eu la confirmation du pourquoi c’est effectivement suffisant pour stocker des strings en UTF-8, puisqu’il faut juste pouvoir avoir un ByteArray pour le stockage.

Pour l’interprétation de la donnée, il faut évidemment utiliser les bonnes fonctions (comme utiliser g_uf8_normalize avant de faire des comparaisons de string, par exemple) et bien comprendre quelle définition de "caractère" on a en tête (utf8everywhere donne 7 définitions différentes et incompatibles !).

Voilà, maintenant pour mon application en C, je sais que j’ai besoin de pouvoir traverser un mot donné par itération sur ses "grapheme cluster". Il ne me reste plus qu’à trouver un bon moyen de le faire :)

[^1]: le standard n’est pas explicite sur la taille des types de base. char doit pouvoir contenir le basic execution character set et garantir que sa valeur numérique est non-négative. Ce qui revient en pratique à utiliser au moins 8 bits pour char.

[^2]: oui, j’ai donné le lien de l’ancienne documentation, parce que la nouvelle a perdu cette description. J’ai essayé de rapporter le bug, en espérant l’avoir ouvert dans le bon projet !

[^3]: à la condition que le standard dise que le basic execution character set doit être capable de stocker n’importe quelle donnée Unicode. Ce serait facile de le faire grâce à UTF-8 qui est compatible avec la définition actuelle de char.