Convertir des ko en o

Un kilooctet vaut 1 000 octets quand c’est un organisme de normalisation qui le définit, et 1 024 quand c’est un système d’exploitation. Cette page compte en 1 000 ; l’unité valant 1 024 s’appelle kibioctet.

Un octet vaut huit bits — c’est d’ailleurs ce que le mot dit, là où l’anglais *byte* ne dit rien de la taille. Elle n’a pas toujours été fixée : les premiers ordinateurs employaient six, sept ou neuf bits. Huit s’est imposé parce qu’un caractère y tient et que le nombre se coupe proprement en deux.

Passer des kilooctets aux octets déplace la virgule de 3 rangs vers la droite, et rien d'autre ne change. Aucun facteur à retenir, aucun arrondi à trancher : les chiffres restent dans le même ordre, seule leur position bouge.

1 234 kB font 1234000 B — les mêmes chiffres, décalés. C'est la seule conversion que vous pouvez vérifier d'un coup d'œil : si les chiffres du résultat ne sont pas ceux du départ, ce n'est pas cette conversion qui les a changés.

Le décimal fait de cette conversion la plus simple des unités de données : kilo veut dire 10³, donc un kilooctet fait 1 000 octets et 47 kB font 47 000. C’est la signification SI du préfixe, la signification employée par toute norme réseau, et la signification derrière les capacités auxquelles le stockage se vend. Les chiffres ne bougent pas et seule la virgule se déplace.

La lecture binaire donne 1 024 octets, une unité qui s’appelle correctement le kibioctet et s’écrit KiB. Les deux sont à 2,4 % d’écart, ce qui est la plus petite distance entre une paire décimale et binaire — elle monte à 4,9 % au méga, à 7,4 au giga et à 10 au téra. C’est cette étroitesse qui explique que l’ambiguïté ait survécu ici le plus longtemps : à l’échelle du kilooctet, la différence n’est presque jamais assez grande pour qu’on remarque qu’on se trompait d’unité.

Le cas d’une seule lettre vaut huit fois plus que toute la question 1 000 contre 1 024. B est un octet, b est un bit, et il y a huit bits dans un octet, de sorte que 1 kB fait 8 kb et que 100 kB font 800 kb. Les fichiers, la mémoire et le stockage se comptent en octets ; les débits de ligne, les bitrates et tout ce qui se mesure par seconde sur un fil se comptent en bits, par une convention qui remonte aux liens série et qui n’a jamais changé.

La conséquence pratique est qu’un chiffre auquel est accroché un « par seconde » doit être divisé par huit avant d’être comparé à un fichier. Un flux audio à 256 kbit/s fait 32 ko par seconde, ce qui donne 115 Mo par heure. Une liaison à 64 kbit/s transfère 8 ko par seconde. Lire l’un comme des octets surestime le débit d’un facteur huit et produit des plans qui ne peuvent pas fonctionner.

L’endroit où la plupart des gens rencontrent cette conversion tous les jours, c’est un budget de performance web : un plafond de tant de kilooctets de JavaScript, de CSS ou de poids total de page, vérifié contre une taille de transfert qu’un outil rapporte en octets. Ces budgets sont décimaux, parce qu’ils sont des nombres ronds choisis par des humains et comparés à des mesures réseau qui utilisent des puissances de dix. Un budget de script de 170 kB vaut 170 000 octets.

Ce qui compte plus que le diviseur, c’est la taille qui est mesurée. Le chiffre qui compte contre le budget est la taille de transfert compressée, parce que c’est elle qui traverse le réseau, et pour le JavaScript c’est typiquement un tiers du fichier sur disque. Un bundle de 520 000 octets non compressés peut arriver en 160 000 octets de brotli et passer un budget de 170 ko confortablement — donc une comparaison entre un chiffre non compressé et un budget n’est pas une comparaison du tout.

Sous le mégaoctet, les nombres qui façonnent tout sont des puissances de deux plutôt que des puissances de dix. Un secteur de disque fait 512 ou 4 096 octets ; une page mémoire fait 4 096 sur presque tout système actuel ; un bloc de système de fichiers fait en général 4 096 ; un segment TCP sur un Ethernet ordinaire transporte environ 1 460 octets de charge utile. Aucun de ces nombres n’est un nombre rond de kilooctets dans aucun des deux systèmes, et tous décident de comportements que la conversion d’unités ne change pas.

C’est pourquoi un fichier de 1 ko occupe 4 096 octets et un fichier de 5 ko en occupe 8 192. C’est aussi pourquoi les tailles de tampon sont choisies à 4 096, 8 192 ou 65 536 plutôt qu’à 4 000 ou 50 000 : un tampon aligné sur une page ou un bloc se déplace en unités entières, et un tampon mal aligné en chevauche deux. À cette échelle, l’instinct utile n’est pas « quel kilooctet » mais « à quelle frontière ce nombre est-il proche ».

Une limite exprimée en kilooctets sur du texte est une limite en octets, et UTF-8 ne dépense pas un octet par caractère. L’ASCII simple coûte un octet, mais les lettres latines accentuées, le grec et le cyrillique en coûtent deux, la plupart des caractères CJK en coûtent trois, et les émojis et beaucoup de symboles en coûtent quatre. Donc un champ de 2 ko contient 2 000 caractères anglais, environ 1 900 caractères de français avec accents, et 500 émojis.

La distinction se voit partout où une limite est appliquée ailleurs que là où elle a été déclarée. Une colonne de base de données peut être déclarée en caractères tandis qu’un index, un champ de protocole ou une limite de cookie plus loin dans la chaîne compte en octets, et une valeur qui passe l’une est refusée par l’autre. Quand une limite est vérifiée contre une mesure en octets, l’hypothèse prudente est que tout ce qui suit compte aussi en octets.

Un kilooctet fait à peu près 1 000 caractères d’anglais clair, ce qui est un long paragraphe ou un court corps de courriel. Une requête HTTP minimale avec ses en-têtes pèse un à deux kilooctets avant les cookies, et les cookies la poussent plus loin ; une petite réponse JSON d’API pèse quelques kilooctets ; un sous-ensemble de police web pour un poids fait 15 à 30 ko ; un favicon pèse quelques kilooctets ; un fichier CSS typique après compression pèse des dizaines de kilooctets.

C’est à cela que la conversion sert vraiment. Quand un outil rapporte 47 318 octets, l’appeler 47 ko le replace immédiatement — plus gros qu’une requête, plus petit qu’un fichier de police, taille plausible pour une feuille de style compressée. Le diviseur précis est sans importance pour ce jugement, et c’est la raison honnête pour laquelle l’ambiguïté du kilooctet n’a jamais valu la peine d’être discutée à ce bout de l’échelle.

Un test tranche. Prenez une valeur qui fait exactement 1 024 octets : un outil qui la rapporte en 1,02 kB est décimal, et un qui la rapporte en 1,0 ko compte en kibioctets quelles que soient les lettres qu’il imprime. Sous Unix, du et df sont binaires par défaut et acceptent un drapeau pour les puissances de dix ; les panneaux réseau des navigateurs et la plupart de l’outillage de performance web rapportent en décimal, ce qui colle à la manière dont les débits sont cités.

Si les deux chiffres que vous comparez diffèrent d’environ 2,4 % et qu’aucune autre explication ne convient, le diviseur est l’explication. S’ils diffèrent d’un facteur quatre sur un petit fichier, c’est l’allocation par blocs. S’ils diffèrent d’environ trois pour un, l’un des deux est compressé et l’autre non. Ces trois vérifications expliquent presque toute divergence à l’échelle du kilooctet, et elles valent la peine d’être menées dans cet ordre.