← RFC Reference

RFC 2047: MIME Parte 3 — Extensiones de Encabezado de Mensaje para Texto No ASCII

Por Qué Existe

RFC 2045 y RFC 2046 resolvieron el problema de transportar contenido no-ASCII en los cuerpos de mensajes con Content-Transfer-Encoding. Pero los encabezados de correo electrónico — Subject, nombres de visualización de From, nombres de visualización de To, y otros — están regidos por RFC 5322, que los restringe a ASCII de 7 bits.

Esto crea un problema evidente: miles de millones de usuarios de correo electrónico escriben en idiomas que requieren caracteres no-ASCII. Sin RFC 2047, no podrías enviar un correo electrónico con:

• Una línea Subject en chino, japonés, coreano, árabe, hebreo o tailandés
• Un nombre de visualización del remitente con caracteres acentuados (René, Müller, Björk)
• Cualquier campo de encabezado que contenga caracteres fuera del rango ASCII

RFC 2047 define la sintaxis de palabra codificada: una forma compacta de insertar texto no-ASCII dentro de encabezados solo-ASCII, legible por cualquier cliente de correo compatible con MIME.

Cómo Funciona

El Formato de Palabra Codificada

Una palabra codificada tiene esta estructura:

=?charset?encoding?encoded-text?=

Los tres componentes son:

Codificación B (Base64)

Usa codificación base64 estándar. Mejor para texto que es fuertemente no-ASCII, como scripts CJK:

; Subject: "Meeting confirmation" en japonés
Subject: =?UTF-8?B?5Lya6K2w44Gu56K66KqN?=

; Nombre de visualización de From en chino
From: =?UTF-8?B?5byg5LiJ?= <zhang@example.com>

Codificación Q (Variante Quoted-Printable)

Una codificación quoted-printable modificada optimizada para encabezados. Como QP de cuerpo, los bytes no-ASCII se convierten en pares hexadecimales =XX. Diferencia clave: los espacios se codifican como guiones bajos (_):

; Subject: "Café menu" con e acentuada
Subject: =?UTF-8?Q?Caf=C3=A9_menu?=

; Nombre de visualización de From: "René Dupont"
From: =?UTF-8?Q?Ren=C3=A9_Dupont?= <rene@example.com>

; Subject: "Gruße aus Berlin" (saludos alemanes)
Subject: =?UTF-8?Q?Gru=C3=9Fe_aus_Berlin?=

La codificación Q es más legible por humanos cuando la mayoría del texto es ASCII con solo algunos caracteres no-ASCII. La codificación B es más compacta cuando la mayoría de los caracteres son no-ASCII.

Dónde Pueden Aparecer Palabras Codificadas

Las palabras codificadas se permiten en posiciones específicas dentro de encabezados:

• Subject, Comments, Keywords: En cualquier lugar donde se espere texto (como reemplazo de un atom o quoted-string).
• From, To, Cc, Bcc, Reply-To, Sender: Solo en la porción del nombre de visualización, nunca en la dirección de correo electrónico misma.
• Content-Description: Permitido para describir partes MIME.

Las palabras codificadas no se permiten dentro de quoted-strings, en la parte local o dominio de una dirección de correo electrónico, o como valores de parámetros en encabezados estructurados como Content-Type (usa RFC 2231 para eso).

Detalles Técnicos Clave

Límites de Longitud

Cada palabra codificada no debe exceder 75 caracteres. Si el texto codificado es más largo, debe dividirse en múltiples palabras codificadas separadas por espacios en blanco plegables (CRLF + espacio o tabulación):

; Tema largo dividido en dos palabras codificadas
Subject: =?UTF-8?B?5LuK5pel44Gu5Lya6K2w44Gr44Gk44GE44Gm?=
 =?UTF-8?B?44GU5qGI5YaF44GE44Gf44GX44G+44GZ?=

Cuando dos palabras codificadas adyacentes se separan solo por espacios en blanco lineales, el espacio en blanco entre ellas se ignora durante la decodificación. Esto permite dividir sin problemas texto largo en múltiples palabras codificadas.

Selección de Juego de Caracteres

Siempre usa UTF-8 para nuevos mensajes. Los otros juegos de caracteres existen por razones heredadas:

Interacción con Plegado de Encabezado

RFC 5322 limita las líneas de encabezado a 998 caracteres y recomienda mantenerlas bajo 78. Las palabras codificadas interactúan con el plegado: puedes interrumpir entre palabras codificadas en límites de espacios en blanco, pero nunca debes interrumpir en medio de una palabra codificada. El contenedor =?...?= debe estar en una sola línea.

Reglas de Decodificación

Cuando un cliente de correo encuentra una palabra codificada, lo hace:

1. Extrae el juego de caracteres, tipo de codificación y texto codificado del contenedor =?charset?encoding?text?=.
2. Decodifica el texto usando base64 (B) o quoted-printable (Q).
3. Interpreta los bytes resultantes de acuerdo con el juego de caracteres declarado.
4. Muestra el texto Unicode decodificado al usuario.

Si el cliente no reconoce el juego de caracteres, debe mostrar la palabra codificada como está en lugar de mostrar texto ilegible.

Ejemplos

Un Mensaje Completo con Encabezados Codificados

MIME-Version: 1.0
From: =?UTF-8?Q?Ren=C3=A9_Dupont?= <rene@example.fr>
To: =?UTF-8?B?5bGx55Sw5aSq6YOO?= <yamada@example.jp>
Subject: =?UTF-8?Q?Re:_R=C3=A9union_du_15_mars?=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Bonjour Taro,

Confirmons la r=C3=A9union pour le 15 mars.

Nota: el encabezado usa palabras codificadas RFC 2047 (=?...?=), mientras que el cuerpo usa codificación quoted-printable regular (=XX sin el contenedor). Estos son mecanismos diferentes para diferentes partes del mensaje.

Comparación de Codificación

El mismo texto — "München" — codificado ambas formas:

; Codificación Q: legible, bueno para texto mayormente ASCII
=?UTF-8?Q?M=C3=BCnchen?=

; Codificación B: compacta pero opaca
=?UTF-8?B?TcO8bmNoZW4=?=

Errores Comunes

• Codificar la dirección de correo electrónico misma. Solo el nombre de visualización puede codificarse. =?UTF-8?Q?user?=@example.com es inválido y será rechazado o malinterpretado. Para direcciones de correo electrónico internacionalizadas, ve RFC 6531/6532.
• Falta de espacio entre palabras codificadas y texto regular. Una palabra codificada debe separarse del texto adyacente por espacios en blanco. Hello=?UTF-8?Q?World?= está mal formado; debería ser Hello =?UTF-8?Q?World?=.
• Interrumpir una palabra codificada en líneas. El token completo =?...?= debe caber en una línea. Si necesitas plegar, divide en múltiples palabras codificadas en límites de palabras.
• Usar RFC 2047 en parámetros Content-Type. Las palabras codificadas no son válidas en parámetros de encabezados estructurados como filename= o name=. Usa codificación de parámetros RFC 2231 en su lugar: filename*=UTF-8''R%C3%A9sum%C3%A9.pdf.
• Exceder el límite de 75 caracteres. Cada palabra codificada debe ser de 75 caracteres o menos. El texto largo debe dividirse en múltiples palabras codificadas. Las palabras codificadas de tamaño excesivo pueden ser silenciosamente truncadas por servidores de correo.
• Codificación doble. Codificar texto que ya está codificado produce basura como =?UTF-8?Q?=3D=3FUTF-8=3FQ=3F...?=. Asegúrate de que tu canalización de codificación se ejecute exactamente una vez.

Impacto en la Entregabilidad

• La codificación incorrecta activa filtros de spam. Las palabras codificadas mal formadas en líneas Subject son una bandera roja. Los filtros de spam han visto décadas de codificación rota de herramientas de spam. Una codificación limpia y compatible con estándares señala software de envío legítimo.
• La codificación del nombre de visualización afecta la confianza. Si el nombre de visualización de From contiene caracteres no-ASCII que no están debidamente codificados, los destinatarios ven texto sin procesar =?UTF-8?Q?...?= en lugar de un nombre legible. Esto se ve sospechoso y daña las tasas de apertura.
• La representación de la línea Subject es crítica para el compromiso. Una línea Subject corrupta debido a un juego de caracteres incorrecto o codificación rota significa que el destinatario no puede leerla. El correo electrónico se ignora o se reporta como spam.
• Siempre usa UTF-8. Los juegos de caracteres heredados como ISO-8859-1 no pueden representar todos los caracteres. Si un sistema mezcla juegos de caracteres en diferentes encabezados, los clientes pueden mostrar algunos correctamente y otros como mojibake. Estandariza en UTF-8 en todas partes.
• Prueba en varios clientes. Outlook, Gmail, Apple Mail y Thunderbird tienen comportamientos de decodificación RFC 2047 ligeramente diferentes, especialmente alrededor de casos límite como palabras codificadas largas y mezcla de codificación/no-codificación en un solo encabezado.

Related RFCs