Convertir des Kio en Mo

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 mégaoctet vaut un million d’octets. Les fabricants de stockage ont toujours compté en décimal, et c’est pourquoi leurs chiffres paraissent plus grands que ce qu’affiche l’ordinateur.

Le facteur vaut 0,001024, et à peu près personne ne le trimballe. Arrondi à 0,00102, 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 0,001 MB et 0,001 MB — 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 0,001 MB là où la boîte annonçait 0,001 MB. 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.

Un fichier annoncé à 24 500 KiB semble tenir dans une limite de 25 Mo avec une marge confortable. Il n'en est rien : 24 500 × 1 024 = 25 088 000 octets, et un plafond de 25 Mo appliqué en octets décimaux le refuse avec 88 000 octets de dépassement. Aucun des deux chiffres n'explique le refus, ce qui pousse à réessayer, à incriminer le service, et bien plus tard à vérifier ce que les deux unités veulent dire.

L'écart cumule deux facteurs. Un kibioctet dépasse un kilooctet de 2,4 pour cent, et il y en a mille par mégaoctet plutôt que 1 024, donc un compte en KiB divisé par mille sous-estime le fichier de 2,4 pour cent à chaque palier. Sur une pièce jointe de quelques kilooctets, cela ne se voit pas. À moins de cinq pour cent d'une limite dure, cela décide du verdict.

Multiplier par 1 024 pour repasser en octets, puis diviser par un million pour arriver aux mégaoctets. 24 500 × 1 024 = 25 088 000, et cela fait 25,088 Mo. En une seule étape, c'est la multiplication par 0,001 024, qui est exacte et termine, sans arrondi caché. Deux calculateurs corrects donnent le même résultat au dernier chiffre ; l'incertitude n'est jamais dans l'arithmétique mais dans ce que l'autre bout compte.

La vérification qui débusque un sens inversé est la direction du changement. De KiB vers Mo, la valeur numérique doit chuter d'un facteur mille environ, et un peu moins que mille, parce que le kibioctet est l'unité la plus grande. Un résultat qui tombe à exactement un millième a perdu les 2,4 pour cent ; un résultat qui tombe à 1 024 fois moins est en fait converti vers le Mio, pas le Mo.

La plupart des services grand public affichent la limite en Mo et l'appliquent en octets décimaux, de sorte que 25 Mo vaut 25 000 000 d'octets. D'autres l'appliquent en binaire, ce qui donne 26 214 400 octets, soit 4,9 pour cent de plus. La documentation précise rarement laquelle, et la différence n'apparaît qu'au moment du refus, qui est le pire moment pour enquêter.

La stratégie sûre est l'indifférence plutôt que la précision. Un fichier qui se trouve à moins de cinq pour cent d'un plafond est dans la zone où la réponse dépend d'un détail d'implémentation invisible, et la bonne réponse est de raccourcir le fichier plutôt que de déterminer laquelle des deux lectures s'applique. En dessous de quatre-vingt-dix pour cent du plafond, toutes les interprétations plausibles s'accordent et la question ne se pose plus.

Les pièces jointes d'un courrier ne partent pas telles quelles. Elles sont encodées pour le transport selon un schéma qui représente trois octets par quatre caractères imprimables, ce qui ajoute un tiers, plus quelques sauts de ligne. Un fichier de 20 Mo arrive à la limite comme un message d'environ 27 Mo, et une borne à 25 Mo sur la taille totale du message le refuse confortablement.

C'est cet effet qu'il faut garder en tête, parce qu'il est d'un ordre de grandeur au-dessus de tout ce qui concerne les unités sur cette page. Quand la limite s'applique au message plutôt qu'au fichier, la taille utilisable tourne autour des trois quarts du chiffre affiché. Les téléversements par formulaire ne sont en général pas concernés, parce que le fichier part en octets bruts, mais tout ce qui voyage en courrier porte cette surcharge.

Les dépôts hébergés sont plus sévères que le courrier parce qu'ils vérifient par programme et refusent à la limite exacte. Une plateforme qui prévient au-delà de 50 Mo et refuse au-delà de 100 compare un compte d'octets, et un fichier annoncé à 97 000 KiB représente 99 328 000 octets — sous la limite, mais de moins d'un pour cent, ce qui n'est pas une marge sur laquelle on s'appuie. Les fichiers lourds dans un dépôt restent dans l'historique, donc le contrôle s'applique à tout ce qui a été validé, pas à ce qui est présent.

Le schéma qui évite toute cette catégorie consiste à sortir les gros binaires de l'endroit plafonné : un dépôt d'artefacts, un stockage objet, ou une extension de gestion des fichiers volumineux qui range un pointeur dans le dépôt et le contenu ailleurs. C'est une décision différente de convertir le nombre correctement, et c'est celle qui empêche d'avoir à le convertir à chaque opération.

Quand un fichier dépasse de quelques pour cent, les réductions les moins coûteuses ne sont en général pas la compression. Les images embarquent des vignettes, des profils de couleur et des métadonnées d'appareil photo qui pèsent plusieurs centaines de kilo-octets ; les documents accumulent l'historique des révisions et des polices intégrées ; les archives contiennent souvent des fichiers déjà compressés, sur lesquels une nouvelle compression ne gagne rien. Retirer ce qui ne sert pas bat ce qui reste à comprimer.

Si le contenu lui-même doit maigrir, chaque méthode a son coût. Réencoder une photographie à qualité plus basse est destructif et ne se défait pas ; réduire ses dimensions est en général plus efficace par unité de dégât visible ; découper une archive évite complètement la perte au prix d'un transfert plus lourd. Re-comprimer plusieurs fois un fichier déjà compressé est la seule approche qui rate presque toujours, parce qu'il ne reste presque plus rien à trouver. Sur un fichier en dépassement de quelques pour cent, retirer une ressource embarquée bat en général tout le reste, parce que c'est exact, réversible et sans coût en qualité.

Un outil qui affiche KiB annonce sa convention et mérite confiance. Un outil qui affiche KB ne le fait pas, et sous Windows il s'agit presque certainement de 1 024 octets malgré l'étiquette. Le même fichier peut donc apparaître comme 24 500 KiB dans un outil et 24 500 KB dans un autre, les deux décrivant les mêmes octets, et un seul étant étiqueté honnêtement.

Quand la précision compte, demandez le compte d'octets. Tout gestionnaire de fichiers l'affiche quelque part, tout outil en ligne de commande l'imprime, et cela supprime la question : un compte d'octets n'a pas besoin d'interprétation, se convertit exactement dans toute unité, et c'est le nombre que la limite comparera de toute façon. Quand un travail se répète — export hebdomadaire, lot de numérisations, série de livrables pour un même client —, noter ce compte d'octets une fois dispense de la conversion à chaque tour.