Conversor Binario

1. Pesos posicionales y conversión entre base 2, 10 y 16

El binario es un sistema posicional en base 2: dentro de un byte cada bit vale una potencia de dos, con pesos 128, 64, 32, 16, 8, 4, 2 y 1 de izquierda a derecha. Por eso 01000001 se lee como 64 + 1 = 65 decimal, que en la tabla ASCII es la letra "A" y en hexadecimal se escribe 0x41. Pasar a hexadecimal es mecánico porque cada grupo de 4 bits (nibble) equivale a un dígito hex: 0100 es 4 y 0001 es 1. Un byte cubre 256 valores (0-255) y exactamente dos dígitos hex, motivo por el cual los volcados de memoria, los colores CSS (#FF8800) y las direcciones MAC se escriben en hexadecimal y no en binario.

2. Enteros con signo y complemento a dos

Los enteros con signo se almacenan en complemento a dos: el bit más significativo pasa a tener peso negativo -2^(N-1). En un entero de 8 bits, 11111111 no es 255 sino -1, y el rango va de -128 a 127. Para negar un valor se invierten todos los bits y se suma 1: 00000101 (5) se convierte en 11111010 + 1 = 11111011 (-5). El esquema elimina el cero negativo duplicado y permite que la ALU reste con el mismo circuito sumador. También explica el desbordamiento clásico: sumar 1 a 01111111 (127) da 10000000, que se relee como -128. El byte 0xFF significa 255 sin signo y -1 con signo; solo el tipo declarado decide.

3. ASCII de 7 bits frente a UTF-8 de longitud variable

ASCII define apenas 128 puntos de código en 7 bits, así que todo lo demás depende de UTF-8, una codificación de longitud variable que anuncia su tamaño en los bits iniciales: 0xxxxxxx para un byte, 110xxxxx 10xxxxxx para dos, 1110xxxx para tres y 11110xxx para cuatro. La "é" (U+00E9) se codifica como 11000011 10101001 (0xC3 0xA9), el ideograma 中 (U+4E2D) ocupa tres bytes y un emoji como 😀 (U+1F600) ocupa cuatro. No conviene confundir caracteres con bytes: en JavaScript "😀".length devuelve 2 porque las cadenas son UTF-16 y el emoji se guarda como par suplente, mientras que su forma binaria UTF-8 tiene 32 bits.

¿Por qué mi cadena binaria no se decodifica a texto?

Casi siempre porque la cantidad de dígitos no es múltiplo de 8. Si copiaste grupos de 7 bits de ASCII puro o se perdió un cero inicial, todos los bytes siguientes quedan desalineados. Revisá también caracteres colados que no sean 0 ni 1 y, si el texto tenía acentos o emojis, que estén completos los 2 a 4 bytes UTF-8 de cada carácter.

¿Por qué los acentos salen como "é" al pasar de binario a texto?

Es mojibake: los dos bytes UTF-8 de la "é" (0xC3 0xA9) se están leyendo como dos caracteres Latin-1 sueltos, Ã y ©. El binario está bien; lo que falla es la codificación declarada del lado que decodifica. Forzá UTF-8 en el destino, por ejemplo con <meta charset="utf-8"> o con charset=utf-8 en la cabecera Content-Type.

¿El orden de bytes (endianness) afecta la conversión de texto a binario?

En UTF-8 no: su secuencia de bytes está fijada por la norma y se lee igual en x86, ARM o cualquier arquitectura, por eso no necesita BOM. Sí importa en UTF-16 y UTF-32, donde FE FF o FF FE marca el orden, y en enteros de varios bytes: 0x41424344 se guarda como 44 43 42 41 en little-endian (x86) y como 41 42 43 44 en el big-endian del orden de red.