¿Cuántos caracteres están permitidos en el asunto del correo electrónico de Internet? Tuve un escaneo de The RFC for email pero no pude ver específicamente cuánto tiempo estuvo permitido. Tengo un colega que quiere validarlo programáticamente.¿Cuál es el límite de longitud del tema del correo electrónico?
Si no hay un límite formal, ¿cuál es una buena duración en la práctica para sugerir? Cheers,
Consulte RFC 2822, sección 2.1.1 para comenzar.
Hay dos límites que esta lugares estándar sobre el número de caracteres en una línea. Cada línea de caracteres DEBE tener no más de 998 caracteres, y DEBE ser no más de 78 caracteres, excluyendo el CRLF.
Como afirma el RFC más adelante, puede trabajar alrededor de este límite (no debería hacerlo) doblando el sujeto en varias líneas.
campo Cada cabecera es lógicamente una sola línea de caracteres comprenden el nombre del campo, el colon, y el cuerpo campo . Sin embargo, para su comodidad, y para tratar con las limitaciones de 998/78 caracteres por línea, la parte del cuerpo de campo parte de un campo de encabezado se puede dividir en en una representación de varias líneas; esto se llama "plegado". La regla general es que siempre que este estándar permita doblar el espacio en blanco (no simplemente caracteres WSP), un CRLF puede ser insertado antes de cualquier WSP. Para ejemplo, el campo de cabecera:
Subject: This is a testse puede representar como:
Subject: This is a test
La recomendación para no más de 78 caracteres en la cabecera del asunto suena razonable. Nadie quiere desplazarse para ver toda la línea de asunto, y algo importante puede cortarse a la derecha.
La versión actual de la especificación del FMI, RFC 5322, se puede encontrar aquí: http://tools.ietf.org/html/rfc5322#section-2.1.1 –
Actualización aleatoria ...gmail auto-wraps en función del ancho de la pantalla y el espacio disponible. (no 78 caracteres) – CasualT
Esta respuesta solo aborda el límite de longitud de línea, no el límite de longitud total. – Chalky
No creo que haya un límite formal aquí, y estoy bastante seguro de que tampoco hay ningún límite estricto especificado en la RFC, como descubriste.
creo que algunas limitaciones bastante comunes para las líneas de asunto en general (no sólo correo electrónico) son:
Obviamente , quieres encontrar algo que sea razonable. Si está escribiendo un cliente de correo electrónico, es posible que desee usar 256 caracteres, y obviamente, realice pruebas exhaustivas en servidores comerciales grandes para asegurarse de que publican correctamente su correo.
Espero que esto ayude!
No hay una razón en particular por la que 256 sea mejor que 250, o 300, o 372. Hace mucho que usamos bytes para la cadena longitudes. –
Estoy de acuerdo con usted para fines prácticos, pero creo que 256 es mejor que algunas de las otras opciones que mencionó, ya que es más consistente con otros productos. –
255 es el límite real en algunos productos (Jira y Outlook, por ejemplo) – reconbot
después de algunas pruebas: si envía un correo electrónico a un cliente Outlook, y el tema es> 77 caracteres, y necesita usar "=?ISO" dentro del asunto (en mi caso debido a acentos), entonces OutLook "cortará" el sujeto en el medio y engrane todo lo que viene después, incluido el texto del cuerpo, los archivos adjuntos, etc. ¡toda una malla!
Tengo varios ejemplos como éste:
Subject: =?ISO-8859-1?Q?Actas de la obra N=BA.20100154 (Expediente N=BA.20100182) "NUEVA RED FERROVIARIA.=
TRAMO=20BEASAIN=20OESTE(Pedido=20PC10/00123-125),=20BEASAIN".?=
Para:
Como se ve, en la línea de asunto que cutted en carbón 78 con un "=" seguido de 2 ó 3 líneas de avance , luego continuó con el resto del tema mal.
Me lo informaron varios clientes que usaban OutLook, otros clientes de correo electrónico se ocupan de esos temas.
Si no tiene ISO, no duele, pero si lo agrega a su sujeto para ser amable con RFC, obtiene esta sorpresa de OutLook. Poco si no agrega los ISO, entonces el correo electrónico de iPhone no lo entenderá (y adjuntar archivos con nombres usando dichos caracteres no funcionará en iPhones).
Hay muchos problemas con el tema que configura: 1. Los espacios deben codificarse con '_', 2. Una 'palabra codificada' (=? Juego de caracteres? Q/B? Data? =) No puede tener más de 75 caracteres de largo (rfc2047). 3. ° No puede escapar de la nueva línea con '=' char al final de la línea (la codificación QP del encabezado es diferente de la del cuerpo QP). La conclusión es: no es culpa de Outlook. –
RFC2322 establece que el tema de cabecera "no tiene ninguna restricción de longitud"
sino producir cabeceras largas pero hay que dividirlo en varias líneas, un proceso llamado "plegable".
sujeto se define como "desestructurado" en el RFC 5322
aquí es algunas citas ([...] indicar cosas omití)
3.6.5. Informational Fields
The informational fields are all optional. The "Subject:" and
"Comments:" fields are unstructured fields as defined in section
2.2.1, [...]
2.2.1. Unstructured Header Field Bodies
Some field bodies in this specification are defined simply as
"unstructured" (which is specified in section 3.2.5 as any printable
US-ASCII characters plus white space characters) with no further
restrictions. These are referred to as unstructured field bodies.
Semantically, unstructured field bodies are simply to be treated as a
single line of characters with no further processing (except for
"folding" and "unfolding" as described in section 2.2.3).
2.2.3 [...] An unfolded header field has no length restriction and
therefore may be indeterminately long.
255 es el límite en algunos productos de venta de entradas (por ejemplo Jira) y parece ser el límite en Outlook, Thunderbird y Gmail parecen truncar después de 130. – reconbot
RFC2047 es más adecuado para la validación, veo un montón de software de envío masivo de correo que produce contenido no válido RFC2047. – Jasen
En las bases de datos es muy común (una tradición que pueda decir) definir la longitud de los campos de texto no especialmente largos o cortos como VARCHAR (255) o nombres equivalentes similares. Si se presenta una cadena más larga, generará un error o simplemente se truncará al límite. Es por eso que Jira y Outlook como se menciona aquí no admiten más caracteres. Por razones de compatibilidad, no recomendaría 255+ Agregando un poco de crema en el pastel de 5 años;) –