Variantes de base64: alfabetos estándar y URL-safe, reglas de relleno y rigurosidad de los decodificadores

Qué es

Variante	Caracteres del alfabeto 62/63	Relleno (padding)	Saltos de línea
base64 estándar (RFC 4648 §4)	+ /	obligatorio, salvo que la especificación que lo referencia disponga otra cosa — "MUST include appropriate pad characters"	prohibidos, salvo que la especificación que lo referencia los exija
URL-safe / base64url (RFC 4648 §5)	- _	misma regla que el estándar, salvo que se modifique; el RFC señala que el relleno puede omitirse cuando la longitud es conocida	prohibidos, salvo que la especificación que lo referencia los exija
JWT / JWS BASE64URL (RFC 7515)	- _	se omite de forma explícita — "with all trailing '=' characters omitted"	no se permite ninguno — "without the inclusion of any line breaks"
MIME (RFC 2045)	+ /	obligatorio	obligatorios — no más de 76 caracteres por línea; los decodificadores deben ignorar los caracteres fuera del alfabeto

Por qué importa

RFC 4648 define dos alfabetos que se diferencian exactamente en dos caracteres y establece que el relleno es obligatorio "unless the specification referring to this document explicitly states otherwise." Los JWT son justamente una de esas excepciones: RFC 7515 omite por completo los caracteres = finales y prohíbe los saltos de línea, de modo que un segmento de JWT con relleno = o dividido en varias líneas es una entrada inválida para un decodificador estricto. MIME exige lo contrario: líneas de no más de 76 caracteres, y el comando base64 de GNU divide la salida con ese ancho por defecto, así que hay que indicar -w0 para obtener una única línea continua (-w es una opción de GNU coreutils; el base64 de macOS no divide líneas por defecto y usa -b para pedir saltos de línea). Además, los decodificadores difieren en su grado de tolerancia: base64.b64decode de Python descarta los caracteres fuera del alfabeto antes de comprobar el relleno, salvo que se pase validate=True. Por eso, una cadena base64url que se le entregue pierde sus - y _ y, o bien se decodifica en bytes erróneos, o bien falla por el relleno, sin señalar nunca los caracteres incorrectos. Además, lanza Incorrect padding ante una entrada sin relleno, que es justo lo que hace base64.urlsafe_b64decode con un segmento de JWT. El atob() del navegador lanza un InvalidCharacterError ante -, _ o cualquier otro carácter fuera del alfabeto estándar, pero acepta la falta de relleno e ignora los espacios en blanco ASCII. El paquete encoding/base64 de Go mantiene StdEncoding y URLEncoding como codecs distintos y no intercambiables, con RawStdEncoding/RawURLEncoding como formas explícitas sin relleno.

Cómo aplicarlo

• Elige el alfabeto según el contexto: en URL, nombres de archivo y JWT se necesitan -/_; en el resto de los casos se usa +// por defecto.
• Quita o añade el relleno de forma deliberada: los JWT no deben llevarlo; la mayoría de los demás consumidores lo esperan, salvo que se documente lo contrario.
• Usa base64 -w0 siempre que la salida de un script deba ser una sola línea.
• No te fíes de la tolerancia por defecto de base64.b64decode; pasa validate=True cuando una entrada malformada deba rechazarse sin más.
• Antes de decodificar en Python un valor base64url sin relleno, añade '=' * (-len(s) % 4); en Go, usa RawURLEncoding.

Trampas

• Pasar una cadena con relleno y alfabeto +// a un decodificador que espera base64url.
• Suponer que todos los decodificadores descartan los caracteres sobrantes como hace Python por defecto: atob() lanza una excepción.
• Suponer que -w0 es portable: es una opción de GNU coreutils, y el base64 de macOS usa -b en su lugar.
• Olvidar que -w0 es necesario para evitar saltos de línea en la salida de base64 dentro de scripts.