Convertir des Mo en o

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 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 mégaoctets aux octets déplace la virgule de 6 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 MB font 1234000000 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.

Les formats de configuration qui acceptent une taille prennent presque toujours un entier d’octets, et la raison est que toute autre unité dans ce domaine est ambiguë. Un octet est la même quantité dans tous les systèmes et sous toutes les conventions ; un mégaoctet fait 1 000 000 pour un organisme de normalisation et un ingénieur réseau et 1 048 576 pour une bonne part du logiciel. Un champ défini en octets ne peut pas être mal lu, et c’est précisément pourquoi il est défini ainsi.

La conversion hors des mégaoctets décimaux est une multiplication par un million. 1 Mo fait 1 000 000, 10 Mo fait 10 000 000, 50 Mo fait 50 000 000 et 512 Mo fait 512 000 000. Chacun de ceux-là est un nombre rond dans le système de cette page, et chacun d’eux est un nombre malcommode en unités binaires, ce qui est le premier indice de ce que quelqu’un voulait dire quand on trouve 52 428 800 dans un fichier.

Le même champ qui accepte 10 000 000 acceptera souvent 10M, et le suffixe n’est pas un raccourci pour les chiffres. nginx lit k comme 1 024 et m comme 1 048 576, de sorte que client_max_body_size 10m fait 10 485 760 octets. PHP fait la même chose pour upload_max_filesize, post_max_size et memory_limit, où K, M et G sont tous des puissances de 1 024. Les outils GNU font la distinction explicitement : M signifie 1 048 576 et MB signifie 1 000 000, et ce sont deux suffixes distincts.

L’écart est de 4,9 % à l’échelle du mégaoctet, ce qui est assez petit pour survivre à une revue et assez grand pour importer à une frontière. Il est aussi invisible dans le fichier : 10M et 10 000 000 ont l’air de la même intention et sont distants de 485 760 octets. Là où une configuration accepte les deux formes, choisissez une convention pour tout le fichier et dites-le en haut, pour que la personne suivante qui modifiera le chiffre n’ait pas à refaire la question.

La valeur à écrire est celle qui aura l’air juste dans l’outil qui en rendra compte. Si le tableau de bord, la ligne de log ou le message d’erreur que l’équipe regarde affiche les tailles en mébioctets, alors 10 485 760 apparaît comme 10 Mio propre et 10 000 000 apparaît comme 9,54, un chiffre qui a l’air d’une erreur. Si la documentation, la limite visible du client et la page marketing disent toutes 10 Mo, c’est le chiffre décimal qui maintient l’accord.

Ce qui ne marche pas est de choisir l’un à chaque endroit indépendamment. Une pile où le proxy est à 10 485 760 et l’application à 10 000 000 a une fenêtre de 485 760 octets dans laquelle une requête passe le premier contrôle et échoue au second, et l’erreur qui revient sera celle de l’application plutôt que le rejet net à la périphérie. La cohérence sur tout le chemin compte plus que lequel des deux nombres est choisi.

Un téléversement de fichier traverse en général au moins trois plafonds configurés : une limite de corps du reverse-proxy ou du répartiteur de charge, une limite du moteur d’application ou du runtime, et souvent une limite côté framework ou stockage dans l’application. Chacune est réglée séparément, souvent par des personnes différentes à des moments différents, et la plus petite décide de ce qui se passe réellement. Augmenter la valeur que tout le monde connaît et laisser les deux autres est la raison la plus fréquente pour laquelle un changement de limite n’a aucun effet visible.

Là où ils se déclenchent change l’expérience autant que le résultat. Un rejet en périphérie arrive rapidement et proprement, souvent avant que le corps ait fini d’être transmis ; un rejet au niveau de l’application arrive après que le fichier entier a été transféré, ce qui sur une connexion lente représente des minutes d’attente pour un échec. Régler la limite de périphérie un peu au-dessus de la limite d’application signifie que l’erreur utile est celle que les utilisateurs verront.

Une limite s’applique au corps de la requête, et le corps de la requête est plus grand que le fichier. Les données de formulaire en multipart enveloppent chaque partie dans une ligne de séparation et un jeu d’en-têtes, ce qui coûte quelques centaines d’octets par champ et reste négligeable pour un gros fichier. Le base64 n’est pas négligeable : il transforme chaque trio d’octets en quatre caractères imprimables, de sorte qu’un fichier transporté dans un document JSON grandit d’environ 33 %, et qu’un fichier de 10 Mo arrive en corps d’environ 13,4 Mo.

Donc une limite destinée à accepter des fichiers de 10 Mo doit être réglée à partir de la taille encodée plutôt qu’à partir de la taille du fichier. Pour du multipart, quelques centaines de kilooctets de marge suffisent. Pour du base64 dans du JSON, multipliez par 4/3 et ajoutez une marge : une limite à 14 000 000 accepte confortablement un fichier de 10 Mo, alors que 10 000 000 rejette tout ce qui dépasse environ 7,5 Mo et produit un rapport de bug qui dit que la limite est fausse.

Un 52 428 800 nu dans un fichier de configuration est un chiffre que personne ne vérifiera, et un chiffre erroné est indiscernable d’un bon à l’œil. Là où le format permet une expression, écrivez 50 1024 1024 et laissez le lecteur voir la dérivation. Là où seul un littéral est permis, mettez le calcul en commentaire sur la ligne au-dessus : la taille visée, le système où elle est, et l’outil avec lequel la valeur doit s’accorder.

Cela vaut aussi la peine d’enregistrer d’où vient le chiffre. Une limite qui existe parce qu’un contrat client dit 50 Mo est une chose différente d’une qui existe parce qu’un profil de mémoire le disait, et les deux seront changées pour des raisons différentes. Les valeurs de configuration sans origine énoncée finissent en général haussées sans précaution ou défendues à jamais, et une seule phrase en commentaire empêche les deux.

Quand une requête est refusée pour cause de taille, la plupart des systèmes rapportent la limite configurée et beaucoup rapportent la taille reçue, les deux en octets. Cette paire de chiffres est le diagnostic le plus rapide disponible : elle identifie quel niveau a rejeté la requête, parce que la limite citée correspond exactement à une des valeurs de la pile, et elle confirme si un suffixe court a été interprété comme vous l’attendiez.

Une limite rapportée à 10 485 760 quand le fichier dit 10 000 000 signifie que le suffixe a été lu en unités binaires ; une limite rapportée depuis un niveau que vous ne saviez pas configuré signifie que le plafond n’est pas là où vous le pensiez. Les deux se trouvent en une ligne d’un journal d’erreurs, et les deux sont bien plus dures à reconstituer depuis l’extérieur en téléchargeant des fichiers progressivement plus gros jusqu’à ce que quelque chose casse.