Travailler avec des fichiersDe la fenêtre au fichier · 7 min de lecture

Des bits aux lettres

On sait déjà que dans un fichier texte chaque petit paquet de bits représente un caractère. Reste la question évidente : comment la machine fait-elle pour savoir que ce petit paquet de zéros et de uns est un « h » ?

Avec une table. Rien de plus.

Une liste où chaque lettre a un numéro attribué, et ce numéro s'écrit en binaire. La table d'origine date de 1963 et fonctionne toujours pareil : le A est le 65, le a est le 97, l'espace est le 32.

Cet accord est tout ce qu'il faut pour qu'un fichier écrit sur une machine se lise sur une autre, soixante ans plus tard, sans qu'aucune des deux ne sache rien de l'autre.

Hn.º 7201001000
on.º 11101101111
ln.º 10801101100
an.º 9701100001

Ils tiennent tous dans 8 bits.

01001000011011110110110001100001

Chaque tranche est un numéro, et chaque numéro une lettre dans la table.

Une bande de zéros et de uns découpée en tranches de huit.

Les accents et le ç sont le cas bizarre. Les 128 premiers numéros suffisaient pour l'anglais et rien d'autre. Tout ce qui est venu après — accents, ç, emojis — se range avec deux, trois ou quatre petits paquets de bits au lieu d'un.

Voilà d'où vient cette recommandation de ne pas mettre d'accents dans les noms de fichiers : si le fichier voyage vers un système qui interprète ces octets avec une autre table, l'accent casse.

Et voilà d'où vient la bouillie de symboles. Quand tu ouvres un PDF avec le Bloc-notes, ces bits décrivaient un morceau d'image compressée. Le Bloc-notes n'a aucun moyen de le savoir, alors il fait la seule chose qu'il sait faire : il découpe par huit et il cherche dans la table.

La table renvoie toujours quelque chose — et ce quelque chose, c'est la bouillie que tu vois.

Comment le programme sait-il où finit une lettre et où commence la suivante ?

La machine ne sait pas où finit une lettre : elle le suppose.

snack 5 sur 9 · L'extension

Powered by KlugerByte