Tabla del alfabeto Base64

Los 64 caracteres

Base64 lee la entrada de 3 en 3 bytes (24 bits) y los divide en cuatro números de 6 bits. Cada número, de 0 a 63, es un índice de esta tabla. El orden lo fija el RFC 4648: mayúsculas del 0 al 25, minúsculas del 26 al 51, dígitos del 52 al 61 y después + y /. La última columna es el código ASCII del carácter, que es lo que realmente se guarda o se envía.

Conviene memorizar dos rangos. Todos los caracteres de A a P (0 a 15) empiezan por los bits 00, y todos los de w a / (48 a 63) empiezan por 11. Con eso basta para decodificar un carácter de cabeza cuando revisas un prefijo a mano. En cómo funciona Base64 hay un ejemplo resuelto de la división en bits.

El orden del alfabeto no es el orden ASCII. En ASCII van primero + y /, luego los dígitos, luego las mayúsculas y por último las minúsculas. Por eso, ordenar cadenas Base64 no ordena los bytes subyacentes: +A== (el byte F8) queda antes que AA== (el byte 00). Si necesitas valores codificados que se ordenen igual que los bytes originales, usa base32hex del RFC 4648 o hexadecimal sin más.

El alfabeto URL-safe

+ y / tienen un significado especial en las URL. + se decodifica como espacio en las query strings y en los datos de formularios, y / separa los segmentos de la ruta. Base64URL, definido en la sección 5 del RFC 4648, conserva los índices 0 a 61 y cambia los dos últimos:

Todo lo demás, incluida la disposición de los bits, es idéntico, así que convertir de uno a otro consiste en sustituir caracteres y añadir o quitar el relleno. Los JWT, muchos tokens de API y los identificadores aptos para nombres de archivo usan Base64URL, normalmente sin =. El codificador Base64URL lo genera directamente. La comparación completa está en Base64 frente a Base64URL.

El carácter de relleno

= (ASCII 0x3D) no forma parte del alfabeto de 64 caracteres y nunca codifica datos. Solo completa el último grupo de 4 caracteres cuando la longitud de la entrada no es múltiplo de 3:

• Sobra 1 byte: 2 caracteres de datos más ==.
• Sobran 2 bytes: 3 caracteres de datos más =.
• No sobra ningún byte: sin relleno.

Por tanto, una cadena con relleno siempre tiene una longitud múltiplo de 4, y nunca verás ===. Sin relleno, la longitud dividida entre 4 deja de resto 0, 2 o 3, nunca 1. La guía del relleno explica cuándo se puede omitir = y cómo restaurarlo.

Qué caracteres aparecen en cada posición

Algunos patrones se deducen directamente de la disposición de los bits. Los comprobamos por fuerza bruta con todos los valores de byte relevantes.

Antes de == solo verás A, Q, g o w. Cuando sobra un byte, el segundo carácter lleva 2 bits de datos seguidos de 4 bits a cero, así que su índice es 0, 16, 32 o 48. Antes de un solo =, el tercer carácter termina en 2 bits a cero, de modo que es uno de estos 16: A E I M Q U Y c g k o s w 0 4 8. Cualquier otro carácter en esa posición indica una codificación no canónica, que los decodificadores estrictos rechazan.

Los bytes aleatorios usan los 64 caracteres por igual. Cada grupo de 6 bits de datos aleatorios tiene una distribución uniforme, así que los datos cifrados, las claves y los archivos comprimidos producen una distribución de caracteres plana. Una distribución sesgada sugiere que los datos son texto o tienen estructura.

El texto ASCII nunca pone en primer lugar una g a z minúscula, un dígito, + ni /. El primer carácter de cada grupo de 4 contiene los 6 bits altos de un byte. En ASCII de 7 bits el bit más alto es 0, así que ese carácter siempre está entre A y f (índices 0 a 31). En SGVsbG8gd29ybGQh (Hello world!) los grupos empiezan por S, b, d y b.

En el Base64 de un texto ASCII, + y / son poco frecuentes. Con bytes por debajo de 0x80, + solo puede aparecer como cuarto carácter de un grupo, cuando el tercer byte es > o ~. / solo puede aparecer ahí cuando ese byte es ? o el carácter de control DEL. Por eso Hi?> se codifica como SGk/Pg== y <b> como PGI+.

Las rachas de A son bytes cero; las de /, bytes 0xFF. AAAA son tres bytes 00 y //// son tres bytes FF. Los tramos largos de A son típicos de formatos binarios dispersos, del texto UTF-16 (Hello es SABlAGwAbABvAA==) y de los campos de longitud al principio de las claves SSH. Encontrarás más patrones reconocibles en prefijos Base64 habituales.

Otros alfabetos Base64

Varios sistemas mantuvieron la idea de 64 caracteres por cada 6 bits, pero eligieron otros caracteres:

• IMAP sustituye / por , porque / es un separador de jerarquía habitual en los nombres de buzón. Una carpeta llamada Entwürfe se guarda como Entw&APw-rfe.
• bcrypt pone . y / al principio y deja las letras antes que los dígitos. Sus salts y hashes son Base64 en este alfabeto sin relleno, y por eso un decodificador estándar devuelve bytes incorrectos con ellos.
• crypt(3) usa ./0-9A-Za-z, que es el orden ASCII. Además empaqueta los bits empezando por el extremo menos significativo, así que ni siquiera traduciendo el alfabeto un decodificador estándar reproduce los bytes del hash.
• uuencode y xxencode son anteriores a MIME. Las herramientas uuencode y xxencode leen y escriben ambos formatos.

Para codificaciones con alfabetos de otro tamaño, como Base32, Base58 y Base85, consulta Base64 frente a hex, Base32, Base58 y Base85. Las definiciones de los términos usados aquí están en el glosario.

Preguntas frecuentes