stringtranslate.com

8-битный чистый

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

История

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

Двоичные файлы октетов не могут передаваться напрямую через 7-битные каналы данных. Чтобы обойти это, были разработаны двоично-текстовые кодировки , которые используют только 7-битные символы ASCII . Некоторые из этих кодировок — uuencoding , Ascii85 , SREC , BinHex , kermit и Base64 MIME . Системы на основе EBCDIC не могут обрабатывать все символы, используемые в UUencoded данных. Однако кодировка 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]

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

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

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

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

Смотрите также

Примечания

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

Ссылки

  1. ^ RFC  780: Приложение A, RFC  788: 4.5.2., RFC  821: Приложение B, RFC  1056: 4.
  2. ^ Джон Бек. «Объяснение электронной почты». 2011.
  3. ^ Джонатан Б. Постел (ноябрь 1981 г.). "4.5.3. РАЗМЕРЫ". ПРОСТОЙ ПРОТОКОЛ ПЕРЕДАЧИ ПОЧТЫ. doi : 10.17487/RFC0788 . RFC 788. Максимальная общая длина текстовой строки, включая <CRLF>, составляет 1000 символов (но не считая начальной точки, дублированной для прозрачности).
  4. ^ G. Vaudreuil (февраль 1993 г.). "2. Проблема". Переход интернет-почты с Just-Send-8 на 8bit-SMTP/MIME. doi : 10.17487/RFC1428 . RFC 1428. SMTP, как определено в RFC 821, ограничивает отправку интернет-почты символами US-ASCII.
  5. ^ Дэн Сугалски. «Электронная почта с вложениями». «The Perl Journal». Лето 1999 г. «Когда почта была стандартизирована в далеком 1982 г. с помощью RFC822, ... Единственными ограничениями, наложенными на тело сообщения, были набор символов (7-битный ASCII) и максимальная длина строки (1000 символов)».
  6. ^ ab N. Freed; N. Borenstein (ноябрь 1996 г.). "Abstract". Многоцелевые расширения интернет-почты (MIME). Часть первая: Формат тел интернет-сообщений. doi : 10.17487/RFC2045 . RFC 2045. Многоцелевые расширения интернет-почты, или MIME , переопределяют формат сообщений
  7. ^ C. Feather (октябрь 2006 г.). Протокол передачи сетевых новостей (NNTP). doi : 10.17487/RFC3977 . RFC 3977.
  8. ^ C. Lindsey; D. Kohn (ноябрь 2009 г.). K. Murchison (ред.). Формат статьи Netnews. doi : 10.17487/RFC5536 . RFC 5536.
  9. ^ К. Мур (ноябрь 1996 г.). MIME (многоцелевые расширения интернет-почты), часть третья: расширения заголовков сообщений для не-ASCII-текста. doi : 10.17487/RFC2047 . RFC 2047.
  10. ^ Н. Фрид; К. Мур (ноябрь 1997 г.). Значение параметра MIME и расширения закодированных слов: наборы символов, языки и продолжения. doi : 10.17487/RFC2231 . RFC 2231.
  11. ^ Теодор Цо ; Кит Мур ; Марк Криспин (12 сентября 1994 г.). "8-битная передача в NNTP". IETF -SMTP mail list . Архивировано из оригинала 20 марта 2012 г. Получено 3 апреля 2010 г.
  12. ^ "comp.mail.mime FAQ, часть 3 'Что такое ESMTP и как он влияет на MIME?'". Usenet FAQs . 8 августа 1997 г. Архивировано из оригинала 18 января 2012 г. Получено 3 апреля 2010 г.
  13. ^ J. Yao; W. Mao (февраль 2012 г.). Расширение SMTP для интернационализированной электронной почты. doi : 10.17487/RFC8531 . RFC 8531.
  14. ^ «Расширение 8BITMIME».