View source for 8-bit clean

{{Short description|Computer system that correctly handles 8-bit character encodings}}
{{More citations needed|date=June 2008}}

In [[computer network]]ing, a system is '''8-bit clean''' if it processes [[8-bit]] [[character encoding]]s without altering the [[high bit]] or treating any [[byte]] as an [[in-band]] control code. This property can describe both a [[communications protocol]] and the software and devices that implement such protocols. Although many early email systems only supported 7-bit data, the vast majority of modern email systems are 8-bit clean.

== History ==
Until the early 1990s, many programs and data transmission channels were [[character-oriented]] and treated some characters like [[end-of-text]] (ETX) as [[control character]]s. Others assumed a stream of seven-bit characters, with values between 0 and 127; for example, the [[ASCII]] standard used only seven bits per character, [[ASCII#Bit width|avoiding an eight-bit representation]] in order to save on data transmission costs. On computers and data links using [[8-bit byte]]s, this left the top [[bit]] of each byte free for use as a [[parity bit]], [[flag bit]], or metadata control bit. Seven-bit systems and data links are unable to directly handle more complex character codes which are commonplace in non-[[English language|English]]-speaking countries with larger [[alphabet]]s.

[[Binary file]]s consisting of 8-bit [[octet (computing)|octet]]s cannot be transmitted through 7-bit data channels directly. To work around this, [[binary-to-text encoding]]s have been devised which use only 7-bit [[ASCII]] characters. Some of these encodings are [[uuencoding]], [[Ascii85]], [[SREC (file format)|SREC]], [[BinHex]], [[kermit (protocol)|kermit]] and [[MIME]]'s [[Base64]]. [[EBCDIC]]-based systems cannot handle all characters used in UUencoded data.{{clarify|reason=Identify problematic characters and indicate whether the issue exists for code pages 037 and 1047.|post-text=(see [[Talk:8-bit clean#EBCDIC|talk]])|date=March 2025}} However, the base64 encoding does not have this problem.

== SMTP and NNTP ==
Historically, various media were used to transfer messages, some of which only supported 7-bit data, so an 8-bit message had high chances to be [[mojibake|garbled]] during transmission in the 20th century. Some implementations ignored the formal discouraging of 8-bit data and allowed bytes with the [[high bit]] set to pass through. Such implementations are said to be 8-bit clean. In general, a [[communications protocol]] is said to be 8-bit clean if it correctly passes through the high bit of each byte in the communication process.

Many early communications protocol standards, such as {{IETF RFC|780|788|821|2821|5321}} (for [[SMTP]]), {{IETF RFC|977}} (for [[NNTP]]) and {{IETF RFC|1056|leadout=and}}, were designed to work over such "7-bit" communication links. They specifically require the use of ASCII "transmitted as an 8-bit byte with the high-order bit cleared to zero", and some of these<ref>{{IETF RFC|780}}: Appendix&nbsp;A, {{IETF RFC|788}}: 4.5.2., {{IETF RFC|821}}: Appendix&nbsp;B, {{IETF RFC|1056}}: 4.</ref> explicitly restrict <em>all</em> data to 7-bit characters.

For the first few decades of email networks (1971 to the early 1990s), most email messages were [[plain text]] in the 7-bit US-ASCII character set.<ref> John Beck. [http://www.sendmail.com/sm/open_source/docs/email_explained/ "Email Explained"]. 2011.</ref>

The RFC 788 definition of SMTP, like its predecessor RFC 780, limits Internet Mail to lines (1000 characters or less) of 7-bit US-ASCII characters.<ref>{{cite RFC
 |         rfc = 788
 |       title = SIMPLE MAIL TRANSFER PROTOCOL
 | sectionname = 4.5.3. SIZES
 |       quote = The maximum total length of a text line including the <CRLF> is 1000 characters (but not counting the leading dot duplicated for transparency).
 |        date = November 1981
 |      author = Jonathan B. Postel
 }}
</ref><ref>{{cite RFC
 |         rfc = 1428
 |       title = Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME
 |      author = G. Vaudreuil
 |        date = February 1993
 | sectionname = 2. The Problem
 |       quote = SMTP as defined in RFC 821 limits the sending of Internet Mail to US-ASCII characters.
 }}
</ref><ref> Dan Sugalski. [http://www.foo.be/docs/tpj/issues/vol4_2/tpj0402-0010.html "E-mail with Attachments"]. "The Perl Journal". Summer 1999. "When mail was standardized way back in 1982 with RFC822, ... The only limits placed on the body were the character set (7-bit ASCII) and the maximum line length (1000 characters)."</ref><ref name="RFC2045" />

Later, the format of email messages was redefined in order to support messages that are not entirely US-ASCII text (text messages in character sets other than US-ASCII, and non-text messages, such as audio and images).<ref name="RFC2045">{{cite RFC
 |         rfc = 2045
 |       title = Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
 |     author1 = N. Freed
 |     author2 = N. Borenstein
 |        date = November 1996
 | sectionname = Abstract
 | quote = Multipurpose Internet Mail Extensions, or [[MIME]], redefines the format of messages
 }}
</ref> The header field Content-Transfer-Encoding=binary{{efn|The header field Content-Transfer-Encoding{{=}}8BIT does not designate 8-bit clean, since [[CRLF]] has special significance.}} requires an 8-bit clean transport.

RFC 3977<ref>{{cite IETF
 |     rfc = 3977
 |   title = Network News Transfer Protocol (NNTP)
 |    date = October 2006
 |  author = C. Feather
 }}
</ref> specifies that "NNTP operates over any reliable bi-directional 8-bit-wide data stream channel" and changes the character set for commands to [[UTF-8]]. However, RFC 5536<ref>{{cite IETF
 |     rfc = 5536
 |   title = Netnews Article Format
 |    date = November 2009
 | author1 = C. Lindsey
 | author2 = D. Kohn
 |  editor = K. Murchison
}}
</ref> still limits the character set to ASCII, including RFC 2047{{Ref RFC|2047}} and RFC 2231<ref>{{cite IETF 
 |     rfc = 2231
 |   title = MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations
 |    date = November 1997
 | author1 = N. Freed
 | author2 = K. Moore
}}
</ref> MIME encoding of non-ASCII data.

The Internet community generally adds features by ''extension'', allowing communication in both directions between upgraded machines and not-yet-upgraded machines, rather than declaring formerly standards-compliant legacy software to be broken and requiring that all software worldwide be upgraded to the latest standard. The recommended way to take advantage of 8-bit clean links between machines is to use the ESMTP ({{IETF RFC|1869}}) [[8BITMIME]] extension<ref>{{Cite web|url=http://www.imc.org/ietf-smtp/old-archive/msg02018.html|title=8-bit transmission in NNTP|author=Theodore Ts'o|author-link=Theodore Ts'o|author2=Keith Moore|author2-link=Keith Moore|author3=Mark Crispin|author3-link=Mark Crispin|work=[[IETF]]-SMTP mail list|date=12 September 1994|access-date=3 April 2010|archive-url=https://web.archive.org/web/20120320233721/http://www.imc.org/ietf-smtp/old-archive/msg02018.html|archive-date=20 March 2012|url-status=dead|df=dmy-all}}</ref><ref>{{Cite web|url=http://www.uni-giessen.de/faq/archiv/mail.mime-faq.part1-9/msg00002.html|title=comp.mail.mime FAQ, part 3 'What's ESMTP, and how does it affect MIME?'|work=[[Usenet]] FAQs|date=8 August 1997|access-date=3 April 2010|archive-url=https://web.archive.org/web/20120118070711/http://www.uni-giessen.de/faq/archiv/mail.mime-faq.part1-9/msg00002.html|archive-date=18 January 2012|url-status=dead|df=dmy-all}} </ref> for message bodies and the SMTP [[SMTPUTF8]]<ref>{{cite IETF|
 |     rfc = 8531
 |   title = SMTP Extension for Internationalized Email
 |    date = February 2012
 | author1 = J. Yao
 | author2 = W. Mao
}}
</ref> extension for message headers. Despite this, some [[mail transfer agent]]s, notably [[Exim]] and [[qmail]], relay mail to servers that do not advertise 8BITMIME without performing the conversion to 7-bit MIME (typically [[quoted-printable]], "Q-P conversion") required by {{IETF RFC|6152}}. This "just-send-8" attitude does not, in fact, cause problems in practice because virtually all modern email servers are 8-bit clean.<ref>{{cite web|url=http://cr.yp.to/smtp/8bitmime.html|title=The 8BITMIME extension}}</ref>

== See also ==
* [[32-bit clean]]
* {{slink|MIME|Content-Transfer-Encoding}}
* [[Telnet]]

== Notes ==
{{Notelist}}

== References ==
{{Reflist}}

[[Category:Character encoding]]