Convertir MB a B

Un megabyte es un millón de bytes. Los fabricantes de almacenamiento siempre han contado en decimal, y por eso sus cifras parecen mayores que lo que muestra el ordenador.

Un byte son ocho bits, cosa que no siempre estuvo clara: los primeros ordenadores usaron seis, siete o nueve. Se impuso el ocho porque en él cabe un carácter y porque la cifra se parte en mitades limpias.

Pasar de megabytes a bytes desplaza la coma 6 lugares hacia la derecha y no cambia nada más. No hay factor que recordar ni redondeo que decidir: las cifras siguen en el mismo orden y solo cambia su posición.

1234 MB son 1234000000 B: las mismas cifras, corridas de sitio. Conviene saberlo porque es la única conversión que se comprueba de un vistazo — si las cifras del resultado no son las mismas con las que empezaste, lo que le ha pasado al número no ha sido esta conversión.

Los formatos de configuración que aceptan un tamaño casi siempre aceptan un entero de bytes, y el motivo es que todas las demás unidades de esta zona son ambiguas. Un byte es la misma cantidad en cualquier sistema y bajo cualquier convención; un megabyte son 1.000.000 para un organismo de normalización y para un ingeniero de redes, y 1.048.576 para muchísimo software. Un campo definido en bytes no se puede leer mal, que es exactamente por lo que está definido así.

Salir de megabytes decimales es multiplicar por un millón. 1 MB son 1000000, 10 MB son 10000000, 50 MB son 50000000 y 512 MB son 512000000. Todos ellos son números redondos en el sistema que usa esta página y todos son incómodos en unidades binarias, que es la primera pista sobre qué quiso decir alguien cuando te encuentras un 52428800 en un fichero.

El mismo campo que acepta 10000000 suele aceptar 10M, y el sufijo no es una abreviatura de las cifras. nginx lee k como 1.024 y m como 1.048.576, así que client_max_body_size 10m son 10.485.760 bytes. PHP hace lo mismo con upload_max_filesize, post_max_size y memory_limit, donde K, M y G son potencias de 1.024. Las herramientas GNU marcan la diferencia de forma explícita: M significa 1.048.576 y MB significa 1.000.000, y son sufijos separados.

El hueco es del 4,9 % a escala de megabyte, lo bastante pequeño para pasar una revisión y lo bastante grande para decidir un caso límite. Además es invisible en el fichero: 10M y 10000000 parecen la misma intención y se llevan 485.760 bytes. Donde el formato admita las dos formas, elige una convención para todo el fichero y dilo arriba del todo, para que quien toque el número después no tenga que volver a resolver la pregunta.

El valor que hay que escribir es el que va a parecer correcto en la herramienta que después informe sobre él. Si el panel, la línea de registro o el mensaje de error que mira el equipo muestran los tamaños en mebibytes, 10485760 aparece como un 10 MiB limpio y 10000000 aparece como 9,54, que tiene toda la pinta de una errata. Si la documentación de alrededor, el límite que se le cuenta al cliente y la página comercial dicen 10 MB, la cifra decimal es la que mantiene a las tres de acuerdo.

Lo que no funciona es elegir una distinta en cada sitio. Un montaje con el proxy en 10485760 y la aplicación en 10000000 tiene una ventana de 485.760 bytes en la que una petición pasa el primer control y falla el segundo, y lo que vuelve es el error de la aplicación en vez del rechazo limpio del borde. Que todo el camino sea coherente importa más que cuál de las dos cifras se escoja.

Una subida de fichero cruza normalmente al menos tres topes configurados: el límite de cuerpo de un proxy inverso o de un balanceador, el del servidor de aplicación o del entorno de ejecución, y el del marco de trabajo o del almacenamiento dentro de la propia aplicación. Cada uno se fija por separado, muchas veces por personas distintas en momentos distintos, y manda el más pequeño. Subir el que todo el mundo conoce y dejar los otros dos es el motivo más frecuente de que cambiar un límite no tenga ningún efecto visible.

Dónde salta el rechazo cambia la experiencia además del resultado. Un rechazo en el borde llega rápido y limpio, a menudo antes de que el cuerpo haya terminado de subir; un rechazo en la aplicación llega cuando el fichero entero ya ha viajado, lo que en una conexión lenta son minutos de espera para acabar en un fallo. Poner el límite del borde un poco por encima del de la aplicación hace que el error útil sea el que ve el usuario.

Un límite se aplica al cuerpo de la petición, y el cuerpo es mayor que el fichero. Los formularios multiparte envuelven cada parte en una línea de frontera y un juego de cabeceras, un coste fijo de unos cientos de bytes por campo que es despreciable con un fichero grande. Base64 no es despreciable: convierte cada tres bytes en cuatro caracteres imprimibles, así que un fichero metido dentro de un documento JSON crece alrededor de un 33 % y uno de 10 MB llega como unos 13,3 MB de cuerpo.

Un límite pensado para aceptar ficheros de 10 MB debe fijarse por tanto sobre el tamaño codificado y no sobre el del fichero. Para multiparte basta con unos cientos de kilobytes de margen. Para base64 dentro de JSON, multiplica por 4/3 y añade holgura: un límite de 14000000 acepta un fichero de 10 MB con comodidad, mientras que 10000000 rechaza cualquiera que pase de unos 7,5 MB y produce un informe de incidencia que dice que el límite está mal.

Un 52428800 suelto en un fichero de configuración es un número que nadie va a verificar, y uno equivocado es indistinguible de uno correcto a simple vista. Donde el formato admita una expresión, escribe 50 1024 1024 y deja que se vea de dónde sale. Donde solo se admita un literal, pon la cuenta en un comentario en la línea de encima: el tamaño previsto, el sistema en el que está y la herramienta con la que ese valor tiene que coincidir.

También conviene dejar escrito de dónde salió la cifra. Un límite que existe porque un contrato dice 50 MB es una cosa distinta de uno que existe porque lo dijo un perfil de memoria, y los dos se cambiarán por motivos distintos. Los valores de configuración sin origen declarado acaban subiéndose a la ligera o defendiéndose para siempre, y una sola frase en un comentario evita las dos cosas.

Cuando una petición se rechaza por tamaño, la mayoría de los sistemas informan del límite configurado y muchos informan también de lo que recibieron, los dos en bytes. Ese par de números es el diagnóstico más rápido disponible: identifica qué capa rechazó la petición, porque el límite citado coincidirá con exactamente uno de los valores del montaje, y confirma si el sufijo se interpretó como esperabas.

Un límite informado como 10485760 cuando en el fichero pone 10000000 significa que el sufijo se leyó en unidades binarias; un límite informado desde una capa que no sabías que estaba configurada significa que el techo no está donde creías. Las dos cosas se encuentran en una línea del registro de errores, y las dos son mucho más difíciles de deducir desde fuera subiendo ficheros cada vez más grandes hasta que algo se rompe.