Codificador y decodificador Base32

Base32 convierte texto UTF-8 arbitrario en una cadena compacta formada únicamente por las letras de la A a la Z y los dígitos del dos al siete, con relleno opcional de signos de igual para que cada bloque ocupe un límite de ocho caracteres. A diferencia de Base64, el alfabeto evita el signo más, la barra y otros signos de puntuación que rompen las URL, los argumentos de línea de comandos o los sistemas de archivos insensibles a mayúsculas, por lo que las semillas secretas, las claves TOTP y muchos tokens de protocolo siguen distribuyéndose en Base32. Esta capacidad implementa de extremo a extremo el alfabeto de la sección seis del RFC 4648: el modo de codificación lee su cadena como bytes UTF-8 y emite un resultado Base32 con relleno; el modo de decodificación acepta Base32 en mayúsculas y minúsculas, elimina los espacios en blanco, valida cada carácter y devuelve el texto UTF-8 original.

Cómo el Base32 del RFC 4648 empaqueta bits en A-Z y 2-7

La sección seis del RFC 4648 define un alfabeto de treinta y dos símbolos: las veintiséis letras latinas mayúsculas seguidas de los seis dígitos del dos al siete. La codificación parte de bytes en bruto. Para el texto, esta capacidad primero convierte su cadena con UTF-8, de modo que los caracteres multibyte sigan siendo portables entre idiomas y plataformas.

Esos bytes se leen después como un flujo continuo de bits. Cada cinco bits seleccionan un índice del alfabeto y producen un carácter Base32. Cinco bytes de entrada aportan cuarenta bits, que se reparten exactamente en ocho caracteres Base32; los restos más cortos dejan un quinteto final parcial que se completa con ceros a la derecha y después con relleno de signos de igual, de modo que la longitud total sea siempre múltiplo de ocho.

La decodificación invierte la correspondencia: cada carácter que no es de relleno aporta cinco bits, los bytes completos se emiten en cuanto se acumulan ocho bits y el relleno final se comprueba en una posición legal. Los espacios en blanco se ignoran, por lo que los tokens de varias líneas pegados desde un correo siguen funcionando. Las letras minúsculas se convierten a mayúsculas antes de la búsqueda.

Ese rechazo estricto es intencionado: una sustitución silenciosa ocultaría errores de transcripción en secretos de autenticación y formatos de transmisión.

Qué se envía y qué se recibe

Envíe un campo de cadena obligatorio llamado text y un campo mode opcional con el valor encode o decode. Cuando mode se omite, encode es el valor predeterminado, de modo que una sola carga útil sigue haciendo trabajo útil. El modo encode trata text como contenido UTF-8 plano y devuelve una cadena result en el alfabeto del RFC 4648 con relleno.

El modo decode trata text como Base32, normaliza mayúsculas y espacios en blanco, valida el alfabeto y devuelve la cadena UTF-8 recuperada en result. Ambas direcciones devuelven mode, el text original, result, un campo length para la cadena de salida principal, las etiquetas alphabet y charset, un indicador padding y una breve cadena de referencia al estándar para que los clientes puedan comprobar qué perfil han alcanzado.

Las comprobaciones clásicas incluyen codificar Hello como JBSWY3DP, codificar la letra f sola como MY con seis signos de igual de relleno y decodificar un bloque conocido con relleno hasta recuperar foobar. Use el formulario gratuito del navegador para comprobaciones rápidas y demostraciones en clase, y después invoque el mismo contrato desde scripts cuando necesite material secreto en masa o casos de regresión.

Dónde aparece la codificación Base32 en el trabajo real

Los secretos de contraseñas de un solo uso basadas en tiempo del RFC 6238 y las aplicaciones de autenticación casi siempre viajan en Base32 para que los usuarios puedan escribirlos sin confundir el cero con la letra O o el uno con la letra I como ocurriría con Base64. Las cargas QR de aprovisionamiento y los códigos de respaldo necesitan, por tanto, una codificación fiable al generar claves y una decodificación estricta al importarlas.

El DNS y algunos sistemas de configuración de red prefieren alfabetos parecidos a Base32 para etiquetas opacas que deben sobrevivir a la normalización de mayúsculas. Los enlaces profundos móviles y los tokens cortos sin conexión suelen elegir Base32 porque el conjunto de símbolos es insensible a mayúsculas tras la normalización y evita los caracteres reservados de las URL. Los equipos de soporte pegan secretos de varias líneas desde incidencias y necesitan tolerancia a los espacios sin aceptar símbolos basura que producirían una clave incorrecta.

Quienes escriben material didáctico sobre esquemas de codificación quieren una página dedicada a Base32 en lugar de enterrarlo bajo una landing genérica de Base64, porque la intención de búsqueda y las reglas del alfabeto difieren. Si necesita Base64 con alfabeto seguro para URL, codificación porcentual para URL o conversión de enteros entre bases, trátelos como intenciones de búsqueda y landings independientes en lugar de sobrecargar esta página del codificador Base32.