← RFC Reference

RFC 2231: Extensiones de Valor de Parámetro MIME

Por Qué Existe Esto

Los parámetros MIME aparecen en encabezados como Content-Type y Content-Disposition. El caso de uso más común es el parámetro filename para adjuntos:

Content-Disposition: attachment; filename="report.pdf"

Esto funciona bien para nombres de archivo ASCII. ¿Pero qué hay de un archivo llamado 報告書.pdf (japonés para "informe") o un nombre de archivo con 200 caracteres? La especificación MIME original (RFC 2045) no tenía mecanismo para esto. RFC 2231 resuelve tres problemas:

• Juegos de caracteres: codificar caracteres no-ASCII en valores de parámetros
• Etiquetas de idioma: anotar valores de parámetros con un identificador de idioma
• Continuaciones: dividir valores de parámetros largos en múltiples líneas

Cómo Funciona

Codificación de Juego de Caracteres e Idioma

Para incluir caracteres no-ASCII, añade un asterisco al nombre del parámetro y usa el formato charset'language'encoded-value:

Content-Disposition: attachment;
    filename*=UTF-8''%E5%A0%B1%E5%91%8A%E6%9B%B8.pdf
             ^^^^^^^  ^^  ^^^^^^^^^^^^^^^^^^^^^^^^
             juego de caracteres  idioma  valor codificado en porcentaje
                     (vacío = sin etiqueta de idioma)

El valor %E5%A0%B1%E5%91%8A%E6%9B%B8 son los bytes UTF-8 para "報告書" codificados en porcentaje. La etiqueta de idioma entre comillas simples es opcional (a menudo se deja vacía).

Continuaciones para Valores Largos

Cuando un valor de parámetro es demasiado largo para una línea de encabezado única, divídelo usando continuaciones numeradas:

Content-Type: application/pdf;
    filename*0="very-long-document-name-that-exceeds-the";
    filename*1="-reasonable-line-length-limit-for-headers.pdf"

Las partes se reensambian en orden numérico: *0, *1, *2, etc.

Combinado: Continuaciones con Juegos de Caracteres

Para valores no-ASCII largos, combina ambas características. Solo el primer segmento incluye el juego de caracteres e idioma; los segmentos siguientes son solo valores codificados:

Content-Disposition: attachment;
    filename*0*=UTF-8''%E3%81%93%E3%82%8C%E3%81%AF%E9%95%B7;
    filename*1*=%E3%81%84%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB;
    filename*2*=%E5%90%8D.pdf
          ^^^^
          número + asterisco = continuación codificada

Detalles Técnicos Clave

Sintaxis de Nombre de Parámetro

Reglas de Codificación

• Usa codificación de porcentaje (como codificación URL) para octetos no-ASCII
• Los caracteres ASCII que son seguros en tokens MIME (letras, dígitos, guiones, puntos) no necesitan codificación
• El juego de caracteres es casi siempre UTF-8 en la práctica moderna
• La etiqueta de idioma sigue BCP 47 (p. ej., en, ja, zh-CN) pero a menudo se omite

Interacción con RFC 2047

RFC 2047 proporciona palabras codificadas (=?UTF-8?B?...?=) para texto no-ASCII en encabezados. Sin embargo, RFC 2047 establece explícitamente que las palabras codificadas NO deben aparecer dentro de cadenas entrecomilladas o valores de parámetros. RFC 2231 es el mecanismo correcto para parámetros MIME. A pesar de esta regla, muchos clientes de correo usan RFC 2047 en parámetros filename de todas formas, por lo que los analizadores robustos deben manejar ambos.

Errores Comunes

• Usar codificación RFC 2047 en valores de parámetros. Escribir filename="=?UTF-8?B?...?=" es técnicamente inválido, pero generalizado. Para máxima compatibilidad, envía ambos: un filename plano con respaldo ASCII y un filename* con el valor codificado RFC 2231.
• Olvidar el asterisco doble para continuaciones codificadas. filename*1 es una continuación de texto plano. filename*1* es una continuación codificada. Falta el asterisco final significa que el valor será tratado como texto literal, no decodificado.
• Orden de continuación incorrecto. Las partes deben numerarse secuencialmente comenzando en 0. Las brechas en la numeración (0, 1, 3) o comenzar en 1 en lugar de 0 causarán fallos de análisis en implementaciones estrictas.
• Usar un juego de caracteres distinto de UTF-8. Aunque RFC 2231 permite cualquier juego de caracteres IANA, la práctica moderna es UTF-8 exclusivamente. Usar ISO-8859-1 o Windows-1252 reduce la interoperabilidad con destinatarios internacionales.
• No proporcionar un respaldo ASCII. Algunos clientes de correo más antiguos no soportan RFC 2231. Siempre incluye un parámetro filename plano con una aproximación ASCII junto al parámetro filename*.

Impacto en la Entregabilidad

• Visualización del nombre del archivo adjunto. La codificación incorrecta causa que los nombres de archivo de los adjuntos aparezcan como texto ilegible o signos de interrogación en el cliente de correo del destinatario. Esto es confuso e improfesional, aunque no afecta directamente si el mensaje se entrega.
• Disparadores de filtros de spam. Los parámetros MIME mal formados pueden disparar filtros de spam. Algunos filtros marcan mensajes con anomalías de codificación como sospechosos, ya que las campañas de malware a veces usan encabezados mal formados para explotar vulnerabilidades del analizador.
• Interoperabilidad entre clientes. El estado real del soporte RFC 2231 varía. Gmail, Apple Mail y Thunderbird lo manejan bien. Algunos clientes empresariales más antiguos no lo hacen. El enfoque más seguro es siempre incluir ambos parámetros filename (ASCII) y filename* (RFC 2231).
• Parámetros Content-Type también. Aunque filename es el caso de uso más visible, RFC 2231 también se aplica a parámetros Content-Type como name y charset, y a cualquier otro parámetro de encabezado MIME.

Related RFCs