Editing 8-bit clean (section)

== History ==
Until the early 1990s, many programs and data transmission channels were character-oriented and treated some characters, e.g., [[End-of-Text character|ETX]], as [[control characters]]. 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, avoiding an 8-bit representation [[ASCII#Bit width|in order to save on data transmission costs.]] On computers and data links using [[Byte#8-bit bytes|8-bit bytes]], this left the top [[bit]] of each [[byte]] free for use as a [[parity bit|parity]], [[flag bit]], or metadata control bit. 7-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 of [[octet (computing)|octets]] 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.