Conversor de bases numéricas

Qué hace esta herramienta

El mismo número puede escribirse en muchas bases, y los programadores se mueven entre cuatro de ellas constantemente: binario porque es lo que guarda el hardware, hexadecimal porque es una abreviatura legible del binario, decimal porque así piensan las personas, y octal porque los permisos de archivo y algunos sistemas antiguos aún lo usan. Escribe un valor en cualquiera de los campos y el resto lo siguen, junto con otro campo que puedes fijar en cualquier base de 2 a 36.

Lo que lo separa de una calculadora escolar es el selector de ancho y la rejilla de bits. Elige 8, 16, 32 o 64 bits y los números negativos adoptan su representación real en la máquina en lugar de un signo menos, y cada bit se convierte en algo que puedes pulsar.

Qué es realmente una base

Una base es cuántos dígitos tienes antes de agotarlos y tener que llevar una. El decimal tiene diez, así que tras el 9 viene el 10. El binario tiene dos, así que tras el 1 viene el 10. La posición de cada dígito es una potencia de la base, y eso es todo:

1011           # el número, en base 2
1 x 8 = 8      # bit 3
0 x 4 = 0      # bit 2
1 x 2 = 2      # bit 1
1 x 1 = 1      # bit 0
8+0+2+1 = 11   # el total, en decimal

Las bases por encima de diez necesitan más de diez símbolos, así que toman prestadas letras: el hexadecimal va de 0-9 y luego a-f, donde a es 10 y f es 15. Eso continúa hasta la base 36, que usa todos los dígitos y todas las letras — la mayor base que puede escribirse con el alfabeto llano, y la razón por la que esta herramienta se detiene ahí.

Por qué hexadecimal y no otra cosa

El hexadecimal es popular por una razón concreta: 16 es 2 elevado a 4, así que exactamente un dígito hex cubre exactamente cuatro bits. Eso convierte la conversión entre hex y binario en una consulta sin aritmética: cada dígito hex se expande a sus propios cuatro bits, con independencia de los dígitos que lo rodean.

d    e    a    d
1101 1110 1010 1101   # cada dígito hex es su propio nibble

El octal funciona igual con tres bits por dígito, ya que 8 es 2 elevado a 3 — y por eso los permisos de Unix son octales: tres bits de permiso por grupo de usuarios caben exactamente en un dígito. El decimal no guarda esa relación con el binario, y por eso convertir entre ellos exige una división real en vez de una consulta.

Es también la razón de que aquí el campo binario se agrupe de cuatro en cuatro y el hex de dos en dos: los grupos coinciden con los límites que importan, así que puedes leer un nibble o un byte en pantalla sin contar.

Números negativos y complemento a dos

Un número negativo no tiene forma binaria por sí mismo. No hay signo menos en un registro —solo bits—, así que el signo tiene que codificarse en los propios bits, y eso obliga a decidir cuántos bits hay. Por eso existe el selector de ancho, y por eso la respuesta cambia al cambiarlo.

El esquema que usa toda máquina moderna es el complemento a dos: para representar un número negativo, se toma su forma positiva, se invierte cada bit y se suma uno. El resultado es que el bit superior acaba significando «negativo», y la suma corriente sigue funcionando sin ningún caso especial para los signos.

0000 0101   # 5
1111 1010   # cada bit invertido
1111 1011   # más uno: -5 como byte, o fb en hex

Ensancha el registro y el mismo número obtiene otro patrón: -5 es fb en 8 bits, fffb en 16 y fffffffb en 32. El valor no ha cambiado; sí el número de bits que lo llevan. Cambiar el ancho en esta herramienta muestra exactamente eso.

Por qué 0xFF es a la vez 255 y -1

Los bits ff no dicen si son con signo. Un byte que contiene 1111 1111 se lee como 255 si el código que lo carga declaró un tipo sin signo, y como -1 si declaró uno con signo. Nada en el byte distingue ambos casos: el tipo es una afirmación que hace el programa sobre unos bits que no llevan esa información.

De ahí sale toda una familia de errores reales: una suma de verificación que sale negativa, un byte leído de un archivo que compara como menor que cero, un char de C que se comporta distinto en ARM que en x86 porque su signo lo define la implementación. Siempre que las lecturas con y sin signo difieren, esta herramienta muestra ambas, porque la discrepancia suele ser justo lo que buscabas.

La rejilla de bits

Cada bit del valor actual se muestra con su número de posición, y al pulsarlo se invierte. Las bases se actualizan al instante, lo que hace mucho más fáciles algunas preguntas que a mano:

• Qué bit está activo en este valor de banderas: púlsalos y lee las posiciones.
• Cuál es la máscara para los bits 4 y 7: activa esos dos y lee el hex.
• Qué le hace al valor con signo activar el bit superior: lo vuelve negativo, a la vista.
• Si este valor es potencia de dos: una potencia de dos tiene exactamente un bit activo.

El bit 0 es el menos significativo y va a la derecha, que es la convención universal y la razón de que la rejilla se mantenga de izquierda a derecha incluso en una página que se lee al revés. Las filas son de ocho bits para que los límites de byte se vean de un vistazo.

Los números grandes se mantienen exactos

Los números de JavaScript son dobles, que solo guardan enteros exactos hasta 2^53 — unos 9 billardos. Un valor de 64 bits puede superarlo, y un conversor construido sobre números corrientes lo redondeará en silencio, dando una cadena hex que parece plausible y es incorrecta en sus últimos dígitos.

Aquí todo usa enteros de precisión arbitraria, así que un valor de 64 bits completo se convierte exactamente. El modo de precisión arbitraria va más allá y elimina el límite del todo —útil para valores criptográficos e identificadores grandes—, pero ten en cuenta que sin un ancho fijo no hay complemento a dos, de modo que un número negativo en ese modo lleva simplemente un signo menos en cada base.