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.

De binario a decimal, y de decimal a binario

Binario y decimal son aquí el único par que no comparte nada: dos no es potencia de diez y diez no es potencia de dos, así que ninguno de los dos sentidos es una consulta y ambos exigen aritmética de verdad. Tampoco es la misma aritmética, y esa es la parte que casi nunca se dice en voz alta: el método rápido a mano en un sentido no es el inverso del método rápido a mano en el otro.

• De binario a decimal, duplicando: empieza en el bit más a la izquierda con cero y, por cada bit, duplica lo que llevas y suma ese bit. Para 1011 eso da 1, 2, 5, 11 — una sola pasada, sin valores de posición que recordar, y es exactamente lo que hace esta herramienta al leer lo que escribes.
• De binario a decimal, por posiciones: suma el valor de posición de cada bit activo, que es el ejemplo desarrollado más arriba. Más rápido cuando solo hay dos o tres bits activos, y más lento cuando lo están casi todos.
• De decimal a binario, dividiendo: divide entre dos y anota el resto, una y otra vez, hasta que no quede nada; luego lee los restos de abajo arriba. La respuesta llega con el bit menos significativo primero, y por eso parece del revés todo el rato mientras la escribes.
• De decimal a binario, restando: quita la mayor potencia de dos que quepa y repite. 200 pierde 128 y quedan 72; 72 pierde 64 y quedan 8; 8 pierde 8 y no queda nada — así que están activos los bits de las posiciones 7, 6 y 3 y el byte es 1100 1000. Más rápido que dividir siempre que haya pocos bits activos.

Hay algo que ningún método a mano cubre aquí: un número decimal negativo no tiene forma binaria alguna hasta que se elige un ancho. Pregunta por menos cinco en binario y la respuesta honesta es otra pregunta: ¿cuántos bits? Eso es lo que resuelve el selector de ancho, y de eso trata la sección sobre el complemento a dos de más arriba. En el modo de precisión arbitraria no hay ancho, así que el signo menos sencillamente acompaña al número a cualquier base.

De decimal a hexadecimal, y de hexadecimal a decimal

Casi nadie que haga esto a menudo divide entre dieciséis. El atajo es la relación del hexadecimal con el binario: convierte el número decimal a binario una vez, corta los bits en grupos de cuatro desde la derecha y lee cada grupo como un solo dígito hex. La vuelta es el mismo camino al revés: expande cada dígito hex en sus cuatro bits y suma el valor de posición de los que estén activos. Para cualquier cosa que quepa en un byte hay un camino aún más corto: el primer dígito hex vale dieciséis veces el segundo, así que multiplica y suma.

• 255 es ff — un byte con todos los bits activos. Es el que conviene saber de memoria, porque ahí se acaba el byte.
• 256 es 100. Un paso más allá de un byte lleno los dígitos pasan de largo, igual que 99 pasa a 100 en decimal, y el número hex gana un dígito que el byte no puede sostener.
• 65535 es ffff y 65536 es 10000: las mismas dos referencias un byte más arriba, donde se acaba un contador de dieciséis bits.
• 4096 es 1000, y por eso los tamaños de página, las alineaciones y los desplazamientos de memoria parecen redondos en hex y dentados en decimal. El hex cuenta de cuatro en cuatro bits, y el hardware también.

Las mayúsculas y minúsculas no cuentan: FF y ff son el mismo valor, la herramienta acepta ambas formas al entrar y escribe minúsculas al salir. Lo que no hará es adivinar. El prefijo 0x pertenece al campo hexadecimal y en el decimal se rechaza en vez de descartarse en silencio, porque un valor leído en la base equivocada es el único error que un conversor jamás debe hacer parecer plausible.

De octal a decimal, y el cero inicial que cambia la respuesta

El octal sobrevive en un sitio más que en ningún otro: los permisos de archivo, donde tres bits de permiso por grupo de usuarios caben exactamente en un dígito octal. Convertirlo a decimal es aritmética posicional sencilla con potencias de ocho — 755 en octal es siete sesenta y cuatros más cinco ochos más cinco, es decir 493 — y el sentido contrario es dividir entre ocho leyendo los restos de abajo arriba, la misma forma que de decimal a binario y por la misma razón: el ocho tampoco guarda relación con el diez.

• 755 es 493 en decimal, 644 es 420 y 777 es 511. Ninguno de esos números decimales le sirve a nadie, y ese es justo el punto: los permisos se escriben en octal porque los dígitos coinciden con los bits de permiso, no porque el valor cuente nada.
• Un cero inicial es una marca de base en C y en Python 2: allí 0755 es octal y por tanto el número 493. Python 3 rechaza esa escritura de plano y pide 0o755 en su lugar, con lo que eliminó toda una familia de errores silenciosos.
• YAML 1.1 también lee un 0755 sin comillas como 493, y por eso un modo de permisos en un archivo de configuración hay que entrecomillarlo o deja de ser el modo que escribiste.
• JSON no lo permitió nunca: su gramática prohíbe el cero inicial en un número, así que allí 0755 ni siquiera es un número, sino un error de análisis — el más ruidoso de los tres comportamientos y el único que no se puede leer mal.

Esta herramienta no ve en un cero inicial la marca de nada. La base la fija el campo en el que escribes: 0755 es 755 en el campo decimal y 493 en el octal, y el prefijo 0o se acepta en el campo octal y se rechaza en todos los demás. Adivinar la base a partir de un prefijo significaría devolver un número distinto del que se escribió.

De octal a hexadecimal: el par sin atajo

Ambos son potencias de dos, así que ambos son pura reagrupación de los mismos bits — y aun así este es el único par de las cuatro bases sin ninguna regla de dígito a dígito. Un dígito octal son tres bits y uno hexadecimal cuatro, y ninguno de los dos números divide al otro, de modo que los límites nunca coinciden. No hay forma de saltarse el escribir los bits y reagruparlos.

• Escribe cada dígito octal como sus tres bits, en orden: 755 se convierte en 111 101 101.
• Reagrupa esos bits de cuatro en cuatro desde el extremo derecho, rellenando por la izquierda con ceros cuando la cuenta no salga justa: 0001 1110 1101.
• Lee cada grupo de cuatro como un dígito hex: 1ed. Rellenar por el extremo equivocado es aquí el error clásico, y no parece un error: sencillamente multiplica la respuesta en silencio.

Que dos dígitos hex sean exactamente un byte y dos dígitos octales no lo sean es toda la razón por la que el hex desplazó al octal para leer memoria: ocho bits son dos dígitos octales y dos tercios, así que el límite del byte cae en mitad de un dígito. El octal encajaba con máquinas cuyo tamaño de palabra era múltiplo de tres bits; el hex encaja con el byte de ocho bits. Y en esta página la rejilla de bits es más rápida que cualquiera de los dos métodos a mano para este par: activa los bits una vez y los dos campos ya están mostrando la respuesta.