Convertir KiB a B

Un kibibyte son exactamente 1.024 bytes. El nombre se introdujo en 1998 para que «kilobyte» pudiera volver a significar 1.000, aunque la costumbre nunca llegó a imponerse del todo.

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.

En este sentido la cuenta es una multiplicación, y por un número entero: un kibibyte son 1024 bytes, exactamente, y 1024 es la definición, no una medición que se quedó cerca.

Eso convierte esta en una de las pocas conversiones que merece la pena hacer de cabeza, y hace que el resultado se pueda comprobar: divide de vuelta y tienes que caer en el número de partida, exacto y sin resto que justificar.

Un KiB son 1.024 de la unidad de debajo; un kB, 1.000. En esta página eso es la diferencia entre 1024 B y 1000 B —un 2,4 %—, 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 2,4 %. Un disco vendido en kB 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 B donde la caja ponía 1024 B. 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.

La aritmética es lo de menos: se multiplica por 1.024 y el recuento de bytes sale exacto. Lo que convierte esta conversión en algo que merece explicarse es que la cifra de origen llega bajo media docena de nombres distintos. Las interfaces del núcleo de Linux imprimen kB y quieren decir kibibytes. Las herramientas invocadas con la opción -k informan en kibibytes y no lo dicen. La documentación escrita después de 1998 dice KiB y lo dice en serio. Las tres describen la misma unidad de 1.024 bytes.

Eso deja al lector con un paso de identificación antes de la multiplicación. La prueba fiable es la herramienta, no la etiqueta: cualquier cosa que informe de memoria o de uso de bloques en un sistema tipo Unix cuenta en unidades de 1.024 salvo que se le haya pedido explícitamente el sistema decimal. Cualquier cosa que cite un tamaño de archivo para una persona —una página de descarga, un límite de subida, una cifra de transferencia de red— es más probable que quiera decir mil.

El número de bloques que devuelve la metadata de un archivo se expresa en unidades de 512 bytes, y así ha sido desde que se definió la interfaz, sin importar en qué bloquee realmente el sistema de archivos por debajo. Un archivo que ocupa un bloque de 4.096 bytes informa entonces ocho bloques. El mismo archivo con du -k informa 4, porque esa herramienta cuenta en kibibytes. Ninguna de las dos cifras está mal, y ninguna se puede comparar con la otra sin saber a qué bloque se refiere cada una.

La regla práctica es convertir todo a bytes antes de comparar nada. Ocho bloques de 512 bytes y cuatro kibibytes son ambos 4.096 bytes, y esa coincidencia es invisible hasta que las dos se expresan así. Un script que compara un recuento de bloques con un total en kibibytes sin normalizar antes se equivoca por un factor de dos, y el error es lo bastante estable como para parecer una discrepancia real en vez de un fallo del script.

Dos preguntas distintas se esconden detrás de la palabra tamaño. La longitud de un archivo es el número de bytes que contiene; el espacio que ocupa es el número de bloques asignados multiplicado por el tamaño de bloque. Para un archivo de configuración de 100 bytes esas cifras son 100 bytes y 4.096 bytes, una diferencia de cuarenta veces, y cada una es la respuesta correcta a una pregunta distinta.

La diferencia funciona en las dos direcciones. Un archivo disperso —uno con regiones sin escribir que nunca llegaron a asignarse— informa una longitud mucho mayor que los bloques que realmente ocupa, y por eso una imagen de disco virtual puede listarse como 40 GiB y ocupar 3. Convertir un total de bloques en kibibytes a bytes dice cuánto está cargando el almacenamiento; convertir una longitud dice cuánto va a pesar una copia del archivo. Una estimación de copia de seguridad que use la equivocada se equivoca en lo que valga esa dispersión.

Los límites de recursos de la shell mezclan sus unidades y la mezcla no se nota en la salida. El límite de tamaño de pila y el de memoria virtual están en kibibytes, así que un límite de pila que marca 8192 son 8.388.608 bytes. El límite de tamaño de archivo está en bloques de 512 bytes por defecto en bash. Leer un conjunto de límites como si compartieran unidad produce un techo de memoria equivocado por un factor de dos en una dirección o en la otra.

La razón para convertirlos suele ser que algo más está expresado en bytes. Un proceso que falla por un error de memoria informa de la asignación que intentó en bytes; compararla con un límite dado en kibibytes cuesta una multiplicación y convierte una suposición en una respuesta. Si el límite resulta estar lejos de la asignación que falló, la causa está en otro sitio, y saberlo rápido vale más que la propia aritmética.

Por debajo de cierta granularidad, el recuento de bytes deja de ser el número útil. La memoria se reparte en páginas, y en la mayoría de los sistemas una página son 4.096 bytes. Los sistemas de archivos asignan en bloques, y el valor por defecto habitual es la misma cifra. Los discos con el formato de sector más reciente presentan sectores de 4.096 bytes. Las capas encajan porque todas eligieron la misma potencia de dos, y un tamaño múltiplo de ella pasa por todas sin desperdicio.

Esa coincidencia es la razón de que los tamaños de buffer, las entradas de caché y las longitudes de registro se agrupen en múltiplos de 4.096. Una lectura de 4.000 bytes toca la misma página que una de 4.096 y cuesta lo mismo; un registro de 4.100 bytes abarca dos bloques y cuesta el doble de escrituras de las que aparenta necesitar. Convertir una cifra en kibibytes a bytes suele ser el primer paso para comprobar si un tamaño cae justo en ese límite o un poco más allá.

A esta escala, la diferencia entre un kilobyte y un kibibyte son 24 bytes, y para la mayoría de los usos se pierde en el redondeo. Un peso de página anunciado como 500 kB no es significativamente distinto de 500 KiB, y discutir la distinción sobre un solo archivo es tiempo mal empleado.

Se vuelve importante en cuanto se multiplica. Un millón de registros de 4 KiB cada uno son 4.096.000.000 bytes, no 4.000.000.000, y un plan de capacidad construido sobre la segunda cifra se queda 96 MB corto antes de que ocurra nada inesperado. Lo mismo se aplica a la contabilidad por petición, al cálculo de cuotas y a cualquier otro caso donde una unidad pequeña se cuenta muchas veces: la brecha no crece, pero el recuento por el que se multiplica sí.

No todo k son 1.024, y suponer lo contrario es su propio error. El tráfico de red, las franquicias de transferencia, las capacidades de almacenamiento y cualquier cosa impresa en un embalaje son decimales, así que un kilobyte en esos contextos son 1.000 bytes, y multiplicar por 1.024 sobrestima el resultado en un 2,4%. El mismo lector que ha aprendido a desconfiar de una k en la salida de una terminal tiene que recordar confiar en ella en una factura.

La regla que cubre ambos casos sin pensar demasiado: si el número describe lo que hace una máquina por dentro, es binario; si describe lo que se vende, se transfiere o se anuncia, es decimal. La distinción no es perfecta, pero las excepciones se anuncian solas —una herramienta que quiere decir 1.000 suele llevar una opción que lo indica, y una que quiere decir 1.024 suele tener documentación que lo reconoce.

Los recuentos de bytes se mantienen exactos en cualquier tipo entero suficientemente ancho, y una cifra en kibibytes multiplicada por 1.024 se mantiene exacta también. El problema empieza cuando un valor ya se redondeó para mostrarlo: una herramienta que imprime 1,4 KiB ha descartado el recuento de bytes original, y multiplicar la cifra redondeada hacia atrás da algo entre 1.382 y 1.485. Recuperar el original no es posible, así que conviene tomar el recuento de bytes de la fuente y no del resumen siempre que existan ambos.

La mayoría de las herramientas producen bytes en bruto si se les pide, y esa salida es la que hay que alimentar a cualquier proceso automatizado. El formato legible para humanos es una decisión de presentación tomada en el último momento, y tratarlo como si fuera un dato es cómo un pipeline de monitorización acaba con tamaños que se desvían unos puntos porcentuales sin que nadie encuentre después la razón.