SUPPORT THE WORK

GetWiki

Base64

ARTICLE SUBJECTS
aesthetics  →
being  →
complexity  →
database  →
enterprise  →
ethics  →
fiction  →
history  →
internet  →
knowledge  →
language  →
licensing  →
linux  →
logic  →
method  →
news  →
perception  →
philosophy  →
policy  →
purpose  →
religion  →
science  →
sociology  →
software  →
truth  →
unix  →
wiki  →
ARTICLE TYPES
essay  →
feed  →
help  →
system  →
wiki  →
ARTICLE ORIGINS
critical  →
discussion  →
forked  →
imported  →
original  →
Base64
[ temporary import ]
please note:
- the content below is remote from Wikipedia
- it has been imported raw for GetWiki
{{Multiple issues|{{Lead too short|date=February 2013}}{{Primary sources|date=April 2019}}}}In computer science Base64 is a group of binary-to-text encoding schemes that represent binary data in an ASCII string format by translating it into a radix-64 representation. The term Base64 originates from a specific MIME content transfer encoding. Each Base64 digit represents exactly 6 bits of data. Three 8-bit bytes (i.e., a total of 24 bits) can therefore be represented by four 6-bit Base64 digits.Common to all binary-to-text encoding schemes, Base64 is designed to carry data stored in binary formats across channels that only reliably support text content. Base64 is particularly prevalent on the World Wide WebWEB, Base64 encoding and decoding - Web APIs | MDN,weblink where its uses include the ability to embed image files or other binary assets inside textual assets such as HTML and CSS files.WEB, When to base64 encode images (and when not to),weblink {{TOC limit|3}}

Design

The particular set of 64 characters chosen to represent the 64 place-values for the base varies between implementations. The general strategy is to choose 64 characters that are common to most encodings and that are also printable. This combination leaves the data unlikely to be modified in transit through information systems, such as email, that were traditionally not 8-bit clean.IETF, The Base16,Base32,and Base64 Data Encodings, 4648, October 2006, Internet Engineering Task Force, IETF, March 18, 2010, For example, MIME's Base64 implementation uses A–Z, a–z, and 0–9 for the first 62 values. Other variations share this property but differ in the symbols chosen for the last two values; an example is UTF-7.The earliest instances of this type of encoding were created for dialup communication between systems running the same OS â€” e.g., uuencode for UNIX, BinHex for the TRS-80 (later adapted for the Macintosh) â€” and could therefore make more assumptions about what characters were safe to use. For instance, uuencode uses uppercase letters, digits, and many punctuation characters, but no lowercase.IETF, Privacy Enhancement for InternetElectronic Mail: Part I: Message Encryption and Authentication Procedures, 1421, February 1993, Internet Engineering Task Force, IETF, March 18, 2010, IETF, Multipurpose Internet Mail Extensions: (MIME) Part One: Format of Internet Message Bodies, 2045, November 1996, Internet Engineering Task Force, IETF, March 18, 2010, IETF, The Base16, Base32, and Base64 Data Encodings, 3548, July 2003, Internet Engineering Task Force, IETF, March 18, 2010,

Base64 table

The Base64 index table:{|class="wikitable" style="text-align:center"!scope="col"| Index !!scope="col"| Char
!scope="col"| Index !!scope="col"| Char!scope="col"| Index !!scope="col"| Char!scope="col"| Index !!scope="col"| Char
| w
| x
| y
| z
| 0
| 1
| 2
| 3
| 4
| 5
| 6
| 7
| 8
| 9
| +
| /

Examples

The example below uses ASCII text for simplicity, but this is not a typical use case, as it can already be safely transferred across all systems that can handle Base64. The more typical use is to encode binary data (such as an image); the resulting Base64 data will only contain 64 different ASCII characters, all of which can reliably be transferred across systems that may corrupt the raw source bytes.Here is a quote from Thomas Hobbes' 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.
(Please note that all of the example encodings below use only the bytes shown here; there is no C-String-styled terminator assumed.)When that quote is encoded into Base64, it is represented as a byte sequence of 8-bit-padded ASCII characters encoded in MIME's Base64 scheme as follows (newlines and whitespaces may be present anywhere but are to be ignored on decoding):
TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFzb24sIGJ1dCBieSB0aGlz
IHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3aGljaCBpcyBhIGx1c3Qgb2Yg
dGhlIG1pbmQsIHRoYXQgYnkgYSBwZXJzZXZlcmFuY2Ugb2YgZGVsaWdodCBpbiB0aGUgY29udGlu
dWVkIGFuZCBpbmRlZmF0aWdhYmxlIGdlbmVyYXRpb24gb2Yga25vd2xlZGdlLCBleGNlZWRzIHRo
ZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm5hbCBwbGVhc3VyZS4=
In the above quote, the encoded value of Man is TWFu. Encoded in ASCII, the characters M, a, and n are stored as the bytes 77, 97, and 110, which are the 8-bit binary values 01001101, 01100001, and 01101110. These three values are joined together into a 24-bit string, producing 010011010110000101101110. Groups of 6 bits (6 bits have a maximum of 26 = 64 different binary values) are converted into individual numbers from left to right (in this case, there are four numbers in a 24-bit string), which are then converted into their corresponding Base64 character values.As this example illustrates, Base64 encoding converts three octets into four encoded characters.{| class="wikitable" style="text-align:center;" style="font-weight:bold;"! rowspan=2 scope="row" | Source! scope="row" | Text (ASCII)
M a n
! scope="row" | Octets
77 (0x4d) 97 (0x61) 110 (0x6e)
! colspan=2 scope="row" | Bits
| 1| 1| 0
! rowspan=3 scope="row" | Base64encoded! scope="row" | Sextets
19 22 5 46
style="font-weight:bold;"! scope="row" | Character
T W F u
! scope="row" | Octets
84 (0x54) 87 (0x57) 70 (0x46) 117 (0x75)

padding characters might be added to make the last encoded block contain four Base64 characters.

If there are only two significant input octets (e.g., 'Ma'), or when the last input group contains only two octets, all 16 bits will be captured in the first three Base64 digits (18 bits); the two least significant bits of the last content-bearing 6-bit block will turn out to be zero, and discarded on decoding (along with the following = padding characters):{|class="wikitable" style="text-align:center;" style="font-weight:bold;"! rowspan=2 scope="row" | Source! scope="row" | Text (ASCII)
M a}}
! scope="row" | Octets
77 (0x4d) 97 (0x61)
! colspan=2 scope="row" | Bits
| 1| 0| 1 0 0{{fsp}}}}{{fsp}}}}{{fsp}}}}{{fsp}}}}{{fsp}}}}{{fsp}}}}
! rowspan=3 scope="row" | Base64encoded! scope="row" | Sextets
19 22 4Padding}}
style="font-weight:bold;"! scope="row" | Character
T W E =
! scope="row" | Octets
84 (0x54) 87 (0x57) 69 (0x45) 61 (0x3D)
If there is only one significant input octet (e.g., 'M'), or when the last input group contains only one octet, all 8 bits will be captured in the first two Base64 digits (12 bits); the four least significant bits of the last content-bearing 6-bit block will turn out to be zero, and discarded on decoding (along with the following = padding characters):{| class="wikitable" style="text-align:center;" style="font-weight:bold;"! rowspan=2 scope="row" | Source! scope="row" | Text (ASCII)
M}}
! scope="row" | Octets
77 (0x4d)
! colspan=2 scope="row" | Bits
| 1| 1 0 0 0 0{{fsp}}}}{{fsp}}}}{{fsp}}}}{{fsp}}}}{{fsp}}}}{{fsp}}}}{{fsp}}}}{{fsp}}}}{{fsp}}}}{{fsp}}}}{{fsp}}}}{{fsp}}}}
! rowspan=3 scope="row" | Base64encoded! scope="row" | Sextets
19 16Padding}}Padding}}
style="font-weight:bold;"! scope="row" | Character
T Q = =
! scope="row" | Octets
84 (0x54) 81 (0x51) 61 (0x3D) 61 (0x3D)

Output padding

The final == sequence indicates that the last group contained only one byte, and = indicates that it contained two bytes. The example below illustrates how truncating the input of the above quote changes the output padding:{|class="wikitable"! scope="col" colspan=2 | Input! scope="col" colspan=2 | Output! scope="col" rowspan=2 | Padding
! scope="col" | Length! scope="col" | Text! scope="col" | Length! scope="col" | Text
lightgreylightblue|e.}}''1=YW55IGNhcm5hbCBwbGVh{{bgc3Vy}}{{bg2=ZS4=}}}}| 1
lightgreylightblue|e}}''1=YW55IGNhcm5hbCBwbGVh{{bgc3Vy}}{{bg2=ZQ==}}}}| 2
any carnal plea{{bg>lightgrey|sur}}1=YW55IGNhcm5hbCBwbGVh{{bgc3Vy}}}}| 0
any carnal plea{{bg>lightgrey|su}}1=YW55IGNhcm5hbCBwbGVh{{bg2=c3U=}}}}| 1
any carnal plea{{bg>lightgrey|s}}1=YW55IGNhcm5hbCBwbGVh{{bg2=cw==}}}}| 2
The same characters will be encoded differently depending on their position within the three-octet group which is encoded to produce the four characters. For example:{|class="wikitable" style="text-align:right;"! scope="col" | Input! scope="col" | Output
lightgreycGxlY{{bg2=XN1cmUu}}}}
lightgrey1=bGVh{{bg2=c3VyZS4=}}}}
lightgrey1=ZWF{{bg2=zdXJlLg==}}}}
lightgreyY{{bg2=XN1cmUu}}}}
lightgrey1={{bg2=c3VyZS4=}}}}
The ratio of output bytes to input bytes is 4:3 (33% overhead). Specifically, given an input of n bytes, the output will be 4 leftlceil frac{1}{3}n rightrceil bytes long, including padding characters.In theory, the padding character is not needed for decoding, since the number of missing bytes can be calculated from the number of Base64 digits. In some implementations, the padding character is mandatory, while for others it is not used. One case in which padding characters are required is concatenating multiple Base64 encoded files.

Decoding Base64 with padding

When decoding Base64 text, four characters are typically converted back to three bytes. The only exceptions are when padding characters exist. A single = indicates that the four characters will decode to only two bytes, while == indicates that the four characters will decode to only a single byte. For example:{| class="wikitable"! Encoded !! Padding !! Length !! Decoded
1=YW55IGNhcm5hbCBwbGVh{{bg2=cw==}}}}| 1any carnal plea{{bg>lightgrey|s}}
1=YW55IGNhcm5hbCBwbGVh{{bg2=c3U=}}}}| 2any carnal plea{{bg>lightgrey|su}}
1=YW55IGNhcm5hbCBwbGVh{{bgc3Vy}}}}None}} 3any carnal plea{{bg>lightgrey|sur}}

Decoding Base64 without padding

Without padding, after normal decoding of four characters to three bytes over and over again, fewer than four encoded characters may remain. In this situation only two or three characters shall remain. A single remaining encoded character is not possible (because a single Base64 character only contains 6 bits, and 8 bits are required to create a byte, so a minimum of 2 Base64 characters are required: The first character contributes 6 bits, and the second character contributes its first 2 bits.) For example:{| class="wikitable"! Length !! Encoded !! Length !! Decoded
1=YW55IGNhcm5hbCBwbGVh{{bgcw}}}}any carnal plea{{bg>lightgrey|s}}
1=YW55IGNhcm5hbCBwbGVh{{bgc3U}}}}any carnal plea{{bg>lightgrey|su}}
1=YW55IGNhcm5hbCBwbGVh{{bgc3Vy}}}}any carnal plea{{bg>lightgrey|sur}}

Implementations and history

Variants summary table

Implementations may have some constraints on the alphabet used for representing some bit patterns. This notably concerns the last two characters used in the index table for index 62 and 63, and the character used for padding (which may be mandatory in some protocols, or removed in others). The table below summarizes these known variants, and link to the subsections below.{|class="wikitable" style="text-align:center"! rowspan=2 | Encoding! colspan=3 | Encoding characters! colspan=3 | Separate encoding of lines! rowspan=2 | Decoding non-encoding characters
! 62nd! 63rd! pad! Separators! Length! Checksum
! Base64 for Privacy-Enhanced Mail (PEM; {{nowrap|RFC 1421}}; deprecated)
{{code|{{=}}}} mandatory}}CR+LF}} {{Yes| {{No}}
! Base64 transfer encoding for MIME ({{nowrap|RFC 2045}})
{{code|{{=}}}} mandatory}}CR+LF}} {{PartialDiscarded}}
! base64 for {{nowrap|RFC 4648}} (previously, {{nowrap|RFC 3548}}; standard){{efn|name=common|It is important to note that this variant is intended to provide common features where they are not desired to be specialised by implementations, ensuring robust engineering. This is particularly in light of separate line encodings and restrictions, which have not been considered when previous standards have been co-opted for use elsewhere. Thus, the features indicated here may be over-ridden.}}
{{code|{{=}}}} mandatory}} | {{No}}
! base64url URL- and filename-safe ({{nowrap|RFC 4648 §5}}){{efn|name=common}}
{{code|{{=}}}} optional}}| {{No}}
! Radix-64 for OpenPGP ({{nowrap|RFC 4880}})
{{code|{{=}}}} mandatory}}CR+LF}} {{PartialRadix-64 encoded 24-bit cyclic redundancy check}} >| {{No}}
! Base64 for UTF-7 ({{nowrap|RFC 2152}})
|| {{No}}
! Base64 encoding for IMAP mailbox names ({{nowrap|RFC 3501}})
|| {{No}}
! Y64 URL-safe Base64 from YUI LibraryWEB,weblink YUIBlog, YUIBlog, 2012-06-21,
{{code|-}} optional}}| {{No}}
! XML name tokens (Nmtoken) Base64
|| {{No}}
! XML identifiers (Name) Base64
|| {{No}}
! Program identifier Base64 variant 1 (non-standard)
|| colspan=4 {{unk}}
! Program identifier Base64 variant 2 (non-standard)
|| colspan=4 {{unk}}
! Freenet URL-safe Base64 (non-standard)
{{code|{{=}}}} optional}}| {{No}}
{{noteslist}}Due to so many variants for base64, base62x has been introduced to unify all of them by excluding symbols in its output, i.e. only letters and numbers in the textual representation of base64 implementation in base62x.

Privacy-enhanced mail

The first known standardized use of the encoding now called MIME Base64 was in the Privacy-enhanced Electronic Mail (PEM) protocol, proposed by RFC 989 in 1987. PEM defines a "printable encoding" scheme that uses Base64 encoding to transform an arbitrary sequence of octets to a format that can be expressed in short lines of 6-bit characters, as required by transfer protocols such as SMTP.IETF, Privacy Enhancement for Internet Electronic Mail, 989, February 1987, Internet Engineering Task Force, IETF, March 18, 2010, The current version of PEM (specified in RFC 1421) uses a 64-character alphabet consisting of upper- and lower-case Roman letters (A–Z, a–z), the numerals (0–9), and the + and / symbols. The = symbol is also used as a padding suffix. 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 fewer 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 the non-padded data, if two octets of the 24-bit buffer are padded-zeros, two = characters are appended to the output; if one octet of the 24-bit buffer is filled with padded-zeros, one = character is appended. This signals the decoder that the zero bits added due to padding should be excluded from 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 lists Base64 as one of two binary-to-text encoding schemes (the other being quoted-printable). 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, as described at RFC 2045.MIME does not specify a fixed length for Base64-encoded lines, but it does specify a maximum line 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 much higher due to the overhead of the headers. Very roughly, the final size of Base64-encoded binary data is equal to 1.37 times the original data size + 814 bytes (for headers). The size of the decoded data can be approximated with this formula:
bytes = (string_length(encoded_string) - 814) / 1.37

UTF-7

UTF-7, described first in RFC 1642, which was later superseded by 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.IETF, UTF-7 A Mail-Safe Transformation Format of Unicode, 1642, July 1994, Internet Engineering Task Force, IETF, March 18, 2010, IETF, UTF-7 A Mail-Safe Transformation Format of Unicode, 2152, May 1997, Internet Engineering Task Force, IETF, March 18, 2010, 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 up to three unused bits in the last Base64 digit.

OpenPGP

OpenPGP, described in RFC 4880, describes Radix-64 encoding, also known as "ASCII armor". Radix-64 is identical to the "Base64" encoding described from MIME, with the addition of an optional 24-bit CRC. The checksum is calculated on the input data before encoding; the checksum is then encoded with the same Base64 algorithm and, prefixed by "=" symbol as separator, appended to the encoded output data.IETF, OpenPGP Message Format, 4880, November 2007, Internet Engineering Task Force, IETF, March 18, 2010,

RFC 3548

RFC 3548, entitled 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 Base32 and Base16 encodings.Unless implementations are written to a specification that refers to RFC 3548 and specifically requires otherwise, RFC 3548 forbids implementations from generating messages containing characters outside the encoding alphabet or without padding, and it also declares that decoder implementations must reject data that contain characters outside the encoding alphabet.RFC 4648">

RFC 4648

This RFC obsoletes RFC 3548 and focuses on Base64/32/16:
This document describes the commonly used Base64, Base32, and Base16 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.

Filenames

Another variant called modified Base64 for filename uses '-' instead of '/', because Unix and Windows filenames cannot contain '/'.It could be recommended to use the modified Base64 for URL instead, since then the filenames could be used in URLs also.

URL applications

Base64 encoding can be helpful when fairly lengthy identifying information is used in an HTTP environment. For example, a database persistence framework for Java objects might use 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 a compact way.Using standard Base64 in URL requires encoding of '+', '/' and '=' characters into special percent-encoded hexadecimal sequences ('+' becomes '%2B', '/' becomes '%2F' and '=' becomes '%3D'), which makes the string unnecessarily longer.For this reason, modified Base64 for URL variants exist (such as base64url in RFC 4648), where the '+' and '/' characters of standard Base64 are respectively replaced by '-' and '_', so that using URL encoders/decoders is no longer necessary and have 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. Some variants allow or require omitting the padding '=' signs to avoid them being confused with field separators, or require that any such padding be percent-encoded. Some libraries will encode '=' to '.', potentially exposing applications to relative path attacks when a folder name is encoded from user data.

Program identifiers

There are other variants{{clarify|date=September 2018}} that use _- or ._ when the Base64 variant string must be used within valid identifiers for programs.

XML

XML identifiers and name tokens are encoded using two variants:{{Citation needed|date=July 2018}}
  • .- for use in XML name tokens (Nmtoken), or even
  • _: for use in more restricted XML identifiers (Name).

HTML

The atob() and btoa() JavaScript methods, defined in the HTML5 draft specification,WEB, 7.3. Base64 utility methods,weblink HTML 5.2 Editor's Draft, World Wide Web Consortium, 2 January 2017, Introduced by changeset 5814, 2011-02-01. provide Base64 encoding and decoding functionality to web pages. The btoa() method outputs padding characters, but these are optional in the input of the atob() method.

Other applications

(File:35_mm_angle_of_view_vs_focal_length.svg|thumb|Example of an SVG containing embedded JPEG images encoded in Base64)Base64 can be used in a variety of contexts:
  • Base64 can be used to transmit and store text that might otherwise cause delimiter collision
  • Spammers use Base64 to evade basic anti-spamming 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 often used to embed binary data in an XML file, using a syntax similar to … e.g. favicons in Firefox's exported bookmarks.html.
  • Base64 is used to encode binary files such as images within scripts, to avoid depending on external files.
  • The data URI scheme can use Base64 to represent file contents. For instance, background images and fonts can be specified in a CSS stylesheet file as data: URIs, instead of being supplied in separate files.
  • The FreeSWAN ipsec implementation precedes Base64 strings with 0s, so they can be distinguished from text or hexadecimal strings.
  • Although not part of the official specification for SVG, some viewers can interpret Base64 when used for embedded elements, such as images inside SVG.WEB,weblink Edit fiddle - JSFiddle, JSFiddle, jsfiddle.net,

Radix-64 applications not compatible with Base64

  • Uuencoding, traditionally used on UNIX, uses ASCII 32 (" " (space)) through 95 ("_"), consecutively, making its 64-character set " !"$%&'()+,-./0123456789:;?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[]^_". Avoiding all lower-case letters was helpful because many older printers only printed uppercase. Using consecutive ASCII characters saved computing power because it was only necessary to add 32, not do a lookup. Its use of most punctuation characters and the space character limits its usefulness.{{citation needed|date=April 2016}}
  • BinHex 4 (HQX), which was used within the classic Mac OS, uses a different set of 64 characters. It uses upper and lower case letters, digits, and punctuation characters, but does not use some visually confusable characters like '7', 'O', 'g' and 'o'. Its 64-character set is "!"$%&'()+,-012345689@ABCDEFGHIJKLMNPQRSTUVXYZ[`abcdefhijklmpqr".
  • Several other applications use radix-64 sets more similar to but in a different order to the Base64 format, starting with two symbols, then numerals, then uppercase, then lowercase:
    • Unix stores password hashes computed with crypt in the /etc/passwd file using radix-64 encoding called B64. It uses a mostly-alphanumeric set of characters, plus . and /. Its 64-character set is "./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz". Padding is not used.
    • The GEDCOM 5.5 standard for genealogical data interchange encodes multimedia files in its text-line hierarchical file format using radix-64. Its 64-character set is also ./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz".WEB,weblink The GEDCOM Standard Release 5.5, Homepages.rootsweb.ancestry.com, 2012-06-21,
    • bcrypt hashes are designed to be used in the same way as traditional crypt(3) hashes, and the algorithm uses a similar but permuted alphabet. Its 64-character set is "./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789".WEB,weblink src/lib/libc/crypt/bcrypt.c r1.1, Niels Provos, Niels, Provos, 1997-02-13, 2018-05-18,
    • Xxencoding uses a mostly-alphanumeric character set similar to crypt and GEDCOM, but using + and - rather than . and /. Its 64-character set is "+-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz".
  • 6PACK, used with some terminal node controllers, uses a different set of 64 characters.
WEB,weblink 6PACK a "real time" PC to TNC protocol, 2013-05-19,
    • Bash internally represents Base64 with character set "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ@_" which can be seen to decode as Base64 by iteratively decoding the sequence of characters in order: for i in {0..9} {a..z} {A..Z} '@' '_'; do printf "$i : $((64$i))n"; done

See also

References

{{Reflist|2}}

External links

{{Data Exchange}}

- content above as imported from Wikipedia
- "Base64" does not exist on GetWiki (yet)
- time: 1:40am EDT - Tue, Jun 25 2019
[ this remote article is provided by Wikipedia ]
LATEST EDITS [ see all ]
GETWIKI 09 MAY 2016
GETWIKI 18 OCT 2015
M.R.M. Parrott
Biographies
GETWIKI 20 AUG 2014
GETWIKI 19 AUG 2014
GETWIKI 18 AUG 2014
Wikinfo
Culture
CONNECT