Trong khi gửi nội dung email, bạn phải đặt tiêu đề "Mã hóa chuyển nội dung". Tôi đã quan sát nhiều tiêu đề email mà tôi nhận được. Một số email sử dụng "7bit" và một số đang sử dụng "8bit".
sự khác biệt giữa hai cái đó là gì? Cái nào được khuyến khích? Có cần mã hóa đặc biệt nào cho nội dung email để đặt các tiêu đề này không?
Câu trả lời:
Nó có thể hơi dày đặc để đọc, nhưng phần "Nội dung-Chuyển-Mã hoá" của RFC 1341 có tất cả các chi tiết:
http://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html
Tình hình ngày càng tồi tệ hơn. Đây là bản tóm tắt của tôi:
SMTP, theo định nghĩa (RFC 821), giới hạn thư trong các dòng 1000 ký tự, mỗi dòng 7 bit. Điều đó có nghĩa là không có byte nào bạn gửi xuống đường ống có thể có bit quan trọng nhất ("bậc cao nhất") được đặt thành "1".
Nội dung mà chúng tôi muốn gửi thường sẽ không tuân theo hạn chế này vốn có. Hãy nghĩ về một tệp hình ảnh hoặc tệp văn bản có chứa các ký tự Unicode: các byte của các tệp này thường sẽ có bit thứ 8 của chúng được đặt thành "1". SMTP không cho phép điều này, vì vậy bạn cần sử dụng "mã hóa truyền" để mô tả cách bạn đã làm việc xung quanh sự không khớp.
Các giá trị cho Content-Transfer-Encodingtiêu đề mô tả quy tắc bạn đã chọn để giải quyết vấn đề này.
7bitchỉ đơn giản có nghĩa là "Dữ liệu của tôi chỉ bao gồm các ký tự US-ASCII, chỉ sử dụng 7 bit thấp hơn cho mỗi ký tự." Về cơ bản, bạn đang đảm bảo rằng tất cả các byte trong nội dung của bạn đã tuân thủ các hạn chế của SMTP và vì vậy nó không cần phải xử lý đặc biệt. Bạn chỉ có thể đọc nó như hiện tại.
Lưu ý rằng khi bạn chọn 7bit, bạn đồng ý rằng tất cả các dòng trong nội dung của bạn có độ dài dưới 1000 ký tự.
Miễn là nội dung của bạn tuân thủ các quy tắc này, 7bitlà cách mã hóa chuyển giao tốt nhất, vì không cần thực hiện thêm công việc nào; bạn chỉ đọc / ghi các byte khi chúng thoát ra khỏi đường ống. Cũng dễ hiểu 7bitnội dung và ý nghĩa của nó. Ý tưởng ở đây là nếu bạn chỉ viết bằng "văn bản tiếng Anh đơn giản" thì bạn sẽ ổn. Nhưng điều đó không đúng vào năm 2005 và ngày nay nó không đúng.
8bitcó nghĩa là "Dữ liệu của tôi có thể bao gồm các ký tự ASCII mở rộng; chúng có thể sử dụng bit thứ 8 (cao nhất) để biểu thị các ký tự đặc biệt bên ngoài các ký tự 7 bit US-ASCII tiêu chuẩn." Tương tự như vậy 7bit, vẫn có giới hạn dòng 1000 ký tự.
8bit, giống như 7bit, không thực sự thực hiện bất kỳ chuyển đổi nào của các byte khi chúng được ghi vào hoặc đọc từ dây. Nó chỉ có nghĩa là bạn không đảm bảo rằng không có byte nào sẽ có bit cao nhất được đặt thành "1".
Điều này có vẻ như là một bước tiến 7bit, vì nó cho phép bạn tự do hơn trong nội dung của mình. Tuy nhiên, RFC 1341 chứa đoạn mã này:
Kể từ khi xuất bản tài liệu này, không có phương tiện truyền tải Internet tiêu chuẩn nào mà việc đưa dữ liệu 8-bit hoặc nhị phân chưa được mã hóa vào nội dung thư là hợp pháp. Do đó, không có trường hợp nào mà Mã hóa-Truyền-Nội dung "8bit" hoặc "nhị phân" thực sự hợp pháp trên Internet.
RFC 1341 đã ra mắt hơn 20 năm trước. Kể từ đó, chúng tôi đã nhận được Tiện ích mở rộng MIME 8bit trong RFC 6152 . Nhưng ngay cả khi đó, giới hạn dòng vẫn có thể áp dụng:
Lưu ý rằng phần mở rộng này KHÔNG loại trừ khả năng máy chủ SMTP giới hạn độ dài dòng; máy chủ được miễn phí triển khai phần mở rộng này nhưng tuy nhiên, hãy đặt giới hạn độ dài dòng không thấp hơn 1000 octet.
binarycũng giống như 8bit, ngoại trừ việc không có giới hạn độ dài dòng. Bạn vẫn có thể bao gồm bất kỳ ký tự nào bạn muốn và không cần mã hóa thêm. Tương tự như 8bit, RFC 1341 nói rằng nó không thực sự là một mã hóa truyền mã hóa hợp pháp. RFC 3030 đã mở rộng điều này với BINARYMIME.
Trước 8BITMIMEtiện ích mở rộng, cần có một cách để gửi nội dung không thể 7bitqua SMTP. Tệp HTML (có thể có hơn 1000 dòng ký tự) và tệp có ký tự quốc tế là những ví dụ điển hình về điều này. Các quoted-printablemã hóa (quy định tại mục 5.1 của RFC 1341) được thiết kế để xử lý việc này. Nó thực hiện hai điều:
Trích dẫn Có thể in, vì các dòng thoát và ngắn, con người khó đọc hơn nhiều so với 7bithoặc 8bit, nhưng nó hỗ trợ nhiều loại nội dung có thể hơn.
Nếu dữ liệu của bạn phần lớn không phải là văn bản (ví dụ: tệp hình ảnh), bạn không có nhiều tùy chọn. 7bitlà khỏi bàn. 8bitvà binarykhông được hỗ trợ trước RFC phần mở rộng MIME. quoted-printablesẽ hoạt động, nhưng thực sự không hiệu quả (mỗi byte sẽ được biểu diễn bằng 3 ký tự).
base64là một giải pháp tốt cho loại dữ liệu này. Nó mã hóa 3 byte thô thành 4 ký tự US-ASCII, tương đối hiệu quả. RFC 1341 còn giới hạn độ dài dòng của base64dữ liệu-mã hóa là 76 ký tự để vừa với một thông báo SMTP, nhưng điều đó tương đối dễ quản lý khi bạn chỉ cần tách hoặc nối các ký tự tùy ý ở độ dài cố định.
Nhược điểm lớn là base64dữ liệu-mã hóa hầu như không thể đọc được bởi con người, ngay cả khi nó chỉ là văn bản "đơn giản" bên dưới.