Qué es Base32 según RFC 4648
Base32 representa bytes con A-Z y los dígitos 2-7. Cada símbolo transporta cinco bits, por lo que el alfabeto contiene exactamente treinta y dos caracteres. Es más largo que Base64, pero evita puntuación y suele funcionar bien en identificadores que no distinguen mayúsculas.
Esta página convierte primero el texto Unicode a bytes UTF-8. Así se conservan correctamente letras acentuadas, texto CJK y emoji. Al decodificar, los símbolos vuelven a bytes y esos bytes deben formar UTF-8 válido para mostrarse como texto.
El interruptor de relleno solo controla los signos = finales. Se aceptan valores con o sin relleno, pero se comprueba que la longitud sea posible y que los bits sobrantes sean cero para evitar representaciones ambiguas.
Cómo usar el conversor Base32
- Elige Codificar para texto normal y Decodificar para una cadena Base32.
- Decide si el protocolo de destino exige relleno hasta bloques de ocho caracteres.
- Introduce el valor; los errores de alfabeto, longitud, relleno o UTF-8 se muestran sin adivinar correcciones.
- Compara con los vectores oficiales para revisar otra biblioteca o API.
- Intercambia la dirección para comprobar una ida y vuelta, sin olvidar la política del protocolo externo.
Ejemplos y vectores oficiales de Base32
Los ejemplos cubren los vectores RFC 4648, Unicode, minúsculas y las dos políticas de relleno.
| Entrada | Salida | Dirección de conversión | Nota |
|---|---|---|---|
f |
MY====== |
Codificar | Incluir relleno: Con relleno — Vector RFC: un byte. Un byte produce dos caracteres de datos y seis signos de relleno. |
foobar |
MZXW6YTBOI====== |
Codificar | Incluir relleno: Con relleno — Vector RFC: foobar. Es el vector de texto más largo de la sección 10 de RFC 4648. |
Hello |
JBSWY3DP |
Codificar | Incluir relleno: Sin relleno — Texto sin relleno. Los caracteres de datos no cambian; solo se omiten los signos finales. |
jbswy3dp |
Hello |
Decodificar | Decodificar minúsculas. La salida canónica es mayúscula, pero el decodificador admite minúsculas. |
你好 |
4S62BZNFXU====== |
Codificar | Incluir relleno: Con relleno — Unicode en UTF-8. Los caracteres chinos se convierten primero en seis bytes UTF-8. |
∅ |
∅ |
Codificar | Incluir relleno: Con relleno — Valor vacío. Una secuencia vacía tiene una representación Base32 vacía. |
Entrada aceptada y forma canónica
La codificación acepta texto Unicode válido. La decodificación admite A-Z, 2-7, letras minúsculas opcionales y relleno únicamente al final. Los espacios no se eliminan automáticamente.
Sin relleno, la longitud módulo ocho solo puede ser 0, 2, 4, 5 o 7. Con relleno, el número de signos = debe coincidir exactamente con el último bloque.
- La salida canónica usa mayúsculas.
- El relleno solo puede estar al final.
- 0, 1, 8 y 9 no pertenecen al alfabeto.
- Los bits sobrantes distintos de cero se rechazan.
- Datos binarios válidos pueden no ser texto UTF-8.
Cómo funciona el algoritmo Base32
El codificador acumula bits de los bytes UTF-8 y extrae grupos de cinco para indexar el alfabeto. Los bits finales se alinean y se completan temporalmente con ceros.
El decodificador realiza el proceso inverso, reuniendo grupos de cinco hasta emitir bytes de ocho bits. Después aplica una decodificación UTF-8 estricta.
Antes y después del bucle se validan alfabeto, residuos de longitud, cantidad de relleno y bits no usados, siguiendo un comportamiento estricto apropiado para pruebas de protocolos.
Cuándo resulta útil Base32
Base32 sirve cuando los bytes deben viajar como texto sin puntuación problemática. No cifra ni autentica los datos.
| Uso | Descripción |
|---|---|
| Secretos TOTP | Muchos autenticadores muestran secretos compartidos como Base32 sin relleno. |
| Identificadores sin distinción de mayúsculas | El alfabeto restringido resiste mejor sistemas que modifican las mayúsculas o minúsculas. |
| Protocolos relacionados con DNS | Algunos usan variantes de Base32; hay que comprobar el alfabeto exacto. |
| Pruebas de interoperabilidad | Los vectores oficiales revelan fallos de límites y relleno. |
| Valores binarios visibles | Evita 0 y 1, aunque no corrige errores de copia. |
Errores y límites de Base32
Los fallos más comunes son mezclar alfabetos, copiar una cadena incompleta o aplicar el relleno de otro sistema. Una cadena puede parecer correcta y aun tener una longitud imposible.
Base32 representa bytes. Un hash, una clave o un archivo puede decodificarse correctamente como bytes y fallar en esta interfaz de texto por no ser UTF-8.
- 0 o 1 no sustituyen a O o I.
- Un solo carácter de datos es imposible.
- El relleno intermedio es inválido.
- El último símbolo puede introducir bits sobrantes no canónicos.
- Base32 no ofrece confidencialidad.
Base32 frente a otras codificaciones
Base32 sacrifica longitud para obtener un alfabeto pequeño. Base64 es más denso y Base58 busca facilitar la transcripción humana mediante una conversión de base entera.
Crockford Base32, base32hex y z-base-32 usan reglas distintas. Esta página implementa únicamente el alfabeto estándar RFC 4648.
| Formato | Descripción |
|---|---|
| Base64 | Más corto, pero + y / pueden requerir tratamiento especial. |
| Base58 | Elimina caracteres ambiguos y conserva ceros iniciales, sin relleno RFC 4648. |
| Hexadecimal | Es directo y fácil de inspeccionar, pero más largo. |