Під час надсилання вмісту електронної пошти потрібно встановити заголовок "Кодування передачі вмісту". Я спостерігав багато заголовків електронних листів, які я отримував. Деякі електронні листи використовують "7 біт", а деякі використовують "8 біт".
Яка різниця між цими двома? Що рекомендується? Чи потрібне якесь спеціальне кодування для тіла електронної пошти, щоб встановити ці заголовки?
Відповіді:
Читання може бути дещо щільним, але розділ "Передача вмісту-кодування" RFC 1341 містить усі деталі:
http://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html
Ситуація як би погіршується. Ось мій підсумок:
SMTP, за визначенням (RFC 821), обмежує пошту до рядків 1000 символів по 7 біт кожен. Це означає, що жоден з байтів, який ви відправляєте по трубі, не може мати найбільш значущий біт ("найвищий порядок"), встановлений на "1".
Вміст, який ми хочемо надіслати, часто не відповідає цим обмеженням. Подумайте про файл зображення або текстовий файл, який містить символи Unicode: для байтів цих файлів часто для 8-го біта встановлено значення "1". SMTP не дозволяє цього, тому вам потрібно використовувати "кодування передачі", щоб описати, як ви працювали з невідповідністю.
Значення Content-Transfer-Encodingзаголовка описують правило, яке ви вибрали для вирішення цієї проблеми.
7bitпросто означає "Мої дані складаються лише з символів US-ASCII, які використовують лише нижчі 7 бітів для кожного символу". Ви в основному гарантуєте, що всі байти у вашому вмісті вже дотримуються обмежень SMTP, і тому він не потребує спеціального лікування. Ви можете просто прочитати його як є.
Зверніть увагу, що, коли ви вибираєте 7bit, ви погоджуєтесь, що всі рядки у вашому вмісті мають довжину менше 1000 символів.
Поки ваш вміст дотримується цих правил, 7bitце найкраще кодування передачі, оскільки не потрібна додаткова робота; ви просто читаєте / пишете байти, коли вони відриваються від труби. Також легко оглянути 7bitвміст і зрозуміти його. Ідея тут полягає в тому, що якщо ви просто пишете "простим англійським текстом", у вас все буде добре. Але це не було правдою в 2005 році і неправдою сьогодні.
8bitозначає "Мої дані можуть містити розширені символи ASCII; вони можуть використовувати 8-й (найвищий) біт для позначення спеціальних символів поза стандартними 7-бітовими символами US-ASCII". Як і у випадку 7bit, досі існує обмеження в 1000 символів.
8bit, так само 7bit, як насправді не робить жодного перетворення байтів, як вони записані в або прочитані з дроту. Це просто означає, що ви не гарантуєте, що жоден з байтів не матиме найвищого біта, встановленого на "1".
Це здається кроком уперед 7bit, оскільки це дає вам більше свободи у своєму вмісті. Однак RFC 1341 містить такий шматок:
На момент публікації цього документа не існує стандартизованих Інтернет-транспорту, для яких правомірно включати некодовані 8-бітові або двійкові дані до поштових тіл. Таким чином, немає обставин, за яких "8-бітове" або "двійкове" кодування передачі-кодування вмісту насправді є законним в Інтернеті.
RFC 1341 вийшов понад 20 років тому. З тих пір ми отримали 8-бітові розширення MIME у RFC 6152 . Але навіть тоді можуть застосовуватися обмеження рядків:
Зверніть увагу, що це розширення НЕ виключає можливості SMTP-сервера обмежувати довжину рядка; сервери можуть вільно реалізовувати це розширення, але тим не менше встановлюють обмеження довжини рядка не нижче 1000 октетів.
binaryце те саме 8bit, за винятком того, що немає обмеження довжини рядка. Ви все ще можете включати будь-які символи, які хочете, і немає додаткового кодування. Подібно до 8bit, RFC 1341 заявляє, що насправді це не є законним кодуванням передачі кодування. RFC 3030 продовжив це з BINARYMIME.
До 8BITMIMEрозширення повинен був існувати спосіб надсилання вмісту, який не міг бути 7bitчерез SMTP. Хорошими прикладами цього є файли HTML (які можуть мати більше 1000 символьних рядків) та файли з міжнародними символами. quoted-printableКодування (Визначено у розділі 5.1 RFC тисячі триста сорок одна) призначений для обробки цього. Це робить дві речі:
Для друку, що цитується, через загальні та короткі рядки люди набагато важче читати людині, ніж 7bitабо 8bit, але він підтримує набагато ширший діапазон можливого вмісту.
Якщо ваші дані в основному нетекстові (наприклад: файл зображення), у вас не так багато варіантів. 7bitє поза столом. 8bitі binaryне підтримувалися до RFC розширення MIME. quoted-printableбуде працювати, але насправді неефективно (кожен байт буде представлений 3 символами).
base64є хорошим рішенням для даних цього типу. Він кодує 3 необроблені байти як 4 символи US-ASCII, що є відносно ефективним. RFC 1341 додатково обмежує довжину рядка base64закодованих даних до 76 символів, щоб вміститися в SMTP-повідомлення, але цим порівняно легко керувати, коли ви просто розбиваєте або об'єднуєте довільні символи з фіксованою довжиною.
Великий мінус полягає в тому, що base64закодовані дані майже повністю не читаються людьми, навіть якщо це просто "звичайний" текст внизу.