Relleno y longitud

La longitud de salida Base64 es predecible una vez comprendes el agrupamiento en seis bits. Los caracteres de relleno (=, a veces doble ==) comunican «este sexteto final se sintetizó a partir de menos de tres bytes finales» — nada mágico, solo contabilidad.

Cuándo aparece el relleno

La longitud de entrada módulo tres lo gobierna todo:

Bytes de entrada % 3	Relleno necesario
0	ninguno
1	==
2	=

¿Por qué? Cada quantum de salida codifica tres bytes ⇒ cuatro símbolos Base64. Los quanta parciales aún emiten cuatro símbolos, pero los sextetos finales que excederían bits reales se marcan como rellenados para que los decoders trunquen correctamente.

Omitir el relleno a veces parece funcionar porque algunas herramientas lo infieren automáticamente — pero las APIs entre lenguajes se rompen cuando un lado recorta = agresivamente y otro exige forma canónica.

Qué no es =

= no forma parte del alfabeto de payload de 64 símbolos en Base64 clásico — es metacaracter de relleno. Los decoders lo descartan o lo interpretan estrictamente como señal de longitud; editarlo accidentalmente (errores de concatenación en URL, truncamiento al copiar/pegar) corrompe silenciosamente las comprobaciones de longitud de salida.

Las bibliotecas deberían rechazar patrones de relleno inválidos (signos iguales mal colocados, basura final tras los signos iguales) en lugar de adivinar.

Modelo mental rápido con conteo de bits

• Cada tres octetos ⇒ cuatro símbolos del alfabeto.
• ¿Byte extra? Aún emites cuatro símbolos; dos de ellos llevan colectivamente semántica de relleno.
• Dos bytes extra producen = una vez; un byte sobrante solo produce ==.

Ver la tabla de módulo supera memorizar tablas bitwise para depurar.

Ajuste de línea y MIME

Codificadores de correo históricos insertaban saltos de línea cada ~76 caracteres para sobrevivir a terminales antiguas. Las APIs Base64 simples suelen omitir saltos; los bloques PEM envuelven deliberadamente a ancho de columna fijo.

Si concatenas líneas sin eliminar \n/\r antes de decodificar, muchos decoders estrictos fallan. A la inversa, algunos parsers ignoran espacios en blanco en todas partes — conoce la postura de tu stack.

Forma de ejemplo (solo conceptual)

Imagina codificar una sola letra ASCII a (0x61). Emites cuatro caracteres imprimibles terminando en == en codificaciones estándar — las bibliotecas muestran la cadena literal claramente en la documentación; vale la pena verificar una vez con la primitiva de tu lenguaje.

Nunca edites el relleno a mano para «optimizar» URLs — los dialectos URL-safe preservan formas sin = solo cuando el estándar lo permite explícitamente (ver siguiente lección).

Comprobaciones de longitud en código sensible a la seguridad

¿Comparas texto cifrado o firmas Base64? Desajustes de longitud normalizados exponen:

• bugs de truncamiento
• errores de doble codificación
• truncamiento del lado cliente en cadenas de consulta

Trata los payloads Base64 como cadenas opacas más validación estricta.

Idea clave

El relleno existe porque Base64 insiste en emitir cuatro símbolos de salida por fragmento de procesamiento, incluso cuando quedan menos de veinticuatro bits reales de entrada. Respeta el relleno canónico cuando las APIs lo exijan — y elimina/normaliza espacios en blanco según reglas documentadas, no según el folklore. Verifica longitudes con la herramienta Base64.