Base 64 is a positional numeral system using a base of 64. It is the largest power of two base that can be represented using only printable ASCII characters. This has led to its use as a transfer encoding for e-mail among other things. All well-known variants that are known by the name Base64 use the characters A–Z, a–z, and 0–9 in that order for the first 62 digits but the symbols chosen for the last two digits vary considerably between different systems. Several other encoding methods such as uuencode and later versions of binhex use a different set of 64 characters to represent 6 binary digits but these are never called by the name base64.
Full specifications for this form of base64 are contained in RFC 1421 and RFC 2045. The scheme is defined to encode a sequence of octets (bytes). This matches up with the definition of files on almost all systems. The resultant base64-encoded data exceeds the original in length by the ratio 4:3, and typically appears to consist of seemingly random characters. As newlines are inserted in the encoded data every 76 characters, the actual length of the encoded data is approximately 135.1% of the original.
To convert data to base64, the first byte is placed in the most significant eight bits of a 24-bit buffer, the next in the middle eight, and the third in the least significant eight bits. If there are fewer than three bytes left to encode (or in total), the remaining buffer bits will be zero. The buffer is then used, six bits at a time, most significant first, as indices into the string: "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/" and the indicated character is output.
The process then repeats on the remaining input data.
If there are two input bytes remaining (the remainder of the total input bytes divided by three is two), pad with one "=". If there is one input byte remaining (remainder was one), pad with two "=", otherwise, don’t pad. This prevents extra bits being added to the reconstructed data.
For example, a quote from Thomas Hobbes's Leviathan:
is encoded in base64 is as follows:
TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFzb24sIGJ1dCBieSB0aGlz IHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3aGljaCBpcyBhIGx1c3Qgb2Yg dGhlIG1pbmQsIHRoYXQgYnkgYSBwZXJzZXZlcmFuY2Ugb2YgZGVsaWdodCBpbiB0aGUgY29udGlu dWVkIGFuZCBpbmRlZmF0aWdhYmxlIGdlbmVyYXRpb24gb2Yga25vd2xlZGdlLCBleGNlZWRzIHRo ZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm5hbCBwbGVhc3VyZS4=
To illustrate the padding, as we shorten the input, the output changes as follows:
Input ends with carnal pleasure. Output ends with: c3VyZS4= Input ends with carnal pleasure Output ends with: c3VyZQ== Input ends with carnal pleasur Output ends with: c3Vy Input ends with carnal pleasu Output ends with: c3U=
In the above example the encoded value of Man is TWFu. Here is a method that illustrates how one gets the value.
ASCII value of 'M' = 77 = 01001101 ASCII value of 'a' = 97 = 01100001 ASCII value of 'n' = 110 = 01101110
Now from these three bytes we get the 24 bit buffer which would be
010011010110000101101110 (As mentioned in the method the first byte M is placed in the most significant 8 bits of the 24 bit buffer followed by second and third bytes). This number has to be converted to its base 64 value which can be done by taking 6 bits at a time (6 bits has a maximum of 64 different binary values).Now taking 6 bits at a time from the buffer we get the 4 numbers, which are then converted to their corresponding values in Base 64.
010011 = 19 = T 010110 = 22 = W 000101 = 5 = F 101110 = 46 = u
Hence, 3 uncoded bytes (in this case ascii characters) in, 4 encoded ascii characters out.
Modified Base64 is standardized as RFC 2152, A Mail-Safe Transformation Format of Unicode.
Using a URL-encoder on standard Base64, however, is inconvenient as it will translate the '/' and '+' characters into special '%XX' hexadecimal sequences. When this is later used with database storage or across heterogeneous systems, they will themselves choke on the '%' character generated by URL-encoders (because the '%' character is also used in ANSI SQL as a wildcard).
For this reason, a modified Base64 for URL variant exists, where no padding '=' will be used, and the '+' and '/' characters of standard Base64 are respectively replaced by '*' and '-', so that using URL encoders/decoders is no longer necessary and has no impact on the length of the encoded value, leaving the same encoded form intact for use in relational databases, web forms, and object identifiers in general.
Another variant called modified Base64 for regexps uses '!-' instead of '*-' to replace the standard Base64 '+/', because both '+' and '*' may be reserved for regular expressions (note that '*' used in the IRCu variant above would not work in that context).
There are other variants that use '_-' or '._' when the Base64 variant string must be used within valid identifiers for programs, or '.-' for use in XML name tokens (Nmtoken), or even '_:' for use in more restricted XML identifiers (Name).
Usenet | E-mail | Internet standards | Binary to text encoding formats | Positional numeral systems
Base64 | Base64 | Base64 | Base64 | Base64 | Base64 | Base64 | Base64 | Base64 | Base64 | Base64