Екілік деректі мәтінге түрлендіру

Conversion of computer data into text

A binary to text encoding is encoding of data in plain text. More precisely, it is an encoding of binary data in a sequence of printable characters. These encodings are necessary for transmission of data when the communication channel does not allow binary data (such as email or NNTP) or is not 8 bit clean. PGP documentation uses the term "ASCII armor" for binary to text encoding when referring to Base64.

The basic need for a binary to text encoding comes from a need to communicate arbitrary binary data over preexisting communications protocols that were designed to carry only English language human readable text. Those communication protocols may only be 7 bit safe (and within that avoid certain ASCII control codes), and may require line breaks at certain maximum intervals, and may not maintain whitespace. Thus, only the 94 printable ASCII characters are "safe" to use to convey data.

The ASCII text encoding standard uses 7 bits to encode characters. With this it is possible to encode 128 (i. e. 27) unique values (0–127) to represent the alphabetic, numeric, and punctuation characters commonly used in English, plus a selection of Control characters which do not represent printable characters. For example, the capital letter A is represented in 7 bits as 100 00012, 0x41 (1018) , the numeral 2 is 011 00102 0x32 (628), the character } is 111 11012 0x7D (1758), and the Control character RETURN is 000 11012 0x0D (158). In contrast, most computers store data in memory organized in eight bit bytes. Files that contain machine executable code and non textual data typically contain all 256 possible eight bit byte values. Many computer programs came to rely on this distinction between seven bit text and eight bit binary data, and would not function properly if non ASCII characters appeared in data that was expected to include only ASCII text. For example, if the value of the eighth bit is not preserved, the program might interpret a byte value above 127 as a flag telling it to perform some function. It is often desirable, however, to be able to send non textual data through text based systems, such as when one might attach an image file to an e mail message. To accomplish this, the data is encoded in some way, such that eight bit data is encoded into seven bit ASCII characters (generally using only alphanumeric and punctuation characters—the ASCII printable characters). Upon safe arrival at its destination, it is then decoded back to its eight bit form. This process is referred to as binary to text encoding. Many programs perform this conversion to allow for data transport, such as PGP and GNU Privacy Guard.

Binary to text encoding methods are also used as a mechanism for encoding plain text. For example:
Some systems have a more limited character set they can handle; not only are they not 8 bit clean, some cannot even handle every printable ASCII character. Other systems have limits on the number of characters that may appear between line breaks, such as the "1000 characters per line" limit of some Simple Mail Transfer Protocol software, as allowed by Still others add headers or trailers to the text. A few poorly regarded but still used protocols use in band signaling, causing confusion if specific patterns appear in the message. The best known is the string "From " (including trailing space) at the beginning of a line, used to separate mail messages in the mbox file format. By using a binary to text encoding on messages that are already plain text, then decoding on the other end, one can make such systems appear to be completely transparent. This is sometimes referred to as 'ASCII armoring'. For example, the ViewState component of ASP. NET uses base64 encoding to safely transmit text via HTTP POST, in order to avoid delimiter collision.

The table below compares the most used forms of binary to text encodings. The efficiency listed is the ratio between the number of bits in the input and the number of bits in the encoded output. Encoding Data type Efficiency Programming language implementations Comments Ascii85 Arbitrary 80% awk , C, C (2), C#, F#, Go, Java Perl, Python, Python (2) There exist several variants of this encoding, Base85, btoa, etc. Base32 Arbitrary 62.5% ANSI C, Delphi, Go, Java, C# F#, Python Base36 Integer ~64% bash, C, C++, C#, Java, Perl, PHP, Python, Visual Basic, Swift, many othersUses the Arabic numerals 0–9 and the Latin letters A–Z (the ISO basic Latin alphabet). Commonly used by URL redirection systems like TinyURL or SnipURL/Snipr as compact alphanumeric identifiers. Base45 Arbitrary ~67% (97%) Go, Python Defined in IETF Specification RFC 9285 for including binary data compactly in a QR code. Base56 Integer — PHP, Python, Go A variant of Base58 encoding which further sheds the '1' and the lowercase 'o' characters in order to minimise the risk of fraud and human error. Base58 Integer ~73% C, C++, Python, C#, Java Similar to Base64, but modified to avoid both non alphanumeric characters (+ and /) and letters that might look ambiguous when printed (0 zero, I capital i, O capital o and l lower case L). Base58 is used to represent bitcoin addresses. Some messaging and social media systems break lines on non alphanumeric strings. This is avoided by not using URI reserved characters such as +. For SegWit, it was replaced by Bech32, see below. Base62 Arbitrary ~74% Rust, Python Similar to Base64, but contains only alphanumeric characters. Base64 Arbitrary 75% awk , C, C (2), Delphi, Go, Python, many others An early and still popular encoding, first specified as part of in 1987 Base85 Arbitrary 80% C, Python, Python (2) Revised version of Ascii85. Base91 Arbitrary 81% C# F# Constant width variant basE91 Arbitrary 81% C, Java, PHP, 8086 Assembly, AWK C#, F#, Rust Variable width variant Base94 Arbitrary 82% Python, C, Rust Base122 Arbitrary 87.5% JavaScript, Python, Java, Base125 Python and Javascript, Go, C BaseXML Arbitrary 83.5% C Python JavaScript Bech32 Arbitrary 62.5% + at least 8 chars (label, separator, 6 char ECC) C, C++, JavaScript, Go, Python, Haskell, Ruby, Rust Specification. Used in Bitcoin and the Lightning Network. The data portion is encoded like Base32 with the possibility to check and correct up to 6 mistyped characters using the 6 character BCH code at the end, which also checks/corrects the Human Readable Part. The Bech32m variant has a subtle change that makes it more resilient to changes in length. BinHex Arbitrary 75% Perl, C, C (2) MacOS Classic Decimal Integer ~42% Most languages Usually the default representation for input/output from/to humans. Hexadecimal (Base16) Arbitrary 50% Most languages Exists in uppercase and lowercase variants Intel HEX Arbitrary ≲50% C library, C++ Typically used to program EPROM, NOR flash memory chips MIME Arbitrary See Quoted printable and Base64 See Quoted printable and Base64 Encoding container for e mail like formatting Percent encoding Text (URIs), Arbitrary (RFC1738) ~40% (33–70%) C, Python, probably many others Quoted printable Text ~33–100% Probably many Preserves line breaks; cuts lines at 76 characters S record (Motorola hex) Arbitrary 49.6% C library, C++ Typically used to program EPROM, NOR flash memory chips. 49.6% assumes 255 binary bytes per record. Tektronix hex Arbitrary Typically used to program EPROM, NOR flash memory chips. Uuencoding Arbitrary ~60% (up to 70%) Perl, C, Delphi, Java, Python, probably many others An early encoding developed in 1980 for Unix to Unix Copy. Largely replaced by MIME and yEnc Xxencoding Arbitrary ~75% (similar to Uuencoding) C, Delphi Proposed (and occasionally used) as replacement for Uuencoding to avoid character set translation problems between ASCII and the EBCDIC systems that could corrupt Uuencoded data z85 (ZeroMQ spec:32/Z85) Binary & ASCII 80% (similar to Ascii85/Base85) C (original), C#, Dart, Erlang, Go, Lua, Ruby, Rust and others Specifies a subset of ASCII similar to Ascii85, omitting a few characters that may cause program bugs (` \ " ' , ;). The format conforms to ZeroMQ spec:32/Z85. (S/KEY) Arbitrary 33% C, Each 64 bit number is mapped to six short words, of one to four characters each, from a public 2048 word dictionary. The 95 isprint codes 32 to 126 are known as the ASCII printable characters. Some older and today uncommon formats include BOO, BTOA, and USR encoding. Most of these encodings generate text containing only a subset of all ASCII printable characters: for example, the base64 encoding generates text that only contains upper case and lower case letters, (A–Z, a–z), numerals (0–9), and the "+", "/", and "=" symbols. Some of these encoding (quoted printable and percent encoding) are based on a set of allowed characters and a single escape character. The allowed characters are left unchanged, while all other characters are converted into a string starting with the escape character. This kind of conversion allows the resulting text to be almost readable, in that letters and digits are part of the allowed characters, and are therefore left as they are in the encoded text. These encodings produce the shortest plain ASCII output for input that is mostly printable ASCII. Some other encodings (base64, uuencoding) are based on mapping all possible sequences of six bits into different printable characters. Since there are more than 26 = 64 printable characters, this is possible. A given sequence of bytes is translated by viewing it as a stream of bits, breaking this stream in chunks of six bits and generating the sequence of corresponding characters. The different encodings differ in the mapping between sequences of bits and characters and in how the resulting text is formatted. Some encodings (the original version of BinHex and the recommended encoding for CipherSaber) use four bits instead of six, mapping all possible sequences of 4 bits onto the 16 standard hexadecimal digits. Using 4 bits per encoded character leads to a 50% longer output than base64, but simplifies encoding and decoding—expanding each byte in the source independently to two encoded bytes is simpler than base64's expanding 3 source bytes to 4 encoded bytes. Out of PETSCII's first 192 codes, 164 have visible representations when quoted: 5 (white), 17–20 and 28–31 (colors and cursor controls), 32–90 (ascii equivalent), 91–127 (graphics), 129 (orange), 133–140 (function keys), 144–159 (colors and cursor controls), and 160–192 (graphics). This theoretically permits encodings, such as base128, between PETSCII speaking machines.