email - sincronizados - ¿Utiliza el ajuste de palabras en los correos electrónicos?
plugin para personalizar correos woocommerce (9)
En general, debe ajustar a 80, o un poco menos, para permitir que los clientes débiles coticen sin envolver.
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?
Envuelve el primer carácter 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.
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"
RFC 2646 dice:
El tipo de medios Texto / Normal es el denominador común más bajo del correo electrónico de Internet, con líneas de no más de 997 caracteres (por convención generalmente 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.
Es común ajustar líneas a 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 cotización. 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 para explicaciones.
Se debe evitar el correo HTML IMNSHO, no todos leen el correo en un navegador o tienen 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 al HTML es el tipo MIME "enriquecido / en texto" que le brinda la mayoría de las ventajas de los correos HTML sin la molestia pero, una vez más, puede no ser compatible en todas partes.
Vea aquí para texto / enriquecido.
No usé linewrap, hasta que cambié a mutt / xterm (sin mirar hacia atrás).
Una buena API de correo como JavaMail lo hará por usted. Idealmente, no tendría que pensar en este tema de forma explícita.
RFC 5322
http://tools.ietf.org/html/rfc5322#section-2.1.1
2.1.1. Límites de longitud de línea
Hay dos límites que esta especificación establece en la cantidad de caracteres en una línea. Cada línea de caracteres DEBE tener no más de 998 caracteres, y DEBERÍA tener un máximo 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. Recibir implementaciones haría bien en manejar una cantidad arbitrariamente grande de caracteres en una línea para mayor robustez. Sin embargo, hay tantas implementaciones que (de acuerdo con los requisitos de transporte de [RFC5321]) no aceptan mensajes que contienen más de 1000 caracteres, incluidos CR y LF por línea, es importante que las implementaciones no creen dichos mensajes.
La recomendación más conservadora de 78 caracteres es acomodar las muchas implementaciones de interfaces de usuario que muestran estos mensajes que pueden truncar, o desastrosamente envolver, la visualización de más de 78 caracteres por línea, a pesar del hecho de que tales implementaciones no son conformes con la intención de esta especificación (y la de [RFC5321] si realmente hacen que se pierda información). De nuevo, aunque esta limitación se aplica a los mensajes, es obligatorio que las implementaciones muestren mensajes para manejar un número arbitrariamente grande de caracteres en una línea (ciertamente al menos hasta el límite de 998 caracteres) por razones de solidez.
Ver también: RFC2045, RFC2046, RFC2047, RFC2049, RFC4289 y RFC6838 para las especificaciones MIME.
Es divertido leer RFCs. Sabes que te encanta :-)
A menudo me encuentro comenzando a responder por correo electrónico con:
[Format recovered--see http://www.lemis.com/grog/email/email-format.php]
que recibí de Greg Lehey. Parte de esa página 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.