¿Me pregunto si se debería aplicar el ajuste de palabras en los correos electrónicos de texto? ¿Y qué hay de los correos electrónicos HTML? Si es así, ¿a qué personaje normalmente envolverías?¿Utiliza el ajuste de palabras en los correos electrónicos?
RFC 2646 dice:
El/Plain Tipo de medios de texto es el mínimo común denominador de correo electrónico de Internet, con las líneas de no más de 997 caracteres (por convención, por lo general no más de 80)
Otro estándar popular es envolver a 72 caracteres. Esto se remonta a muchas aplicaciones de consola (como EDIT y muchas interfaces BBS) que mostraban texto dentro de una "ventana" ASCII que incluía un borde y una barra de desplazamiento, permitiendo que se mostrara un poco menos de 80 caracteres.
acuerdo.Siempre cierro a los 80, y si eso me rompe una palabra, envolvería a menos de 80, donde quiera que el primer espacio o salto de línea sea anterior a ese octogésimo carácter. – hmcclungiii
Por lo general, debe ajustar a 80, o un poco menos, para permitir que los clientes débiles citen sin envolver.
No usé linewrap, hasta que cambié a mutt/xterm (sin mirar hacia atrás).
Ajustar en el primer carácter de espacio en blanco antes de la posición 72, o en la posición 72 si no hay uno. En Eudora, cuando solía usarlo, la convención era dejar un espacio al final de la línea que indicara que estaba envuelto, por lo que indicaría al cliente que lo recibe que redistribuya el párrafo donde lo necesite en función del ancho de la línea. ventana del cliente No estoy seguro de que este sea el caso en los clientes actuales de correo electrónico.
Creo que el carácter final (ya sea un espacio, un guión u otro tipo de puntuación que se pueda soltar) siempre debe dejarse. – Sparr
Es común envolver líneas en 72 (80 también es común, pero eso significa que pasará de 80 cuando se cotizan) para manejar al menos uno o dos niveles de oferta. Existe el tipo MIME "texto/flujo", lo que significa que el cliente ajustará el texto en sí mismo en los límites de la ventana, pero no que muchos clientes lo admitan. Simplemente configura tu editor para que se ajuste a 72 y estarás seguro y legible para la mayoría de las personas.
EDIT: el tipo exacto es text/plain con la adición de format=flowed así:
Content-Type: text/plain; format=flowed
Ver rfc2646 explicaciones.
Se debe evitar el correo HTML IMNSHO, no todo el mundo lee el correo en un navegador o tiene clientes de correo habilitados para HTML. La mayoría de las razones para usar HTML (enriquecer el correo con subrayado, negrita y similares) pueden emularse. HTML no necesita envolverse ya que el cliente se adaptará al tamaño de la ventana.
Una alternativa a HTML es el tipo MIME "text/enrived" que le brinda la mayoría de las ventajas de los correos HTML sin la molestia pero, una vez más, puede que no sea compatible en todas partes.
Ver here para texto/enriquecido.
Google dice Resultados 1 - 10 de aproximadamente ...
3,160 for +word +wrap +email +"80 characters"
2,820 for +word +wrap +email +"50 characters"
1,790 for +word +wrap +email +"60 characters"
1,720 for +word +wrap +email +"70 characters"
1,540 for +word +wrap +email +"100 characters"
1,250 for +word +wrap +email +"65 characters"
1,120 for +word +wrap +email +"40 characters"
962 for +word +wrap +email +"75 characters"
836 for +word +wrap +email +"72 characters"
a menudo me encuentro a partir de correo electrónico responde con:
[Format recovered--see http://www.lemis.com/grog/email/email-format.php]
la que obtuve de Greg Lehey.Parte de that page dice:
Claramente, debe haber alguna forma de especificar que el texto del mensaje no debe ser envuelto. Eso es texto/simple. Hay tipos especiales de archivos adjuntos MIME que permiten el ajuste, aunque sigo pensando que esta es una mala idea. Si especifica que su mensaje puede estar envuelto, está haciendo una suposición sobre cómo se ve la pantalla del receptor. Incluso si estás en lo cierto alguna vez, no puedes estar en lo correcto todo el tiempo. Por ejemplo, una persona puede tener una pantalla de 200 caracteres de ancho para poder mostrar entradas largas de archivos de registro, pero no querrá ver su texto tan largo.
Obteniendo 404 en http://www.lemis.com/email/email-format.html –
@JamesDaily gracias, ~ 2011 el antiguo enlace comenzó a redirigirse a un enlace * .php y en algún momento de los últimos seis meses que se detuvo. Para referencia futura, si el enlace de arriba se detiene aquí hay un [enlace de archive.org] (https://web.archive.org/web/20100402074443/http://www.lemis.com/email/email-format.html) . –
Una buena API de correo como JavaMail lo hará por usted. Idealmente, no tendría que pensar en este tema de forma explícita.
de acuerdo, y en todos los sitios más nuevos utilizo una biblioteca. Desafortunadamente en este sitio, es tan viejo que no lo hice y sería un pago agregar uno. –
http://tools.ietf.org/html/rfc5322#section-2.1.1
2.1.1. Longitud de la línea Límites
Hay dos límites que se enmarca esta especificación sobre el número de caracteres en una línea. Cada línea de caracteres DEBE ser no más de 998 caracteres, y DEBE tener no más de 78 caracteres, excluyendo el CRLF.
El límite de 998 caracteres se debe a las limitaciones en muchas implementaciones que envían, reciben o almacenan mensajes del FMI que simplemente no pueden manejar más de 998 caracteres en una línea. Las implementaciones de recepción serían que funcionan bien para manejar un número arbitrariamente grande de caracteres en una línea para mayor robustez. Sin embargo, hay tantas implementaciones que (de acuerdo con las necesidades de transporte de [RFC5321]) no aceptar mensajes que contienen más de 1000 caracteres incluyendo el CR y LF por línea, es importante para las implementaciones de no crear tales mensajes.
El más conservador 78 recomendación carácter es para acomodar las muchas implementaciones de interfaces de usuario que muestran estas mensajes que puede truncar o desastrosamente Wrap, la visualización de más de 78 caracteres por línea, a pesar del hecho de que tales implementaciones son no conforme a la intención de esta especificación (y la de [RFC5321] si realmente causan información que se perdió). De nuevo, aunque esta limitación se pone en los mensajes, corresponde a las implementaciones que muestran mensajes manejar un número arbitrariamente grande de caracteres en una línea (ciertamente al menos hasta el límite de 998 caracteres) por el bien de robustez .
Consulte también: RFC2045, RFC2046, RFC2047, RFC2049, RFC4289 RFC6838 & para las especificaciones MIME.
Es divertido leer RFCs. Usted sabe que el amor es :-)
buena respuesta está aquí: http://stackoverflow.com/questions/2696433/is-it-necessary-to-wrap-long-lines-when-sending-emails/2696542# 2696542 –
Ver también http://stackoverflow.com/questions/4297574/do-i-need-to-wrap-email-messages-longer-than-72-characters-in-a-line/4297689 –