Vous vous souvenez de ce prof de physique, au collège, qui n’avait pas tenu compte de vos réponses à un contrôle parce que vous n’aviez pas indiqué les unités ?
Vous aviez écrit « 63 » au lieu de « 63 grammes », « 2,83 » au lieu de « 2,83 mètres », etc. Ça vous avait valu un 5/20.
C’était un gros con ce prof.
Sauf qu’il avait raison.
C’était effectivement un gros con, concernant un tas d’aspects de sa personnalité. Mais pour cette histoire d’unité il avait raison.
En informatique, on a un problème équivalent avec les encodages et les caractères spéciaux.
C’est des centimètres ou des inches ?
L’encodage
Vous connaissez peut-être déjà. Il s’agit de la correspondance entre un caractère et la suite de nombre utilisée pour le représenter. Les ordinateurs ne savent rien faire d’autres que gérer des valeurs numériques. Une image, une application, des clics de souris, une connexion internet, les barrettes de RAM, tout ça c’est que des nombres. Il peut y en avoir énormément, et on ne fait pas toujours la même chose avec. Mais c’est des nombres.
Voici quelques exemples.
- Le caractère é (e accent aigu) :
- est représenté par la suite de nombres (195, 169) dans l’encodage ‘UTF-8’,
- est représenté par le nombre unique 233 en ‘Latin-1’,
- ne peut pas être représenté en ‘ASCII’,
- la lettre A majuscule:
- est représentée par le nombre unique 65, en UTF-8, Latin-1 et ASCII
- est représentée par le nombre unique 193 en ‘EBCDIC’ (un encodage bizarre utilisé par IBM).
En détail, c’est un peu plus compliqué que ça, car l’encodage et le jeu de caractères sont deux notions différentes, je n’ai pas parlé du Byte Order Mark, et il existe plusieurs sortes d’EBCDIC (https:// en.wikipedia.org/wiki/EBCDIC). Mais on ne va pas se prendre la tête avec ça.
Donc une chaîne de caractères toute seule, ça ne veut rien dire et si vous ne connaissez pas son encodage, vous ne pouvez pas la manipuler avec certitude.
C’est ça qui fait que les accents sont parfois tout pourris dans une page web ou un fichier Excel. Le texte est dans un certain encodage, l’application qui le manipule croit que c’en est un autre, et paf pastèque.
Vous pouvez décider que « fuck les accents », et obligez vos utilisateurs à n’utiliser que les caractères ASCII. Mais il faut avoir conscience que cela implique « fuck tous les alphabets non latins » : « fuck les russes, les chinois, les arabes, les hébreux, les mathématiciens et les gens qui écrivent avec des smileys ».
À tout cela s’ajoute une autre couche de confusion possible.
Les caractères spéciaux
Alors voilà. Vous avez créé un site web ou une application dans laquelle l’utilisateur peut saisir du texte (par exemple pour ajouter un commentaire, décrire son chien, etc). Vous maîtrisez parfaitement ce que vous avez développé, et connaissez donc l’encodage dans lequel la chaîne de caractère a été saisie. Super ! Tout est OK ? On peut arrêter de se poser des questions ?
Que diantre nenni !
Il faudra peut-être appliquer une transformation pour protéger ou interpréter certains caractères spéciaux.
Vous voulez enregistrer cette chaîne dans une base de données ? Attention aux injections SQL, vous devez protéger les simple-quotes en les remplaçant par deux simple-quotes à la suite. (Les requêtes paramétrées permettent de le faire automatiquement).
Vous voulez la réafficher dans une page HTML ? Attention aux failles XSS et aux balises HTML. Vous devez protéger les caractères ‘<‘ et ‘>’ en les remplaçant par les HTML entities. Et comme les HTML entities s’écrivent avec le caractère ‘&’, il faut lui aussi le remplacer par son HTML entity.
C’est une URL ? Pensez à la convertir en ‘url-encoding’ : remplacer les espaces par des %20, etc.
C’est une ligne de commande ? Il va peut-être falloir protéger les antislashes en les doublant. Ou pas. Ça dépend de ce que vous avez décidé, mais il sera de bon ton de prévenir l’utilisateur des opérations appliquées.
C’est un chemin vers un fichier ? Très bien, vous n’aurez peut-être pas de conversion à faire. Mais si vous utilisez ce chemin dans une ligne de commande, n’oubliez pas de l’entourer par des guillemets, au cas où il comporterait des espaces. Vous connaissez, bien sûr, l’encodage de votre système de fichiers ?
Autres choses
Cette histoire d’unités et de vilains profs de physique est transposable à d’autres types de données : les dates.
Je ne parle même pas du format de représentation. « 02/03/14 23:45:56 », vous savez déjà que ça ne veut rien dire. Le ’02’ c’est le jour où c’est le mois ? (Au passage, merci les anglais de faire, une fois de plus, à l’envers de tout le monde). Le ’14’, c’est 1914 ou 2014 ?
Évitons ces pièges stupides, et indiquons les dates au format ISO 8601 : 2014-03-02 23:45:56. Voilà, et maintenant, plus d’ambigüité !
Perdu ! Elle est bien votre date, mais c’est quel fuseau horaire ? C’est l’heure d’été ou l’heure d’hiver ? Au fait, vous saviez que les américains effectuaient le changement d’heure, mais pas exactement au même moment dans l’année par rapport à nous ? Et les leaps seconds, on les prend en compte ou pas ?
La solution à cette histoire de date est de tout gérer avec des timestamps, et de convertir vers/à partir d’autres formats uniquement lors des entrées-sorties de ces dates dans votre programme. Le timestamp définit un nombre de secondes depuis 1970-01-01 00:00 UTC.
À partir de ce nombre de secondes, on peut retrouver toute la date. De plus, les opérations de calcul avec les intervalles sont grandement simplifiées. Par contre, ça met en incubation des bugs encore plus rigolos que celui de l’an 2000 (https:// fr.wikipedia.org/wiki/Bug_de_l’an_2038).
Quel bazar ces données ! Au moins, avec les nombres on n’est pas embêtés. Quoi que… Si vous faites de la programmation bas niveau (ce qui signifie « proche de la machine », et non pas « programmation pour les gros teubés »), un monde de normes et de notations peut vous jaillir à la figure. Comment vous représentez les nombres à virgules ? flottantes ou virtuels ? IEEE 754 ou autre chose ? Vos entiers, vous les voulez signés ou non signés ? Avec du complément à deux ou autrement ?
Même pour la donnée la plus simple possible : des nombres entiers positifs, vous devrez peut-être vous poser des questions : big-endian ou little-endian ? Des bits de contrôle ? de parité ?
Il y a encore un tas d’autres choses où le lien entre la donnée et la méta-donnée est indispensable. Vous avez récupéré un fichier, super, mais c’est pour en faire quoi ? C’est une image ? Un texte ? Autre chose ? Et sous quel format ? Et si vous tombez sur une vieille cassette vidéo, c’est du PAL ou du Secam ?
Tout ça pour dire qu’il faut faire attention aux données qu’on manipule, depuis la plus simple variable string jusqu’aux tera-octets de base de données. Il y a plein de programmeurs qui n’en ont pas toujours conscience, ça met le bazar, et je voulais vous sensibiliser sur ce sujet, tel le gros con de prof de physique que je ne suis pas.
Ce sera tout pour aujourd’hui
J’essaie de faire un article de blog par mois, et là ça a été un peu juste. Comme d’hab’, c’est la faute au monde réel, mais aussi à Dead Cells, le nouveau jeu de la Motion Twin. J’aime beaucoup, il y a énormément d’idées intéressantes, et une ambiance mignonne-glauque assez bien travaillée.
Du coup je vous laisse, je vais essayer de dégommer des Slashers au corps à corps.
Réchèr : le Grand Tout 