Español

Herramientas de desarrollo · Codificador y decodificador Base64

Por qué los archivos adjuntos de correo electrónico son Base64: MIME, transporte de 7 bits y líneas de columnas 76

· Antecedentes

base64 codificación

encabezado MIME Content-Transfer-Encoding y ajuste de línea Base64 de 76-character para transporte de correo electrónico
Ilustración de vector original de ToolAcre

El correo electrónico se creó para texto ASCII de 7 bits y los archivos adjuntos debían caber a través de él. Esta publicación analiza cómo MIME adoptó Base64, por qué las líneas se ajustan a 76 caracteres y qué significa eso para el tamaño y la depuración.

El archivo adjunto que llegó dañado a través de un relé antiguo: el problema de 8 bits para el cual se inventó MIME

El correo electrónico se diseñó en las décadas de 1970 y 1980 solo para texto ASCII de 7 bits. SMTP, el protocolo que transporta el correo electrónico, espera que cada línea tenga como máximo 998 caracteres de 7 bits ASCII (caracteres 0-127). Enviar un archivo binario como PDF o una imagen directamente a través de SMTP fallaría: los bytes 128-255 serían dañados o rechazados por los servidores y repetidores de correo antiguos. Los archivos adjuntos necesitan codificación. MIME (Extensiones multipropósito de correo de Internet, RFC 2045) resolvió esto definiendo valores de encabezado de codificación de transferencia de contenido, incluido base64, que representa cualquier secuencia de bytes como texto ASCII de 7 bits.

MIME ofrece varias opciones de codificación de transferencia de contenido: 7 bits (sin codificación, solo para ASCII seguro), 8 bits (para servidores que admiten bytes de 8 bits, no universales), imprimible con comillas (codifica solo bytes no seguros, manteniendo ASCII legible) y base64 (codifica todo, maximizando la compatibilidad). Se eligió Base64 para archivos adjuntos binarios porque es simple, estandarizado y garantiza la seguridad en cualquier sistema de correo, sin importar cuán antiguo sea o que sea estrictamente de 7 bits. La compensación es el tamaño: Base64 es aproximadamente un tercio más grande que los bytes originales.

El problema de transporte que resuelve Base64: representar bytes arbitrarios con caracteres imprimibles

A 3 KB PDF se convierte aproximadamente en 4 KB de texto Base64. El límite de línea de 76 caracteres proviene del RFC 2045.

SMTP permite líneas de hasta 998 caracteres, pero los sistemas de correo más antiguos y algunos filtros de spam rechazan líneas largas. RFC 2045 especifica que las líneas MIME Base64 no deben exceder los 76 caracteres (más un final de línea CRLF), por lo que un servidor de correo nunca interrumpirá el transporte. El límite no es mágico; es un compromiso histórico entre legibilidad (los caracteres 76 se adaptan a la mayoría de los terminales de la década de 1980), la compatibilidad con sistemas antiguos y evitar la detección como spam o patrones de virus.

Las opciones de salida visibles en esta herramienta: relleno canónico y ajuste de caracteres 76 opcional

Los sistemas de correo modernos generalmente admiten líneas más largas, pero la codificación en líneas de caracteres 76 garantiza que el archivo adjunto llegue incluso al receptor más antiguo. Después de que RFC 2045 definiera MIME Base64, RFC 4288 (tipos de medios) y RFC 2183 (Disposición de contenido) agregaron formas estandarizadas para etiquetar archivos adjuntos. Un mensaje con un archivo adjunto PDF incluye un encabezado Content-Transfer-Encoding: base64, un encabezado Content-Type: application/pdf y los PDF bytes codificados como Base64 con líneas de caracteres 76. Un lector de correo decodifica las líneas eliminando los saltos de línea (caracteres CRLF) y luego decodificando Base64 para recuperar los bytes originales.

Para decodificar un archivo adjunto MIME Base64 es necesario ignorar los espacios en blanco. El RFC dice: los decodificadores deben omitir los saltos de línea (caracteres CR y LF) durante la decodificación. Por eso es práctico un decodificador Base64 que acepte espacios en blanco; la mayoría de los correos MIME reales tendrán saltos de línea. Algunos decodificadores son estrictos y rechazan los espacios en blanco (adecuados para contextos como JWT, donde no deben estar presentes saltos de línea), mientras que otros son indulgentes y omiten los espacios en blanco (adecuados para MIME).

La opción de carácter 76 en la práctica: cómo el codificador inserta y el decodificador ignora los saltos de línea

La herramienta de codificación y decodificación Base64 puede manejar ambas cosas: acepta un archivo adjunto pegado de varias líneas e ignora los saltos de línea durante la decodificación. El tamaño del impacto es predecible. El ajuste RFC 2045 base64 agrega un CRLF (2 bytes) por cada 76 caracteres de salida. Para un archivo 10 KB, Base64 es aproximadamente 13.3 KB, más CRLF cada 76 caracteres: aproximadamente 13.5 KB en total. La sobrecarga es aproximadamente un tercio más de bytes.

Los límites de tamaño del correo electrónico generalmente se establecen para el tamaño codificado, no para el tamaño del archivo original; un servidor de correo con un límite 25 MB significa 25 MB del mensaje codificado, no 25 MB de archivos adjuntos. Calcular el tamaño del archivo original requiere dividir por 1.33 (o más precisamente, por 4 dividido por 3). La codificación imprimible entre comillas es una alternativa que mantiene el ASCII imprimible sin cambios y codifica solo bytes 128-255 y algunos caracteres especiales.

Ejemplo resuelto: leer una fuente de mensaje sin procesar: encontrar la parte Base64 y decodificar un pequeño archivo adjunto de texto

Un archivo de texto con principalmente ASCII sigue siendo legible si abre la fuente del mensaje sin formato. Base64 confunde todo, incluso el texto ASCII sin formato. Quoted-printable rara vez se usa para archivos binarios (sería muy ineficiente para un PDF), pero a veces se usa para texto. Un lector de correo elige la codificación según el tipo de archivo adjunto; Por lo general, un navegador no pregunta al usuario qué codificación aplicar.

El cuerpo Base64 de un mensaje de correo electrónico son solo los bytes en sí, no un archivo separado. Cuando ve un archivo adjunto en un lector de correo, el lector ya ha decodificado Base64 y muestra el archivo original.

El costo del tamaño en la práctica: aproximadamente un tercio más de bytes y por qué se establecen límites de tamaño de correo para el tamaño codificado

Si ve el origen del mensaje sin formato (una opción en la mayoría de los clientes de correo), verá los encabezados MIME y el cuerpo codificado en Base64. La herramienta codificadora y decodificadora Base64 puede ayudarle a decodificar manualmente un fragmento de la fuente de un mensaje; Copie la parte Base64, elimine los saltos de línea y péguela en la herramienta.

Varios archivos adjuntos en un mensaje MIME utilizan un límite de varias partes. Cada parte tiene sus propios encabezados (Tipo de contenido, Codificación de transferencia de contenido) y cuerpo. Una versión alternativa en texto plano del mensaje aparece como una parte y cada archivo adjunto aparece como otra parte. La cuerda delimitadora separa las partes; se elige que no aparezca en el contenido de ninguna parte. Un lector de correo reconstruye el mensaje analizando los límites y decodificando cada parte según su encabezado Content-Transfer-Encoding.

Lo que esto no cubre: encabezados de palabras codificadas, S/MIME y la extensión 8BITMIME en profundidad

RFC 2045 La codificación base64 no es universal hoy en día. Algunos sistemas de correo admiten transporte de 8 bits y ya no requieren base64. Algunos sistemas utilizan diferentes nombres de codificación o agregan encabezados personalizados. Pero base64 con 76 líneas de caracteres sigue siendo la opción más compatible para archivos adjuntos que deben llegar a cualquier sistema de correo, en cualquier lugar. Cuando adjunta un archivo usando un cliente de correo, el cliente generalmente elige base64 automáticamente para archivos binarios, maneja el ajuste de línea y agrega los encabezados MIME.

Comprender el mecanismo le ayuda a depurar cuando un archivo adjunto parece dañado o cuando está trabajando manualmente con una fuente de mensaje. Para crear o analizar un mensaje de correo electrónico saliente es necesario comprender la estructura MIME. Una biblioteca debe manejar la codificación, el ajuste de líneas y los encabezados; normalmente no se construye MIME manualmente. Pero si está analizando una fuente de mensaje sin formato (depurando un problema de entrega o extrayendo archivos adjuntos mediante programación), saber que Content-Transfer-Encoding: base64 significa que el siguiente cuerpo es 76-character-wrapped base64 le permite aplicar el decodificador correcto.

Conclusión: Base64 es la capa de compatibilidad del correo electrónico: cómo el codificador y descodificador Base64 le permite leer localmente una pequeña parte de texto de un mensaje sin formato

La base64 en sí es el RFC estándar 4648; el envoltorio y los encabezados MIME son específicos del correo electrónico. Los archivos adjuntos de correo electrónico son base64 porque el correo electrónico se creó para texto sin formato y base64 es la capa de compatibilidad más simple y universal para enviar datos binarios a través de un protocolo de solo texto. El límite de línea de caracteres 76 es un artefacto histórico de las terminales y redes lentas de la década de 1980, pero persiste como estándar de compatibilidad.

Comprender este historial explica por qué existe MIME, por qué existen múltiples opciones de codificación y por qué base64 sigue siendo el valor predeterminado para los archivos adjuntos, aunque los sistemas de correo modernos podrían admitir archivos binarios directamente. El codificador y decodificador Base64 le permite trabajar manualmente con cuerpos MIME para verificar o depurar la codificación.