Convertir des Kio en ko

Un kibioctet vaut exactement 1 024 octets. Le nom a été introduit en 1998 pour que « kilooctet » puisse de nouveau valoir 1 000 — l’habitude n’a jamais tout à fait cédé.

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.

Le facteur vaut 1,024, et à peu près personne ne le trimballe. Arrondi à 1,02, il s'écarte de 0,39 % — invisible sur de petits nombres, et devenu une unité entière vers 1 000 KiB.

C'est ce chiffre-là qu'il faut connaître avant d'arrondir : pas l'erreur elle-même, mais l'endroit où elle cesse d'être négligeable. En dessous, le facteur court est le bon choix ; au-dessus, servez-vous du champ ci-dessus, qui n'arrondit qu'au moment d'afficher.

Un KiB vaut 1 024 fois l'unité du dessous ; un kB, 1 000. Sur cette page, c'est l'écart entre 1,024 kB et 1 kB — 2,4 % — et il grandit à chaque palier : négligeable sur une photo, visible sur un disque dur.

Le mystère de l'espace disque manquant tient tout entier là-dedans, et sur cette page il vaut 2,4 %. Un disque vendu en kB contient exactement ce qui est annoncé ; Windows divise ensuite par 1 024 au lieu de 1 000, garde le nom décimal, et affiche 1 kB là où la boîte annonçait 1,024 kB. macOS compte ces tailles en unités décimales depuis 10.6, d'où le même disque qui paraît de deux tailles sur deux machines — rien n'a disparu et personne n'arrondit : les mêmes octets portent deux noms.

Chaque conversion entre les échelles binaire et décimale est une puissance de 1,024, et celle-ci est la seule où la puissance est un. Un chiffre en Kio devient un chiffre en ko en multipliant par exactement 1,024 : 500 Kio font 512 ko, 250 Kio font 256, 1 000 Kio font 1 024. Il n’y a aucun arrondi là-dedans, et les nombres des deux côtés restent reconnaissables, ce qui en fait le meilleur endroit pour construire l’intuition de la famille entière.

Cette netteté est pourquoi cette paire est l’endroit où bâtir une intuition pour toute la famille. Le 1 024 qui apparaît à droite de 1 000 Kio est le même 1 024 qui définit le kibioctet, et le voir ressortir de la multiplication rend la relation concrète d’une façon que les 7,37 pour cent au cran giga ne le font jamais, et c’est l’investissement qui se rentabilise sur la première fois où le même réflexe évite une erreur au cran supérieur.

La raison de convertir dans ce sens est presque toujours la publication. Un outil a mesuré quelque chose en Kio, et le chiffre doit maintenant se trouver à côté de nombres qui ont été mesurés en décimal : un poids de page publié par un concurrent, une limite de spécification, un budget convenu dans un document, un tableau dans un rapport. Le laisser en Kio est défendable et rend la comparaison fausse de 2,4 pour cent d’une façon qu’aucun lecteur ne remarquera, et c’est exactement le genre d’erreur qui survit à la relecture.

L’autre échec est de convertir en silence. Un chiffre qui a été ajusté devrait le dire, parce que la prochaine personne à le mesurer avec l’outil d’origine récupérera le nombre d’origine et conclura à une régression. Publier « 174 ko (170 Kio mesurés) » coûte onze caractères et empêche un après-midi, et c’est l’investissement qui se rentabilise dès la première fois qu’un lecteur vérifie.

L’outillage de performance web est l’endroit le plus courant où un développeur en activité rencontre cette paire, parce que deux outils dans le même navigateur utilisent des conventions différentes. Lighthouse rapporte les tailles de transfert et de ressource en kibioctets. Le panneau réseau rapporte des kilooctets décimaux. Lancez les deux sur une page et les totaux diffèrent de 2,4 pour cent, de manière constante, sans bogue nulle part, et c’est l’explication que la plupart des lecteurs cherchent pendant une heure avant de la trouver.

L’écart est suffisamment petit pour passer inaperçu jusqu’à ce qu’il tombe sur un seuil. Un budget de 170 ko écrit à partir d’un outil et appliqué avec l’autre admet ou rejette une page à 172 selon le sens dans lequel la paire a été utilisée, et l’enquête qui en résulte cherche une ressource qui a changé plutôt qu’une unité qui ne l’a pas fait. Écrire l’unité dans le budget est toute la correction, et c’est l’habitude qui distingue un budget qu’on peut tenir d’un budget qu’on ne peut pas vérifier.

Le disque haute densité 3,5 pouces contenait 2 880 secteurs de 512 octets, ce qui fait 1 474 560 octets : 1 440 Kio, ou 1,41 Mio, ou 1,47 Mo. Le chiffre sur l’étiquette, 1,44, n’est aucun de ceux-là. Il a été obtenu en prenant le compte en kilooctets binaires et en divisant par un mille décimal — une unité hybride qui n’existe nulle part ailleurs et que tout le monde a utilisée pendant vingt ans, et qui est l’erreur que la normalisation de 1998 visait à empêcher.

C’est la preuve la plus claire qui subsiste que les deux conventions étaient mélangées à l’intérieur d’une seule étiquette bien avant que quiconque propose une correction. Les noms de la CEI sont arrivés en 1998 pour rendre exactement cela impossible à écrire, et la disquette reste l’exemple à conserver parce que l’arithmétique est suffisamment petite pour être vérifiée à la main et que le résultat est sans ambiguïté une troisième chose, et c’est la meilleure illustration de ce que la convention a corrigé.

Les sources sont cohérentes sur la base et incohérentes sur l’étiquette. ls -lh et du -h impriment des puissances de 1 024 sous un K nu. free rapporte des kibioctets. /proc/meminfo écrit ko et entend Kio. L’outillage de build et les bundleurs varient, et plusieurs rapportent en décimal. Lighthouse écrit Kio proprement, et c’est l’outillage qui mérite d’être imité pour ce qui concerne l’étiquetage.

Donc la question pratique n’est pas de savoir dans quelle unité un nombre est, mais si l’outil qui l’a produit le dit. Là où il le dit — Kio, ou un drapeau --si explicite — la conversion est arithmétique. Là où il ne le dit pas, le test le plus rapide est un fichier qui fait exactement 1 024 octets : un outil qui montre 1,0 est binaire, un qui montre 1,02 est décimal, et cela tranche la question en moins de temps qu’il n’en faut pour lire la page de manuel.

Le cran kilo est où la divergence commence et où elle est la plus petite. 2,4 pour cent est à l’intérieur du bruit de la plupart des mesures, confortablement à l’intérieur de la variation entre deux chargements de page, et suffisamment petit pour que traiter Kio et ko comme la même chose soit très près d’être défendable à cette échelle, et c’est la raison pour laquelle la plupart des lecteurs ne s’en soucient pas.

La raison d’être strict quand même est que l’habitude ne reste pas à cette échelle. Le même raisonnement appliqué un cran de préfixe plus haut donne une erreur de 4,86 pour cent, deux crans plus haut 7,37, trois crans plus haut 9,95, et à ce niveau c’est un disque. Quelqu’un qui est soigneux au cran kilooctet a déjà construit le réflexe qui compte au cran téraoctet, là où la même insouciance cesse d’être bon marché, et c’est l’argument en faveur d’une rigueur qui n’est pas strictement nécessaire aujourd’hui mais qui paiera demain.

Toute taille qui apparaît en public sera éventuellement remesurée par quelqu’un avec un outillage différent, et le chiffre qui survit est celui qui a son unité attachée. Un poids de page, un budget d’asset, une taille de paquet, une limite de charge utile : chacun est un chiffre que quelqu’un vérifiera, et un écart de 2,4 pour cent est exactement assez grand pour ressembler à une régression et exactement assez petit pour être écarté comme du bruit, ce qui est la pire combinaison disponible, et c’est l’écart qui déclenche les disputes inutiles.

La convention qui fonctionne est de publier le chiffre décimal avec l’unité épelée, et de noter l’outil de mesure là où il n’est pas évident. Ce n’est pas une divulgation plus lourde que toute autre mesure ne le porte, et elle transforme une dispute sur le chiffre de qui a raison en une vérification de cinq secondes où les deux ont raison, et c’est l’investissement qui épargne la conversation la prochaine fois que le chiffre sera cité.

Les assets web sont cités à trois tailles différentes et une seule d’entre elles est celle qui compte. La taille non compressée est ce qu’est le fichier sur disque. La taille gzippée est ce que la plupart des serveurs envoient. La taille brotli est ce que les serveurs modernes envoient, typiquement quinze à vingt pour cent en-dessous de gzip sur du texte. Un bundle JavaScript décrit comme 300 ko peut faire 90 gzippé et 78 avec brotli, et les trois chiffres sont vrais, et c’est ce qui rend la publication non étiquetée ambiguë.

Donc un chiffre publié a besoin de deux étiquettes plutôt qu’une : la compression et l’unité. « 78 ko brotli » est une affirmation que quelqu’un peut vérifier ; « 78 Kio » seul laisse le lecteur à 2,4 pour cent près, et un « 78 ko » nu le laisse se demander laquelle des trois mesures c’était. Vu la fréquence à laquelle ces chiffres apparaissent dans les comparaisons entre outils et frameworks, l’étiquetage fait plus de travail que le dernier chiffre de la valeur, et c’est l’étiquetage qui distingue une comparaison défendable d’une dispute.