Convertir kB a MiB

Un kilobyte son 1.000 bytes cuando lo define un organismo de normalización y 1.024 cuando lo define un sistema operativo. Esta página calcula con 1.000; la unidad de 1.024 se llama kibibyte.

Un mebibyte son 1.024 kibibytes, es decir 1.048.576 bytes. Las herramientas de Linux y las cifras de memoria se refieren casi siempre a esto, aunque escriban «MB».

El factor es 0,000954, y casi nadie lo lleva encima. Redondeado a 0,00095 se desvía un 0,39 %, que pasa desapercibido en cifras pequeñas y se convierte en una unidad entera alrededor de 1000 kB.

Ese es el dato que interesa antes de redondear: no el error en sí, sino a partir de dónde deja de ser despreciable. Por debajo de ahí el factor corto es el sensato; por encima, usa el campo de arriba, que no redondea hasta el momento de escribir el resultado.

Un MiB son 1.024 de la unidad de debajo; un MB, 1.000. En esta página eso es la diferencia entre 1048,576 kB y 1000 kB —un 4,9 %—, y la distancia crece en cada escalón: por eso es un redondeo despreciable en una foto y un trozo visible de un disco duro.

En eso consiste entero el misterio del espacio que falta, y en esta página vale un 4,9 %. Un disco vendido en MB tiene exactamente lo que dice la etiqueta; lo que pasa después es que Windows divide entre 1.024 en vez de entre 1.000, conserva el nombre decimal y muestra 1000 kB donde la caja ponía 1048,576 kB. macOS cuenta estas cifras en unidades decimales desde 10.6, y por eso el mismo disco puede parecer de dos tamaños en dos ordenadores: no falta nada ni redondea nadie, son los mismos bytes con dos nombres.

Un proyecto web sostiene las dos convenciones a la vez, casi siempre sin decirlo. El panel de red del navegador informa del tamaño transferido en kilobytes de 1.000 bytes, las guías de rendimiento se escriben igual, y la factura del proveedor de hosting cuenta en gigabytes decimales porque así se ha vendido siempre el ancho de banda. Mientras tanto, la caché del servidor, la cuota de almacenamiento y el propio sistema de archivos por debajo cuentan casi siempre en potencias de 1.024.

La conversión entre los dos cruza a la vez un peldaño de prefijo y la frontera entre decimal y binario, así que divide por 1.048,576 y no por mil. En un paquete de 3.000 kB eso es la diferencia entre 3,00 y 2,86, y la cifra menor es la correcta. Comprobar un límite binario con el atajo decimal siempre da más margen del que existe de verdad, que es justo la dirección equivocada para un control de este tipo.

Algunas cifras de referencia: 500 kB son 0,4768 MiB, 1.000 kB son 0,9537, 2.000 kB son 1,9073 y 5.000 kB son 4,7684. Una página que el panel de red totaliza en 2.090 kB no ha superado un límite de 2 MiB, porque 2 MiB son 2.097,152 kB —pero está a solo siete kilobytes de hacerlo, y una lectura decimal contra un límite de 2 MB la habría dado por excedida noventa kilobytes antes.

El error corre al revés cuando el límite está en binario y se lee como decimal. Una caché configurada a 50 MiB admite 52.428,8 kB de contenido, no 50.000, y un cálculo de capacidad hecho sobre la cifra redonda deja casi dos megabytes y medio de caché sin usar. Ningún error es grande y los dos son sistemáticos, lo que significa que se acumulan en la misma dirección cada vez que se repite el cálculo.

Antes de discutir el 4,9%, conviene aclarar qué tamaño se está midiendo. Un paquete de texto suele comprimirse a un tercio de su longitud sin comprimir, o menos, así que el mismo archivo puede describirse honestamente como 900 kB o como 260 kB según se hable de lo que produjo la compilación o de lo que cruzó la red. Eso es un factor de tres, frente a una cuestión de unidades que apenas vale un cinco por ciento.

Los presupuestos de rendimiento deberían por tanto nombrar el estado además de la unidad: transferido, comprimido o en bruto sobre disco. Las herramientas de compilación suelen informar del tamaño sin comprimir porque es lo único que tienen, y el panel del navegador informa de lo transferido porque es lo que ha observado. Un límite que no diga cuál de los dos gobierna acabará aplicándose contra lo que la herramienta tenga a mano, y los dos no son comparables.

Varios empaquetadores aceptan límites de tamaño de recurso como un número de bytes plano, y usar esa forma elimina la necesidad de acordar ningún prefijo. Un límite de 250.000 bytes es inequívoco, se busca con facilidad en el código y se compara directamente con los bytes que la misma herramienta ya informa. Un límite escrito como 250 kB lleva la misma intención con una nota a pie de página, y esa nota es justo lo que se pierde cuando la configuración se copia a otro proyecto.

Donde la herramienta insista en un prefijo, conviene elegir el binario y escribirlo explícitamente. Un límite de caché de 50m en la configuración de un proxy son 52.428.800 bytes, lo crea el lector o no, y anotar MiB al lado del número cuesta una línea de comentario. La alternativa es un límite que todos dan por 50 millones de bytes exactos y que en realidad es casi dos millones y medio mayor.

Los presupuestos de rendimiento existen para detectar un crecimiento pequeño y constante, y el tamaño del desvío que buscan suele coincidir con el tamaño de este error de unidades. Un paquete que crece un 4% en cada versión es justo lo que un presupuesto debería señalar, y es justo la cantidad que un desajuste entre decimal y binario puede absorber antes de que nadie lo note. Una sola versión de margen invisible basta para esconder un trimestre entero de crecimiento.

La solución es que la cifra publicada y el límite salgan de la misma fuente. Si la herramienta de compilación mide en bytes, el presupuesto se fija en bytes; si el monitor mide kilobytes transferidos, el presupuesto se fija en kilobytes transferidos. Cada conversión entre el informe y el umbral es un sitio donde un desplazamiento sistemático puede instalarse y quedarse.

El almacenamiento del lado del cliente —cachés, bases de datos, estado persistido— se mide contra una cuota que el navegador calcula a partir del disco disponible, y las cifras que devuelve son exactas, no con prefijo. Consultar la estimación de almacenamiento da el uso y la cuota en bytes, que es la forma correcta de comparar, y convertir el resultado a mebibytes para mostrarlo es una decisión de presentación tomada después.

La razón para conservar los bytes en bruto es que las cuotas cambian: dependen del espacio libre en disco, de la clase de almacenamiento del origen y de la política del navegador, así que un valor que fue 500 MiB la semana pasada puede no serlo esta. El código que guarda el recuento en bytes y lo vuelve a comprobar se comporta bien ante esos cambios; el que fija en el código una cifra ya convertida a una unidad más cómoda, no.

Divide entre mil y quita un cinco por ciento. Un total de 4.400 kB se convierte en 4,4 y después en unos 4,18 MiB, frente a los 4,19617 reales: suficientemente cerca para saber al instante si se ha cruzado un límite de 4 MiB. Hasta unos pocos megabytes, la estimación se queda a un par de kilobytes de la cifra real.

En el sentido contrario, multiplica por mil y añade un cinco por ciento: un límite de 10 MiB son unos 10.500 kB, frente a 10.485,76 exactos. Los dos atajos no son simétricos, porque uno resta 4,86% y el otro lo vuelve a sumar sobre una base menor, pero a esta escala la diferencia entre ambas correcciones es de unos pocos kilobytes, bien dentro del margen de cualquier medición real.