Bạn có sử dụng gói chữ trong email không?

Question

Tôi tự hỏi nếu gói từ nên được áp dụng trong các email văn bản? Còn email HTML thì sao? Nếu vậy, nhân vật nào bạn thường quấn vào?

Answer 1

RFC 2646 nói:

Các text/plain phương tiện truyền thông loại là mẫu số chung nhỏ nhất của email Internet, với những đường nét không quá 997 ký tự (theo quy ước thông thường không quá 80)

Một tiêu chuẩn phổ biến khác là bọc ở 72 ký tự. Ngày này trở lại nhiều ứng dụng giao diện điều khiển (như EDIT và nhiều giao diện BBS) hiển thị văn bản trong một cửa sổ "ASCII" bao gồm đường viền và thanh cuộn, cho phép hiển thị dưới 80 ký tự.

Answer 2

Thông thường bạn nên quấn ở mức 80 hoặc thấp hơn một chút để cho phép khách hàng mờ trích dẫn mà không cần gói.

Answer 3

Không sử dụng linewrap, cho đến khi tôi chuyển sang mutt/xterm (không bao giờ nhìn lại).

Answer 4

Đưa vào ký tự khoảng trống đầu tiên trước vị trí 72 hoặc ở vị trí 72 nếu không có vị trí. Trong Eudora khi tôi sử dụng nó, quy ước là để lại một khoảng trống ở cuối dòng chỉ ra rằng nó được bao bọc, vì vậy nó sẽ báo hiệu cho máy khách tiếp nhận lại luồng bất cứ khi nào nó cần dựa trên chiều rộng của cửa sổ của khách hàng. Tôi không chắc chắn rằng đây là trường hợp trong các ứng dụng email hiện tại.

Answer 5

Thông thường, việc quấn các đường ở 72 (80 cũng phổ biến nhưng điều đó có nghĩa là nó sẽ vượt quá 80 khi được trích dẫn) để xử lý ít nhất một hoặc hai mức báo giá. Có kiểu MIME "text/flowed" có nghĩa là máy khách sẽ tự bọc văn bản ở các ranh giới của cửa sổ nhưng không phải là nhiều máy khách hỗ trợ nó. Chỉ cần thiết lập trình soạn thảo của bạn để bọc ở 72 và bạn sẽ được an toàn và dễ đọc bởi hầu hết mọi người.

EDIT: loại chính xác là text/plain với việc bổ sung format=flowed như thế này:

Content-Type: text/plain; format=flowed 

Xem rfc2646 cho lời giải thích.

Cần tránh thư HTML IMNSHO, không phải ai cũng đọc thư trong trình duyệt hoặc có ứng dụng thư hỗ trợ HTML. Hầu hết các lý do để sử dụng HTML (làm giàu thư với gạch dưới, đậm và như vậy) có thể được mô phỏng. HTML không cần phải được bao bọc vì máy khách sẽ thích ứng với kích thước cửa sổ.

Một thay thế cho HTML là loại MIME "văn bản/làm phong phú" cung cấp cho bạn hầu hết các ưu điểm của thư HTML với những rắc rối nhưng một lần nữa, có thể không được hỗ trợ ở mọi nơi.

Xem here cho văn bản/làm giàu.

Answer 6

Google cho biết kết quả từ 1 - 10 trong khoảng ...

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" 

Answer 7

Tôi thường thấy mình bắt đầu e-mail trả lời với:

[Format recovered--see http://www.lemis.com/grog/email/email-format.php] 

mà tôi nhận được từ Greg Lehey.Một phần của that page nói:

Rõ ràng, phải có một số cách xác định rằng văn bản tin nhắn không nên được bao bọc. Đó là văn bản/đồng bằng. Có các loại tệp đính kèm MIME đặc biệt cho phép gói, mặc dù tôi vẫn nghĩ rằng đây là một ý tưởng tồi. Nếu bạn chỉ định rằng tin nhắn của bạn có thể được bao bọc, bạn đang giả định về màn hình của người nhận. Ngay cả khi bạn đã đúng, bạn không thể luôn luôn đúng. Ví dụ, một người có thể có một màn hình rộng 200 ký tự để có thể hiển thị các mục nhập tệp nhật ký dài, nhưng anh ta sẽ không muốn xem văn bản của mình dài.

Answer 8

API thư tốt như JavaMail sẽ thực hiện việc này cho bạn. Lý tưởng nhất, bạn sẽ không phải suy nghĩ về vấn đề này một cách rõ ràng.

Answer 9

RFC 5322

http://tools.ietf.org/html/rfc5322#section-2.1.1

2.1.1. Giới hạn độ dài dòng

Có hai giới hạn mà đặc điểm kỹ thuật này đặt vào số lượng ký tự trong một dòng. Mỗi dòng ký tự PHẢI không được nhiều hơn 998 ký tự và KHÔNG được nhiều hơn 78 ký tự, ngoại trừ CRLF.

Giới hạn ký tự 998 là do giới hạn trong nhiều lần triển khai gửi, nhận hoặc lưu trữ tin nhắn IMF mà không thể xử lý hơn 998 ký tự trên một dòng. Việc triển khai sẽ thực hiện làm tốt để xử lý một số lượng lớn các ký tự tùy ý trong một dòng vì mục đích mạnh mẽ. Tuy nhiên, có quá nhiều triển khai mà (tuân thủ các yêu cầu vận chuyển của [RFC5321]) không chấp nhận thư chứa hơn 1000 ký tự bao gồm CR và LF trên mỗi dòng, điều quan trọng là triển khai không được tạo tin nhắn.

Các dè dặt hơn 78 nhân vật đề nghị là để phù hợp nhiều hiện thực của giao diện người dùng hiển thị những thông điệp mà có thể cắt xén, hoặc disastrously quấn, màn hình hiển thị của hơn 78 ký tự trên mỗi dòng, mặc dù thực tế là việc triển khai như vậy không tuân thủ mục đích của thông số này (và của [RFC5321] nếu chúng thực sự làm mất thông tin ). Một lần nữa, mặc dù giới hạn này được đặt trên tin nhắn, nó là đương nhiệm khi triển khai hiển thị tin nhắn để xử lý một số lượng lớn các ký tự tùy ý trong dòng (chắc chắn ít nhất là giới hạn ký tự 998) vì lợi ích .

Xem thêm: RFC2045, RFC2046, RFC2047, RFC2049, RFC4289 & RFC6838 cho thông số kỹ thuật MIME.

Thật thú vị khi đọc RFC. Bạn biết bạn yêu thích nó :-)