8비트 클린

8-bit clean

8비트 클린은 8비트 문자 인코딩을 올바르게 처리하는 컴퓨터 시스템, 통신 채널 및 기타 장치 및 소프트웨어의 속성입니다.이러한 부호화에는 ISO 8859 시리즈와 Unicode의 UTF-8 부호화가 포함됩니다.

역사

1990년대 초반까지 많은 프로그램과 데이터 전송 채널은 문자 지향적이었으며 ETX와 같은 일부 문자를 제어 문자로 취급했다.그 외는 7비트 문자의 스트림을 상정하고 있으며 값은 0~127입니다.예를 들어 ASCII 표준에서는 데이터 전송 비용을 절약하기 위해 문자당7비트밖에 사용하지 않았습니다.8비트 바이트를 사용하는 컴퓨터와 데이터 링크에서는 각 바이트의 최상위 비트가 패리티, 플래그 비트 또는 메타 데이터 제어 비트로 사용 가능하게 되었습니다. 7비트 시스템과 데이터 링크는 영어 이외의 국가에서 일반적으로 사용되는 보다 복잡한 문자 코드를 직접 처리할 수 없습니다.

옥텟의 바이너리 파일은 7비트 데이터 채널을 통해 직접 전송할 수 없습니다.이 문제를 해결하기 위해 7비트 ASCII 문자만 사용하는 바이너리-to-text 인코딩이 고안되었습니다.이러한 인코딩에는 uuencoding, ASCII85, SREC, BinHex, kermit 및 MIME의 Base64 등이 있습니다.EBCDIC 기반 시스템은 UU 인코딩된 데이터에 사용되는 모든 문자를 처리할 수 없습니다.단, base64 부호화에서는 이 문제가 발생하지 않습니다.

SMTP 및 NNTP 8비트 클린

지금까지 메시지 전송에는 다양한 미디어가 사용되었으며, 그 중 일부는 7비트 데이터만 지원했기 때문에 20세기에는 8비트 메시지가 전송 중에 왜곡될 가능성이 높았습니다.그러나 일부 구현에서는 실제로 8비트 데이터의 공식적인 저하에 개의치 않고 높은 비트 설정 바이트를 통과시킵니다.이러한 실장은 8비트 클린이라고 불립니다.일반적으로 통신프로토콜은 통신프로세스에서 각 바이트의 높은 비트를 올바르게 통과하면 8비트가 깨끗하다고 한다.

다음과 같은 많은 초기 통신 프로토콜 표준 RFC780, 788, 821, 2821, 5321(SMTP용), RFC977(NNTP용) 및 RFC1056은 이러한 '7비트' 통신 링크 상에서 동작하도록 설계되어 있습니다.특히 ASCII 문자 세트 "상위 비트가 0으로 클리어된 상태에서 8비트 바이트로 전송"을 사용해야 하며, 이들 중 일부는[1] 모든 데이터를 7비트 문자로 명시적으로 제한합니다.

전자 메일 네트워크의 처음 수십 년(1971~1990년대 초반) 동안 대부분의 전자 메일 메시지는 7비트 US-ASCII 문자 [2]집합의 일반 텍스트였습니다.

SMTP의 RFC 788 정의에서는 이전 RFC 780과 마찬가지로 인터넷 메일은 7비트 US-ASCII [3][4][5][6]문자의 행(1000자 이하)으로 제한됩니다.

이후 완전히 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비트만 전송(RFC 821 SMTP 서버에)"하는 것에 반대했는데[who?], 아마도 "8비트만 전송(just send 8bits)"이 ISO 8859-1이 새로운 "표준 부호화(standard encoding)"가 된다는 암묵적인 선언이고, 전 세계 모든 사람이 동일한 문자 [original research?]집합을 사용하도록 강요했기 때문일 것입니다.대신 머신 간에8비트 클린링크를 이용하는 권장 방법은 메시지 본문에 ESMTP(RFC 1869) 8BITMIME 확장자를[11][12] 사용하고 메시지 헤더에 SMTP SMTPUTF8[13] 확장자를 사용하는 것입니다.그럼에도 불구하고 일부 메일 전송 에이전트(특히 Exim 및 qmail)는 RFC 6152가 요구하는7비트 MIME(일반적으로 따옴표 첨부-인쇄 가능, Q-P 변환)로 변환하지 않고 8BITMIME을 애드버타이즈하지 않는 서버에 메일을 릴레이합니다.이러한 "just-send-8" 자세는 실제로 문제를 일으키지 않습니다. 왜냐하면 거의 모든 최신 이메일 서버는 8비트 [14]클린 상태이기 때문입니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ RFC 780: 부록 A, RFC 788: 4.5.2, RFC 821: 부록 B, RFC 1056: 4.
  2. ^ 존 벡."이메일 설명", 2011.
  3. ^ Jonathan B. Postel (November 1981). "4.5.3. SIZES". SIMPLE MAIL TRANSFER PROTOCOL. doi:10.17487/RFC0788. RFC 788. The maximum total length of a text line including the <CRLF> is 1000 characters (but not counting the leading dot duplicated for transparency).
  4. ^ G. Vaudreuil (February 1993). "2. The Problem". Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME. doi:10.17487/RFC1428. RFC 1428. SMTP as defined in RFC 821 limits the sending of Internet Mail to US-ASCII characters.
  5. ^ 댄 수갈스키."첨부 파일 첨부 이메일""Perl 저널"1999년 여름.메일은 1982년 RFC822에 의해 표준화되었을 때...본문의 제한은 문자 세트(7비트 ASCII)와 최대 행 길이(1000자)뿐입니다.
  6. ^ a b N. Freed; N. Borenstein (November 1996). "Abstract". Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. doi:10.17487/RFC2045. RFC 2045. Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages
  7. ^ C. Feather (October 2006). Network News Transfer Protocol (NNTP). doi:10.17487/RFC3977. RFC 3977.
  8. ^ C. Lindsey; D. Kohn (November 2009). K. Murchison (ed.). Netnews Article Format. doi:10.17487/RFC5536. RFC 5536.
  9. ^ K. Moore (November 1996). MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text. doi:10.17487/RFC2047. RFC 2047.
  10. ^ N. Freed; K. Moore (November 1997). MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations. doi:10.17487/RFC2231. RFC 2231.
  11. ^ Theodore Ts'o; Keith Moore; Mark Crispin (12 September 1994). "8-bit transmission in NNTP". IETF-SMTP mail list. Archived from the original on 20 March 2012. Retrieved 3 April 2010.
  12. ^ "comp.mail.mime FAQ, part 3 'What's ESMTP, and how does it affect MIME?'". Usenet FAQs. 8 August 1997. Archived from the original on 18 January 2012. Retrieved 3 April 2010.
  13. ^ J. Yao; W. Mao (February 2012). SMTP Extension for Internationalized Email. doi:10.17487/RFC8531. RFC 8531.
  14. ^ "The 8BITMIME extension".