8-битная чистота

8-битная чистота — атрибут компьютерных систем , каналов связи и других устройств и программного обеспечения, которые обрабатывают 8-битные кодировки символов , не рассматривая ни один байт как внутриполосный управляющий код.

История

До начала 1990-х годов многие программы и каналы передачи данных были символьно-ориентированными и рассматривали некоторые символы, например ETX , как управляющие символы . Другие предполагали поток семибитных символов со значениями от 0 до 127; например, стандарт ASCII использовал только семь бит на символ, избегая 8-битного представления , чтобы сэкономить на затратах на передачу данных. На компьютерах и каналах передачи данных, использующих 8-битные байты, верхний бит каждого байта оставался свободным для использования в качестве бита четности , флага или бита управления метаданными. 7-битные системы и каналы передачи данных не могут напрямую обрабатывать более сложные коды символов, которые являются обычным явлением в неанглоязычных странах с более крупными алфавитами .

Двоичные файлы октетов не могут передаваться напрямую через 7-битные каналы данных. Чтобы обойти эту проблему, двоично-текстовые кодировки были разработаны , в которых используются только 7-битные символы ASCII . Некоторые из этих кодировок — uuencoding , Ascii85 , SREC , BinHex , kermit и MIME ’s Base64 . Системы на основе EBCDIC не могут обрабатывать все символы, используемые в данных в кодировке UU. Однако кодировка base64 не имеет этой проблемы.

SMTP и NNTP 8-битная чистота

Исторически для передачи сообщений использовались различные носители, некоторые из них поддерживали только 7-битные данные, поэтому 8-битное сообщение имело высокие шансы быть искаженным во время передачи в 20 веке. Но некоторые реализации действительно не заботились о формальном запрете 8-битных данных и позволяли проходить байтам, установленным старшими битами. Такие реализации называются 8-битными. В общем, протокол связи считается 8-битным, если он правильно пропускает старший бит каждого байта в процессе связи.

Многие ранние стандарты протоколов связи , такие как RFC 780 , 788 , 821 , 2821 , 5321 (для SMTP ), RFC 977 (для NNTP ) и RFC 1056 были разработаны для работы по таким «7-битным» каналам связи. В частности, они требуют использования набора символов ASCII, «передаваемого как 8-битный байт со старшим битом, очищенным до нуля», и некоторые из них ^[1] явно ограничить все данные 7-битными символами.

В течение первых нескольких десятилетий существования сетей электронной почты (с 1971 по начало 1990-х годов) большинство сообщений электронной почты представляли собой обычный текст в 7-битном наборе символов US-ASCII. ^[2]

The в RFC 788 , как и его предшественник. Определение SMTP RFC 780 ограничивает Интернет-почту строками (1000 символов или менее) из 7-битных символов US-ASCII. ^[3]^[4]^[5]^[6]

Позже формат сообщений электронной почты был переопределен для поддержки сообщений, которые не являются полностью текстовыми сообщениями US-ASCII (текстовые сообщения в наборах символов, отличных от US-ASCII, и нетекстовые сообщения, такие как аудио и изображения). ^[6] Поле заголовка Content-Transfer-Encoding=binary ^[а] требуется 8-битный чистый транспорт.

РФК 3977 ^[7] указывает: «NNTP работает по любому надежному двунаправленному каналу потока данных шириной 8 бит». и меняет набор символов для команд на UTF-8. Однако, RFC 5536 ^[8] по-прежнему ограничивает набор символов ASCII, включая РФК 2047 ^[9] и RFC 2231 ^[10] MIME-кодирование данных, отличных от ASCII.

Интернет-сообщество обычно добавляет функции путем расширения , обеспечивая связь в обоих направлениях между модернизированными и еще не обновленными машинами, вместо того, чтобы объявлять устаревшее программное обеспечение, ранее совместимое со стандартами, «сломанным» и настаивать на том, чтобы все программное обеспечение во всем мире было обновлено до последней версии. стандарт. В середине 1990-х годов люди ^{[ ВОЗ? ]} возражал против «просто отправить 8 бит (в RFC 821 SMTP-серверы)», возможно, из-за восприятия, что «просто отправьте 8 бит» — это неявное заявление о том, что ISO 8859-1 становится новой «стандартной кодировкой», заставляющей всех в мире использовать один и тот же набор символов . ^{[ оригинальное исследование? ]} Вместо этого рекомендуемый способ воспользоваться преимуществами 8-битных соединений между компьютерами — использовать ESMTP ( RFC 1869 ) 8BITMIME Расширение ^[11]^[12] для тел сообщений и SMTP SMTPUTF8 ^[13] расширение для заголовков сообщений. Несмотря на это, некоторые агенты передачи почты , особенно Exim и qmail , ретранслируют почту на серверы, которые не объявляют 8BITMIME, без выполнения преобразования в 7-битный MIME (обычно quote-printable , «преобразование QP»), требуемого РФК 6152 . Такое отношение «просто отправь-8» на самом деле не вызывает проблем на практике, поскольку практически все современные почтовые серверы являются 8-битными. ^[14]

См. также

Примечания

^ Поле заголовка Content-Transfer-Encoding=8BIT не обозначает 8-битную чистоту, поскольку CRLF имеет особое значение.

Ссылки

^ RFC 780 : Приложение А, RFC 788 : 4.5.2., RFC 821 : Приложение B, РФК 1056 : 4.
^ Джон Бек. «Объяснение электронной почты» . 2011.
^ Джонатан Б. Постел (ноябрь 1981 г.). «4.5.3. РАЗМЕРЫ». ПРОСТОЙ ПРОТОКОЛ ПЕРЕДАЧИ ПОЧТЫ . дои : 10.17487/RFC0788 . РФК 788 . Максимальная общая длина текстовой строки, включая <CRLF>, составляет 1000 символов (не считая начальной точки, дублированной для прозрачности).
^ Г. Водрей (февраль 1993 г.). «2. Проблема». Переход интернет-почты с Just-Send-8 на 8-битный SMTP/MIME . дои : 10.17487/RFC1428 . РФК 1428 . SMTP, как определено в RFC 821, ограничивает отправку Интернет-почты символами US-ASCII.
^ Дэн Сугальски. «Электронное письмо с вложениями» . «Журнал Перла». Лето 1999 года. «Когда в 1982 году почта была стандартизирована с помощью RFC822,… единственными ограничениями, налагаемыми на тело, были набор символов (7-битный ASCII) и максимальная длина строки (1000 символов)».
↑ Перейти обратно: Перейти обратно: ^а ^б Н. Фрид; Н. Боренштейн (ноябрь 1996 г.). "Абстрактный". Многоцелевые расширения почты Интернета (MIME). Часть первая: формат тел интернет-сообщений . дои : 10.17487/RFC2045 . РФК 2045 . Многоцелевые расширения почты Интернета, или MIME , переопределяют формат сообщений.
^ К. Перо (октябрь 2006 г.). Протокол передачи сетевых новостей (NNTP) . дои : 10.17487/RFC3977 . РФК 3977 .
^ К. Линдси; Д. Кон (ноябрь 2009 г.). К. Мерчисон (ред.). Формат статьи Netnews . дои : 10.17487/RFC5536 . РФК 5536 .
^ К. Мур (ноябрь 1996 г.). MIME (многоцелевые расширения почты Интернета), часть третья: расширения заголовков сообщений для текста, отличного от ASCII . дои : 10.17487/RFC2047 . РФК 2047 .
^ Н. Фрид; К. Мур (ноябрь 1997 г.). Значение параметра MIME и расширения закодированных слов: наборы символов, языки и продолжения . дои : 10.17487/RFC2231 . РФК 2231 .
^ Теодор Цо ; Кейт Мур ; Марк Криспин (12 сентября 1994 г.). «8-битная передача по NNTP» . IETF Список рассылки -SMTP . Архивировано из оригинала 20 марта 2012 года . Проверено 3 апреля 2010 г.
^ «Часто задаваемые вопросы по comp.mail.mime, часть 3. Что такое ESMTP и как он влияет на MIME?» " . по Usenet Часто задаваемые вопросы . 8 августа 1997 года. Архивировано из оригинала 18 января 2012 года . Проверено 3 апреля 2010 г.
^ Дж. Яо; В. Мао (февраль 2012 г.). Расширение SMTP для интернационализированной электронной почты . дои : 10.17487/RFC8531 . RFC 8531 .
^ «Расширение 8BITMIME» .

[7] Поле заголовка Content-Transfer-Encoding=8BIT не обозначает 8-битную чистоту, поскольку CRLF имеет особое значение.

[1] RFC 780 : Приложение А, RFC 788 : 4.5.2., RFC 821 : Приложение B, РФК 1056 : 4.

[2] Джон Бек. «Объяснение электронной почты» . 2011.

[3] Джонатан Б. Постел (ноябрь 1981 г.). «4.5.3. РАЗМЕРЫ». ПРОСТОЙ ПРОТОКОЛ ПЕРЕДАЧИ ПОЧТЫ . дои : 10.17487/RFC0788 . РФК 788 . Максимальная общая длина текстовой строки, включая <CRLF>, составляет 1000 символов (не считая начальной точки, дублированной для прозрачности).

[4] Г. Водрей (февраль 1993 г.). «2. Проблема». Переход интернет-почты с Just-Send-8 на 8-битный SMTP/MIME . дои : 10.17487/RFC1428 . РФК 1428 . SMTP, как определено в RFC 821, ограничивает отправку Интернет-почты символами US-ASCII.

[5] Дэн Сугальски. «Электронное письмо с вложениями» . «Журнал Перла». Лето 1999 года. «Когда в 1982 году почта была стандартизирована с помощью RFC822,… единственными ограничениями, налагаемыми на тело, были набор символов (7-битный ASCII) и максимальная длина строки (1000 символов)».

[RFC2045-6] Перейти обратно: Перейти обратно: ^а ^б Н. Фрид; Н. Боренштейн (ноябрь 1996 г.). "Абстрактный". Многоцелевые расширения почты Интернета (MIME). Часть первая: формат тел интернет-сообщений . дои : 10.17487/RFC2045 . РФК 2045 . Многоцелевые расширения почты Интернета, или MIME , переопределяют формат сообщений.

[8] К. Перо (октябрь 2006 г.). Протокол передачи сетевых новостей (NNTP) . дои : 10.17487/RFC3977 . РФК 3977 .

[9] К. Линдси; Д. Кон (ноябрь 2009 г.). К. Мерчисон (ред.). Формат статьи Netnews . дои : 10.17487/RFC5536 . РФК 5536 .

[10] К. Мур (ноябрь 1996 г.). MIME (многоцелевые расширения почты Интернета), часть третья: расширения заголовков сообщений для текста, отличного от ASCII . дои : 10.17487/RFC2047 . РФК 2047 .

[11] Н. Фрид; К. Мур (ноябрь 1997 г.). Значение параметра MIME и расширения закодированных слов: наборы символов, языки и продолжения . дои : 10.17487/RFC2231 . РФК 2231 .

[12] Теодор Цо ; Кейт Мур ; Марк Криспин (12 сентября 1994 г.). «8-битная передача по NNTP» . IETF Список рассылки -SMTP . Архивировано из оригинала 20 марта 2012 года . Проверено 3 апреля 2010 г.

[13] «Часто задаваемые вопросы по comp.mail.mime, часть 3. Что такое ESMTP и как он влияет на MIME?» " . по Usenet Часто задаваемые вопросы . 8 августа 1997 года. Архивировано из оригинала 18 января 2012 года . Проверено 3 апреля 2010 г.

[14] Дж. Яо; В. Мао (февраль 2012 г.). Расширение SMTP для интернационализированной электронной почты . дои : 10.17487/RFC8531 . RFC 8531 .

[15] «Расширение 8BITMIME» .

[1]

[2]

[3]

[4]

[5]

[6]

[а]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]