Misplaced Pages

This is an old revision of this page, as edited by Thijs!bot (talk | contribs) at 08:30, 13 August 2007 (robot Adding: sv:Base64). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

It has been suggested that Radix-64 be merged into this article. (Discuss) Proposed since January 2007.

Base64 or quadrosexagesimal is a positional notation 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.

Base 64 encoding schemes

Privacy-Enhanced Mail (PEM)

The first known use of Base 64 encoding for electronic data transfer was the Privacy-enhanced Electronic Mail (PEM) protocol, proposed by RFC 989 in 1987. PEM defines a "printable encoding" scheme that uses Base 64 encoding to transform an arbitrary sequence of octets to a format that can be expressed in short lines of 7-bit characters, as required by transfer protocols such as SMTP.

The current version of PEM (specified in RFC 1421) uses a 64-character alphabet consisting of upper- and lower-case Roman alphabet characters (A–Z, a–z), the numerals (0–9), and the "+" and "/" symbols. The "=" symbol is also used as a special suffix code. The original specification, RFC 989, additionally used the "*" symbol to delimit encoded but unencrypted data within the output stream.

To convert data to PEM printable encoding, 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 is repeated on the remaining data until less than four octets remain. If three octets remain, they are processed normally. If fewer than three octets (24 bits) are remaining to encode, the input data is right-padded with zero bits to form an integral multiple of six bits.

After encoding padded data, if two octets were remaining to encode, one "=" character is appended to the output; if one octet was remaining, two "=" characters are appended. This signals the decoder that the zero bits added due to padding should not be emitted in the reconstructed data. This also guarantees that the encoded output length is a multiple of 4 bytes.

PEM requires that all encoded lines consist of exactly 64 printable characters, with the exception of the last line, which may contain fewer printable characters. Lines are delimited by whitespace characters according to local (platform-specific) conventions.

MIME

The MIME (Multipurpose Internet Mail Extensions) specification, defined in RFC 2045, lists "base64" as one of several binary-to-text encoding schemes. MIME's base64 encoding is based on that of the RFC 1421 version of PEM: it uses the same 64-character alphabet and encoding mechanism as PEM, and uses the "=" symbol for output padding in the same way.

MIME does not specify a fixed length for base64-encoded lines, but it does specify a maximum length of 76 characters. Additionally it specifies that any extra-alphabetic characters must be ignored by a compliant decoder, although most implementations use a CR/LF newline pair to delimit encoded lines.

Thus, the actual length of MIME-compliant base64-encoded binary data is usually about 137% of the original data length, though for very short messages the overhead can be a lot higher.

UTF-7

UTF-7, described in RFC 2152, introduced a system called Modified Base64. This data encoding scheme is used to encode UTF-16 as ASCII characters for use in 7-bit transports such as SMTP. It is a variant of the base64 encoding used in MIME.

The "Modified Base64" alphabet consists of the MIME base64 alphabet, but does not use the "=" padding character. UTF-7 is intended for use in mail headers (defined in RFC 2047), and the "=" character is reserved in that context as the escape character for "quoted-printable" encoding. Modified base64 simply omits the padding and ends immediately after the last BASE64 digit containing useful bits (leaving 0-4 unused bits in the last base64 digit)

OpenPGP

OpenPGP, described in RFC 2440, describes Radix-64 encoding, also known as "ASCII Armor". Radix-64 is identical to the "base64" encoding described from MIME, with the addition of a 24-bit CRC checksum. The checksum is calculated on the input data before encoding; the checksum is then encoded with the same base64 algorithm and, using an additional "=" symbol as separator, concatenated to the encoded output data.

RFC 3548

RFC 3548 (The Base16, Base32, and Base64 Data Encodings) is an informational (non-normative) memo that attempts to unify the RFC 1421 and RFC 2045 specifications of base64 encodings, alternative-alphabet encodings, and the seldom-used Base 32 and Base 16 encodings.

RFC 3548 forbids implementations from adding non-alphabetic characters unless they are written to a specification that refers to RFC 3548 and specifically requires otherwise; it also declares that decoder implementations must reject data that contains non-alphabetic characters unless they are written to a specification that refers to RFC 3548 and specifically requires otherwise.

RFC 4648

This RFC obsoletes RFC 3548 and focuses on base 64/32/16:

This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings.

Example

A quote from Thomas Hobbes's Leviathan:

Man is distinguished, not only by his reason, but by this singular passion from other animals, which is a lust of the mind, that by a perseverance of delight in the continued and indefatigable generation of knowledge, exceeds the short vehemence of any carnal pleasure.

is encoded in MIME's base64 scheme as follows:

TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFzb24sIGJ1dCBieSB0aGlz
IHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3aGljaCBpcyBhIGx1c3Qgb2Yg
dGhlIG1pbmQsIHRoYXQgYnkgYSBwZXJzZXZlcmFuY2Ugb2YgZGVsaWdodCBpbiB0aGUgY29udGlu
dWVkIGFuZCBpbmRlZmF0aWdhYmxlIGdlbmVyYXRpb24gb2Yga25vd2xlZGdlLCBleGNlZWRzIHRo
ZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm5hbCBwbGVhc3VyZS4=

In the above quote the encoded value of Man is TWFu. Encoded in ASCII, M, a, n are stored as the bytes 77, 97, 110, which are 01001101, 01100001, 01101110 in base 2. These three bytes are joined together in a 24 bit buffer producing 010011010110000101101110. Packs of 6 bits (6 bits has a maximum of 64 different binary values) are converted into 4 numbers (24 = 6x4) which are then converted to their corresponding values in Base 64.

As this example illustrates, Base 64 encoding converts 3 uncoded bytes (in this case, ASCII characters) into 4 encoded ASCII characters.

The example below illustrates how shortening the input changes the output padding:

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=

Implementation

The traditional (MIME) base64 encoding and decoding processes are fairly simple to implement. Here an example using Javascript is given, including the MIME/etc required line breaks at particular line lengths. It is worth noting however, that many base64 functions (e.g. in PHP) return base64 encrypted strings without the line breaks, as the line breaks can be inserted easily after encoding, and many times the base64 encoding is desired only for safely transferring data via XML or inserting into a database, etc -- times when the line breaks are known to be unnecessary and therefore undesirable. The newline inserting and removing in these functions here can easily be commented out (they are each only one line in the respective functions) if they are not needed.

An array of the base 64 characters is necessary for encoding, such as:

 var base64chars = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/'.split("");

And decoding will require the inverse list (swap the indices for the values), such as:

 var base64inv = {}; for (var i = 0; i < base64chars.length; i++) { base64inv] = i; }

Note that in real implementations, it is better to explicitly list the entire array/hash for each list above -- the one-liners here are given to demostrate the idea as directly as possible, rather than being the ideal in practice.

The base64 encoding function:

 function base64_encode (s)
 {
   // the result/encrypted string, the padding string, and the pad count
   var r = ""; var p = ""; var c = s.length % 3;
   // add a right zero pad to make this string a multiple of 3 characters
   if (c > 0) { for (; c < 3; c++) { p += '='; s += "\0"; } }
   // increment over the length of the string, three characters at a time
   for (c = 0; c < s.length; c += 3) {
     // we add newlines after every 76 output characters, according to the MIME specs
     if (c > 0 && (c / 3 * 4) % 76 == 0) { r += "\r\n"; }
     // these three 8-bit (ASCII) characters become one 24-bit number
     var n = (s.charCodeAt(c) << 16) + (s.charCodeAt(c+1) << 8) + s.charCodeAt(c+2);
     // this 24-bit number gets separated into four 6-bit numbers
     n = ;
     // those four 6-bit numbers are used as indices into the base64 character list
     r += base64chars] + base64chars] + base64chars] + base64chars];
     // add the actual padding string, after removing the zero pad
   } return r.substr(0, r.length - p.length) + p;
 }

The base64 decoding function:

 function base64_decode (s)
 {
   // replace any incoming padding with a zero pad (the 'A' character is zero)
   var p = (s.charAt(s.length-1) == '=' ? (s.charAt(s.length-2) == '='
    ? 'AA' : 'A') : ""); var r = ""; s = s.substr(0, s.length - p.length) + p;
   // remove/ignore any characters not in the base64 characters list -- particularly newlines
   s = s.replace(new RegExp('', 'g'), "");
   // increment over the length of this encrypted string, four characters at a time
   for (var c = 0; c < s.length; c += 4) {
     // each of these four characters represents a 6-bit index in the base64 characters list
     //  which, when concatenated, will give the 24-bit number for the original 3 characters
     var n = (base64inv << 18) + base64inv +
      (base64inv << 12) + (base64inv << 6);
     // split the 24-bit number into the original three 8-bit (ASCII) characters
     r += String.fromCharCode((n >>> 16) & 255, (n >>> 8) & 255, n & 255);
     // remove any zero pad that was added to make this a multiple of 24 bits
   } return r.substr(0, r.length - p.length);
 }

The above implementation is best with a language like Javascript that handles string concatenation of arbitrary length strings very efficiently. Other languages (e.g. C) will work much more efficiently by allocating memory for a new string/array of the appropriate size (the output string length is easily calculated from the input string at the very beginning) and then simply setting each character index, as opposed to concatenation.

URL applications

Base64 encoding can be helpful when fairly lengthy identifying information is used in an HTTP environment. Hibernate, a database persistence framework for Java objects, uses Base64 encoding to encode a relatively large unique id (generally 128-bit UUIDs) into a string for use as an HTTP parameter in HTTP forms or HTTP GET URLs. Also, many applications need to encode binary data in a way that is convenient for inclusion in URLs, including in hidden web form fields, and Base64 is a convenient encoding to render them in not only a compact way, but in a relatively unreadable one when trying to obscure the nature of data from a casual human observer.

Using a URL-encoder on standard Base64, however, is inconvenient as it will translate the '+' and '/' characters into special '%XX' hexadecimal sequences ('+' = '%2B' and '/' = '%2F'). 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).

Other applications

Base64 can be used in a variety of contexts:

• Thunderbird and Evolution both use Base64 to obscure e-mail passwords
• Base64 is often used as a quick but insecure shortcut to obscure secrets without incurring the overhead of cryptographic key management
• Spammers use Base64 to evade basic anti-spam tools, which often do not decode Base64 and therefore cannot detect keywords in encoded messages.
• Base64 is used to encode character strings in LDIF files
• Base64 is sometimes used to embed binary data in an XML file, using a syntax similar to ...... e.g.: Firefox's bookmarks.html.
• Base64 is also used when communicating with Fiscal Signature/Printing devices (usually, over COM or LPT ports) to minimize the delay when transferring receipt characters for signing.

See also

• Base32
• Radix-64
• ASCII85
• Quoted-printable
• uuencode
• yEnc
• 8BITMIME
• URL

External links

This article's use of external links may not follow Misplaced Pages's policies or guidelines. Please improve this article by removing excessive or inappropriate external links, and converting useful links where appropriate into footnote references. (July 2007) (Learn how and when to remove this message)

• RFC 989 and RFC 1421 (Privacy Enhancement for Electronic Internet Mail)
• RFC 2045 (Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies)
• RFC 3548 and RFC 4648 (The Base16, Base32, and Base64 Data Encodings)
• Home of the Base64 specification, with an online decoder and C99 implementation
• Base64 primer tutorial with accompanying lecture slides
• and
• MIME::Base64 Perl module
• Base64 implementation in Java

• Articles to be merged from January 2007
• Misplaced Pages external links cleanup from July 2007
• Usenet
• E-mail
• Internet standards
• Binary-to-text encoding formats
• Data serialization formats
• Positional numeral systems