Convertir des Mo en Mio

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.

Un mébioctet vaut 1 024 kibioctets, soit 1 048 576 octets. Les outils Linux et les chiffres de mémoire désignent presque toujours cela, même quand ils écrivent « Mo ».

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

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 MiB vaut 1 024 fois l'unité du dessous ; un MB, 1 000. Sur cette page, c'est l'écart entre 1,0486 MB et 1 MB — 4,9 % — 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 4,9 %. Un disque vendu en MB 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 MB là où la boîte annonçait 1,0486 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.

Le gestionnaire de fichiers affiche 24,8 Mo. Le formulaire annonce un maximum de 25 Mo. Le téléversement est refusé, deux fois, et rien sur aucun des deux écrans ne l’explique. Ce qui s’est passé est que les deux nombres sont dans des unités différentes sous la même abréviation : le gestionnaire a divisé par 1 048 576, et le serveur a divisé par 1 000 000, de sorte que 24,8 d’un côté font 26,0 de l’autre.

C’est la façon la plus fréquente dont le partage binaire-décimal coûte du temps à quelqu’un, et elle est entièrement invisible pendant qu’elle se produit. Aucun message d’erreur ne dit « votre mégaoctet n’est pas notre mégaoctet ». Le fichier échoue, la réaction naturelle consiste à le compresser ou à le recadrer, et la personne qui s’y attelle n’apprend jamais que la marge qu’il lui fallait était d’un pour cent plutôt que de dix.

Les plafonds fixés par les fournisseurs sont généralement décimaux, parce qu’ils sont posés par des personnes qui écrivent des spécifications plutôt que par un système d’exploitation qui affiche un répertoire. Un plafond de 25 Mo représente 25 000 000 d’octets, un champ « max 10 Mo » représente 10 000 000, et une limite d’avatar de 2 Mo représente 2 000 000. Quand la limite est appliquée dans le code, c’est presque toujours un entier d’octets comparé directement, et cet entier a été tapé à la main en chiffre décimal rond.

La taille que vous voyez, en revanche, vient de ce qui l’affiche. Windows compte en mébioctets et écrit Mo. La plupart des gestionnaires de fichiers Linux font de même. Le Finder de macOS compte en mégaoctets et le pense. Les deux chiffres devant vous sont donc mesurés différemment, et la différence va toujours dans le même sens : le fichier est plus gros qu’il n’en a l’air.

L’Explorateur de fichiers utilise des pas de 1 024 depuis bien avant que la CEI ne crée le mébioctet en 1998, et il n’a jamais adopté les noms plus récents. Un fichier de 26 004 685 octets s’affiche comme 24,8 Mo, ce qui est une division correcte par 1 048 576 et un étiquetage incorrect. Microsoft a conservé l’étiquette pour rester compatible avec trois décennies de documentation, de captures d’écran et d’habitudes.

La sortie est la boîte de dialogue des propriétés, qui imprime le compte exact d’octets sous la valeur lisible. Ce nombre est sans ambiguïté et c’est ce que le serveur compare à la limite. Quand une limite compte — un téléversement, un quota de boîte aux lettres, un portail de soumission — lire le compte en octets et comparer des entiers plutôt que de juxtaposer deux valeurs arrondies dans deux conventions en espérant que cela tombe correctement.

Snow Leopard a fait passer le Finder au rapport décimal, de sorte qu’un disque vendu comme 500 Go affiche enfin 500 Go et que les fichiers sont devenus soudainement un peu plus gros. Le changement a supprimé une confusion et en a créé une autre : le même fichier se lit différemment sur un Mac et sur un PC, les deux écrans écrivant Mo.

Cela mérite d’être su quand une taille vous est communiquée par quelqu’un d’autre. « Il fait 26 Mo » venant d’un utilisateur Mac et « il fait 24,8 Mo » venant d’un utilisateur Windows peuvent être le même fichier, et la discordance n’est pas un problème de transfert, une différence de compression ni une copie corrompue. Si deux personnes sont en désaccord sur une taille d’environ cinq pour cent, l’unité est la première chose à vérifier.

L’arithmétique utile va dans l’autre sens de celui que la page annonce. Si le plafond est de 25 Mo décimaux, le plus gros fichier qui passe est de 23,84 Mio, ce que votre gestionnaire affichera comme 23,8 Mo. Pour un plafond de 10 Mo la cible est 9,5 sur votre écran ; pour 50 Mo elle est 47,7 ; pour 2 Mo elle est 1,9. La règle est de multiplier le plafond affiché par 0,954 et de prendre le résultat comme la valeur lue sur votre propre écran.

Une version plus ronde est plus facile à retenir et plus sûre : retirer cinq pour cent du plafond annoncé et viser en dessous. La marge perdue est négligeable — un demi-mébioctet sur un plafond de 25 Mo — et elle absorbe à la fois l’écart d’unité et ce que la procédure de téléversement ajoute autour du fichier. Un fichier qui passe avec de l’air passe du premier coup.

Le courrier électronique est le cas où l’écart d’unité est le moindre problème. Les pièces jointes sont encodées en base 64 pour survivre à un transport en texte, et le base 64 transforme chaque trio d’octets en quatre caractères — une augmentation de 33 % avant que les sauts de ligne soient comptés. Quand le plafond s’applique au message assemblé plutôt qu’au fichier, un plafond de 25 Mo accepte un fichier d’environ 18 Mo, et aucune conversion d’unité n’explique les sept manquants.

Les formulaires web se comportent autrement et mieux. Un téléversement par navigateur utilise le format multipart, qui transporte les octets tels quels avec quelques centaines d’octets d’en-têtes et de délimiteurs autour. Un plafond de 10 Mo sur un formulaire web concerne donc vraiment le fichier, et la seule correction nécessaire est le décimal contre le binaire. Savoir dans laquelle des deux situations on se trouve indique s’il faut retirer cinq pour cent ou un quart, et cette décision vaut la peine d’être prise avant le premier envoi plutôt qu’après le troisième refus. La distinction entre les deux protocoles est technique, et c’est précisément pour cela qu’elle est invisible à l’utilisateur qui ne la connaît pas.

Un écart d’un demi pour cent s’arrondirait silencieusement, et un écart de cinquante serait immédiatement visible. Celui-ci se loge dans la bande où il ne change rien à la perception d’un fichier et où il décide de tout quant il s’agit de franchir un seuil. Les photographies, les documents et les vidéos courtes se situent dans la zone où un plafond affiché et une taille lue diffèrent de moins d’un pas d’arrondi qu’on songerait à remettre en cause.

Il compose aussi en montant, ce qui explique pourquoi la même incompréhension coûte davantage à mesure que les nombres grandissent. Les unités binaires et décimales divergent de 2,43 % au kilo, de 4,86 au méga, de 7,37 au giga et de 9,95 au téra, parce que chaque pas multiplie l’écart par 1,024 à nouveau. Sur une pièce jointe cela coûte un fichier refusé ; sur une baie de stockage cela représente la meilleure part d’un disque.