Codificador y descodificador base32

¿Qué es base32?

Base32 representa bytes cualesquiera con 32 caracteres imprimibles, para que unos datos que no son texto puedan viajar por sitios que solo aceptan texto. Está definido en el RFC 4648, la misma especificación que define base64 y base16, y trabaja en grupos de cinco bytes: cuarenta bits repartidos en ocho grupos de cinco, y cada grupo se convierte en un carácter.

La pregunta obvia es por qué usarlo si existe base64 y ocupa menos. Base32 gasta ocho caracteres por cada cinco bytes frente a los cuatro por cada tres de base64: una proporción de 8/5 contra 4/3, lo que deja base32 exactamente en 6/5, es decir un 20 por ciento más grande. Ese 20 por ciento se paga por una sola propiedad: el alfabeto no distingue mayúsculas de minúsculas. Base64 necesita ambas cajas para llegar a 64 caracteres, así que cualquier cosa que unifique la caja lo destruye. Base32 usa solo 26 letras y seis dígitos, de modo que sobrevive a sistemas de ficheros que ignoran la caja, a etiquetas DNS, a nombres de host y a que alguien lo lea en voz alta o lo copie a mano.

Ese es todo el intercambio, y explica dónde aparece base32 de verdad: en registros de DNSSEC, en los enlaces magnet de las redes de intercambio y en los secretos compartidos que guardan las aplicaciones de doble factor, donde a veces una persona tiene que teclear la cosa.

Cómo usarlo

1. Elige Codificar o Descodificar y luego un alfabeto. El estándar es el que quieres salvo que sepas lo contrario. El hex extendido es el otro alfabeto que define el RFC 4648, y la sección de abajo explica cuándo es el correcto.
2. Pega tu texto o tu base32 en la caja. Al codificar verás los bytes de entrada, los caracteres de salida y la proporción de expansión. Al descodificar la herramienta es tolerante con los espacios y con las minúsculas, porque aquí ninguna de las dos cosas significa nada.
3. Copia el resultado. Al codificar puedes quitar el relleno final de signos igual, porque las especificaciones reales lo quitan. Y si pegas algo que no es una codificación canónica, la herramienta lo descodifica igualmente y te lo dice, en vez de fingir que la entrada estaba bien.

Dos alfabetos, y el que nadie implementa es el que se ordena

El RFC 4648 define base32 dos veces. La sección 6 da el alfabeto conocido: de la A a la Z y después los dígitos del 2 al 7. La sección 7 da un segundo alfabeto al que llama hex extendido: los dígitos del 0 al 9 y después de la A a la V. Casi todas las implementaciones ofrecen solo el primero, y el motivo de que exista el segundo es exacto, no decorativo.

El alfabeto hex extendido está en orden ASCII ascendente. Los valores van del 0 al 9 y luego de la A a la V, que es el orden en el que esos caracteres ya se ordenan, así que la cadena codificada se ordena exactamente igual que los bytes de debajo. El alfabeto estándar no está en orden ASCII: asigna el valor 0 a la letra A, que es 0x41, y el valor 26 al dígito 2, que es 0x32. Los últimos seis valores se ordenan por tanto antes que los primeros veintiséis, y el orden se rompe.

Eso es una afirmación que conviene medir en vez de dar por buena, así que las pruebas la miden. Sobre veinte mil pares generados de cadenas de bytes de igual longitud, el alfabeto hex extendido conserva el orden de todos y cada uno de los pares. El estándar lo conserva el 74 por ciento de las veces, que es como decir que normalmente parece funcionar y falla justo cuando lo necesitas.

La propiedad tiene un consumidor real, que es la mejor confirmación posible. Los registros NSEC3 de DNSSEC, especificados en el RFC 5155, guardan nombres de propietario ya troceados en base32 con el alfabeto hex extendido, y la especificación dice por qué con todas las letras: ese orden es el mismo que el orden canónico de nombres DNS cuando los nombres se codifican así. NSEC3 funciona demostrando que ningún nombre cae en el hueco entre dos vecinos, así que ahí el orden no es una comodidad, es el mecanismo. El RFC 5155 además prescinde del relleno por completo, y por eso esta herramienta te deja quitarlo.

El precio es visual, y es más sutil de lo que parece de entrada. El alfabeto estándar no evita simplemente los caracteres de aspecto ambiguo: conserva las letras O e I, que son precisamente las ambiguas. Lo que evita son los pares ambiguos, porque al no estar los dígitos 0 y 1 en el alfabeto, una O solo puede ser una letra y un 1 no puede aparecer nunca, de modo que no cabe la mala lectura. El hex extendido contiene 0, 1, O e I a la vez, y esa ambigüedad real es lo que paga por ordenarse.

El relleno, y tres longitudes que no pueden existir

Las reglas de relleno de base32 son más estrictas que las de base64 y se equivocan más a menudo. Como ocho caracteres llevan cinco bytes, un grupo final incompleto deja un cuerpo de 2, 4, 5 o 7 caracteres, rellenado hasta ocho con 6, 4, 3 o 1 signos igual respectivamente. Esos cuatro números no son un convenio, son aritmética, y un descodificador que acepte cualquier otra cantidad está aceptando algo que ningún codificador produjo.

La consecuencia más afilada es que hay tres longitudes imposibles. El cuerpo de un base32 nunca puede tener 1, 3 o 6 caracteres por encima de un múltiplo de ocho, porque no hay ningún número de bytes de entrada que los produzca. Compáralo con base64, donde solo una longitud de cada cuatro es imposible. Así que un base32 con la longitud equivocada no está meramente corto o truncado: es la prueba de que algo aguas arriba está roto, y esta herramienta lo dice en vez de adivinar qué se quiso decir.

El relleno en sí es opcional en la práctica. Los ejemplos del propio RFC lo incluyen, DNSSEC lo omite expresamente y los secretos de los autenticadores suelen escribirse sin él. Esta herramienta acepta la entrada de las dos maneras y te deja elegir al codificar, porque las dos son legítimas y una herramienta que insistiera en una sola se equivocaría con medio mundo.

Cuando los mismos bytes tienen varias grafías

La sección 3.5 del RFC 4648 se titula Codificación canónica y describe un problema que casi todas las herramientas ignoran. Cuando el grupo final está incompleto, el último carácter lleva unos cuantos bits de datos reales y unos cuantos bits sobrantes. La especificación dice que un codificador conforme debe poner esos bits sobrantes a cero, y advierte de que si no lo hace no existe una representación canónica y varias cadenas distintas descodifican a los mismos datos binarios.

El número de grafías lo fija la aritmética. Un cuerpo que acaba en 2 caracteres tiene 2 bits libres, así que cuatro cadenas distintas descodifican al mismo byte; un cuerpo de 4 caracteres tiene 4 bits libres y dieciséis grafías; uno de 5 tiene 1 bit libre y dos; uno de 7 tiene 3 bits libres y ocho. En concreto, la letra suelta f se codifica como MY, y MZ, M2 y M3 también descodifican a f.

La especificación solo dice que un descodificador puede rechazar esa entrada, y como es un puede, prácticamente nada lo hace. La biblioteca estándar de Python es un ejemplo razonable de implementación cuidadosa, y aceptó dos mil de dos mil cadenas mutadas a propósito, devolviendo los bytes originales en todas ellas sin decir nada. Eso es comportamiento conforme y es también la manera en que unos mismos datos acaban con varias representaciones dentro de sistemas que daban por hecho que tenían una.

Esta herramienta toma la tercera opción. Descodifica la entrada no canónica, porque negarse sería poco útil y te contaría menos, y a continuación te dice que la codificación no era canónica y te enseña lo que habría escrito un codificador conforme. Si estás comparando cadenas base32 por igualdad en alguna parte, como claves de caché, como identificadores o para descartar duplicados, esa diferencia es justo el fallo que estás buscando.

Límites honestos

Esto codifica y descodifica texto, no ficheros. La entrada se trata como texto y se convierte a bytes UTF-8 antes de codificar, y a la vuelta los bytes tienen que ser UTF-8 válido o la herramienta lo dice en vez de entregarte caracteres de sustitución. Esa última comprobación significa que no puedes usar esta página para hacer pasar binario cualquiera por la dirección de descodificado, y es deliberado: destrozar bytes en silencio es peor que rechazarlos.

Base32 es una codificación, no un cifrado. No oculta nada. Cualquiera que reconozca el juego de caracteres lo descodifica en segundos, y que una cadena parezca opaca no es protección de ningún tipo. Si lo que quieres es un texto que otros no puedan leer, lo que quieres es cifrado, que es otra página de este sitio.

Por último, los dos alfabetos de aquí son los dos que define el RFC 4648. Por ahí fuera existen otras variantes de base32, como la de Crockford, que elimina varias letras y funde otras, o z-base-32, que reordena el alfabeto pensando en las personas, y no son interoperables ni con estas ni entre sí. Si una cadena no descodifica aquí, la variante es lo primero que hay que mirar.

¿Por qué es gratis?

Porque no cuesta nada mantenerlo. La codificación y la descodificación ocurren en tu navegador según escribes; no se sube nada, no se registra nada y ningún servidor ve tu texto porque no hay ningún servidor de por medio.

Así que no hay cuenta, ni registro, ni nada guardado detrás de uno. Los alfabetos y las reglas de relleno salen del propio RFC 4648, los vectores de prueba de la batería son los que publica la especificación, y los resultados se contrastan con la biblioteca estándar de Python como implementación independiente.