8-bit clean describes computer systems that handle true 8-bit character encodings, such as ISO 8859 series and UTF-8 Unicode encoding.
Video 8-bit clean
History
Until the early 1990s, many programs and data transmission channels assumed that all characters would be represented as numbers between 0 and 127 (7 bits); for example, ASCII standards only use 7 bits per character, avoid 8-bit representation to save data transmission costs. On computers and data links using 8-bit bytes, this leaves the top bits of each free byte for use as parity, flag bits, or meta data control bits. The 7-bit system and data link can not handle more complex character codes that are common in non-English speaking countries.
Binary files can not be transmitted over a 7-bit data channel directly. To overcome this, a binary-to-text encoding has been created that uses only 7-bit ASCII characters. Some of these encodings are uuencoding, Ascii85, SREC, BinHex, kermit and Base64 MIME. The EBCDIC-based system can not handle all characters used in UUencoded data. However, the base64 encoding does not have this problem.
Maps 8-bit clean
SMTP and NNTP 8-bit cleanliness
Historically, various media were used to transfer messages, some of them only supporting 7-bit data, so 8-bit messages have a high chance of being twisted during transmission in the 20th century. But some implementations really do not care about formal termination of 8-bit data and allow bit sets of high bits to be skipped.
Many standard initial communication protocols, such as RFC 780, RFC 788, RFC 821 for SMTP, RFC 977 for NNTP, RFC 1056, RFC 2821, RFC 5321, are designed to work on these "7-bit" communication connections. They specifically mention the use of ASCII character sets "transmitted as 8-bit bytes with high-level bits being deleted to zero" and some of these explicitly limit all data to 7-bit characters.
During the first few decades of email networks (1971 to early 1990s), most email messages were plain text in 7-bit US-AS character sets.
According to RFC 1428, the original definition of RFC 821 concerns the limits of SMTP Internet Mail to lines (1000 characters or less) of 7-bit US-ASCII characters.
Then the email message format is redefined to support messages that are not fully US-ASCII text (text messages in sequences of characters other than AS-ASCII, and non-text messages, such as audio and images).
The Internet community generally adds features with "extensions", enabling communications in both directions between upgraded machines and non-upgraded machines, rather than declaring inherited standard software "broken" and insisting that all software around the world is upgraded to the latest standards. In the mid-1990s, people objected "to only send 8 bits (to the RFC 821 SMTP server)", probably because the perception that "just sending 8 bits" is an implicit statement that ISO 8859-1 becomes "new standard encoding" forcing everyone in the world to use the same set of characters Instead, the recommended way to take advantage of 8-bit-clean links between machines is to use the ESMTP (RFCÃ1869) 8BITMIME extension, however some Letter Transfer Agents, notably Exim and qmail, relaying emails to servers that do not advertise 8BITMIME without converting to 7-bit MIME (usually quoted-printing, "QP conversion") required by RFC 6152. This "only -send-8" in fact does not pose a problem in practice, as almost all modern 8-bit net email servers.
See also
- MIME # Content-Transfer-Encoding
- Telnet # 8-bit data
- net 32-bit
References
This article is based on material extracted from Free On-line Computing Dictionary before November 1, 2008 and entered under "license" terms of GFDL, version 1.3 or later.
Source of the article : Wikipedia
0 Comments