Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

История [ править ]

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

Бинарные файлы из октетов не могут передаваться через 7-битовые каналы данных напрямую. Чтобы обойти это, было разработано кодирование двоичного кода в текст , в котором используются только 7-битные символы ASCII . Некоторые из этих кодировок UUencoding , ascii85 , SREC , BinHex , Кермит и 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]

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

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

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

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

См. Также [ править ]

  • 32-битный чистый
  • MIME § Content-Transfer-Encoding
  • Telnet § 8-битные данные

Ссылки [ править ]

  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. ^ Дэн Сугальский. «Электронная почта с вложениями» . "Журнал Perl". Лето 1999 года. «Когда еще в 1982 году почта была стандартизирована с RFC822, ... Единственными ограничениями, наложенными на тело, были набор символов (7-битный ASCII) и максимальная длина строки (1000 символов)».
  6. ^ a b Н. Фрид; Н. Боренштейн (ноябрь 1996 г.). "Абстрактный". Многоцелевые расширения почты Интернета (MIME). Часть первая: формат тел сообщений в Интернете . DOI : 10,17487 / RFC2045 . RFC 2045 . Многоцелевые расширения почты Интернета, или MIME , переопределяют формат сообщений.
  7. Перейти ↑ C. Feather (октябрь 2006 г.). Протокол передачи сетевых новостей (NNTP) . DOI : 10,17487 / RFC3977 . RFC 3977 .
  8. ^ К. Линдси; Д. Кон (ноябрь 2009 г.). К. Мерчисон (ред.). Формат статьи 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. ^ Теодор Ts'o ; Кейт Мур ; Марк Криспин (12 сентября 1994 г.). «8-битная передача в NNTP» . Список рассылки IETF- SMTP . Архивировано из оригинального 20 марта 2012 года . Проверено 3 апреля 2010 года .
  12. ^ "comp.mail.mime FAQ, часть 3 'Что такое ESMTP и как это влияет на MIME? ' " . Часто задаваемые вопросы по Usenet . 8 августа 1997 года Архивировано из оригинала 18 января 2012 года . Проверено 3 апреля 2010 года .
  13. ^ Дж. Яо; В. Мао (февраль 2012 г.). Расширение SMTP для интернационализированной электронной почты . DOI : 10,17487 / RFC8531 . RFC 8531 .
  14. ^ "Расширение 8BITMIME" .