Resumen

  • La RFC 3548 abordó una fuente pequeña pero persistente de incompatibilidad: muchos protocolos decían «base64» sin fijar alfabeto, saltos de línea, relleno ni reacción ante caracteres ajenos al alfabeto.
  • Su idea central fue que las reglas MIME del correo constituyen un perfil concreto, no un contrato universal para cualquier decodificador.

Un editor de texto puede abrir una cadena Base64. De ahí nace una intuición engañosa: entran bytes, salen caracteres imprimibles y cualquier decodificador debería poder deshacer el camino. La historia que recoge la RFC 3548 es menos simple. Las implementaciones habían acumulado pequeñas diferencias, mientras que algunos protocolos invocaban «base64» como si el nombre resolviera todas las decisiones.

La discrepancia no estaba en la aritmética de seis bits, sino en el margen que la rodea. ¿Debe el codificador insertar saltos de línea? ¿Es obligatorio el = final? ¿Se rechaza un carácter inesperado o se ignora? ¿Qué símbolos ocupan las 64 posiciones? Tomar la respuesta de un formato vecino puede funcionar dentro de él y fallar ante un interlocutor que espera otro comportamiento.

Publicada en julio de 2003 como RFC informativa, la RFC 3548 buscó reducir esa ambigüedad. Su introducción observó un atajo frecuente: documentos de protocolo mencionaban «base64» sin descripción ni referencia precisa y a menudo acudían a MIME sin considerar las consecuencias de los saltos de línea o los caracteres fuera del alfabeto. El documento reunió los esquemas Base16, Base32 y Base64 de uso común y puso sus parámetros sobre la mesa.

MIME era una fuente de confusión precisamente porque definía un contexto propio. La RFC 2045 describe Base64 como una codificación de transferencia para el contenido de mensajes. Su límite de 76 caracteres por línea pertenece al correo; PEM había empleado 64 caracteres en un contexto similar. La regla general de la RFC 3548 para quien la invoca es no añadir saltos de línea salvo que la especificación lo pida. Un salto no es decorativo si otro analizador puede contarlo como dato o rechazarlo.

El relleno y la tolerancia también dependen del perfil. La RFC 3548 exige que el codificador incluya el relleno necesario, excepto si la especificación de referencia dispone lo contrario. El decodificador debe rechazar caracteres ajenos al alfabeto, a menos que una regla explícita elija otra política. MIME puede ignorarlos, incluidos CRLF, pero esa excepción pertenece a MIME. Trasladarla a otro protocolo cambia qué entradas se aceptan. La RFC menciona canales encubiertos y errores de implementación como motivos de cautela; no relata un ataque concreto contra un producto identificado.

También hacía falta nombrar el alfabeto. El Base64 habitual usa + y / para los valores 62 y 63. La RFC 3548 documenta una variante segura para URL y nombres de archivo que sustituye esos signos por y _. Aclara que no debe tratarse como el mismo formato ni llamarse simplemente «base64». Un campo de ruta o identificador impone condiciones distintas a las de un cuerpo de correo.

En octubre de 2006, la RFC 4648 sustituyó a la RFC 3548 como documento de estándares. Conservó el enfoque por perfiles y añadió la codificación canónica: los bits de relleno de Base64 y Base32 deben ser cero; de lo contrario, varias cadenas pueden decodificarse en los mismos bytes. Es un asunto distinto del plegado de líneas de MIME. Leídas juntas, ambas RFC enseñan por qué «se pudo decodificar» no completa una especificación: emisor y receptor aún deben acordar grafía, relleno, tolerancia y el nivel donde se interpreta el valor.

La codificación base no cifra ni autentica. Es una representación textual de octetos para ciertos transportes. El legado más útil de la RFC 3548 es más modesto: un nombre conocido no equivale a un conjunto completo de reglas.

Fuentes