{"history":[],"article":{"id":"038030e0-8bca-475d-837c-a1c6f65a7c85","title":"Ascii85","slug":"ascii85","content":":::summary\n:::\n\n# \n**Ascii85**, also called **Base85**, is a form of [binary-to-text encoding](https://bliptext.com/articles/binary-to-text-encoding) developed by Paul E. Rutter for the [btoa](https://bliptext.com/articles/btoa) utility.\nBy using five [ASCII](https://bliptext.com/articles/ascii) characters to represent four bytes of [binary data](https://bliptext.com/articles/binary-data) (making the encoded size 1⁄4 larger than the original, assuming eight bits per [ASCII](https://bliptext.com/articles/ascii) character), it is more efficient than [uuencode](https://bliptext.com/articles/uuencode) or [Base64](https://bliptext.com/articles/base64), which use four characters to represent three bytes of data (1⁄3 increase, assuming eight bits per [ASCII](https://bliptext.com/articles/ascii) character).\nIts main modern uses are in [Adobe](https://bliptext.com/articles/adobe-systems)'s [PostScript](https://bliptext.com/articles/postscript) and [Portable Document Format](https://bliptext.com/articles/portable-document-format) file formats, as well as in the [patch](https://bliptext.com/articles/patch-unix) encoding for [binary files](https://bliptext.com/articles/binary-file) used by [Git](https://bliptext.com/articles/git).\n\n# Overview\nThe basic need for a binary-to-text encoding comes from a need to communicate arbitrary [binary data](https://bliptext.com/articles/binary-data) over preexisting [communications protocols](https://bliptext.com/articles/communications-protocol) that were designed to carry only English language [human-readable](https://bliptext.com/articles/human-readable) text.\nThose communication protocols may only be 7-bit safe (and within that avoid certain ASCII control codes), and may require [line breaks](https://bliptext.com/articles/line-break-computing) at certain maximum intervals, and may not maintain [whitespace](https://bliptext.com/articles/whitespace-computer-science).\nThus, only the 94 [printable ASCII characters](https://bliptext.com/articles/ascii) are \"safe\" to use to convey data.\nEighty-five is the minimum integer value of n such that n5 ≥ 2564; so any sequence of 4 bytes can be encoded as 5 symbols, as long as at least 85 distinct symbols are available.\n(Five [radix](https://bliptext.com/articles/radix)-85 digits can represent the integers from 0 to 4,437,053,124 inclusive, which suffice to represent all 4,294,967,296 possible 4-byte sequences.)\n\n# Encoding\nWhen encoding, each group of 4 bytes is taken as a 32-bit binary number, most significant byte first (Ascii85 uses a [big-endian](https://bliptext.com/articles/big-endian) convention).\nThis is converted, by repeatedly dividing by 85 and taking the remainder, into 5 radix-85 digits.\nThen each digit (again, most significant first) is encoded as an ASCII printable character by adding 33 to it, giving the ASCII characters 33 through 117.\nBecause all-zero data is quite common, an exception is made for the sake of [data compression](https://bliptext.com/articles/data-compression), and an all-zero group is encoded as a single character instead of.\nGroups of characters that decode to a value greater than 232 − 1 (encoded as ) will cause a decoding error, as will characters in the middle of a group.\nWhite space between the characters is ignored and may occur anywhere to accommodate line-length limitations.\n\n# Limitations\nThe original specification only allows a stream that is a multiple of 4 bytes to be encoded.\nEncoded data may contain [characters](https://bliptext.com/articles/escape-character) that have special meaning in many programming languages and in some text-based protocols, such as left-angle-bracket, backslash , and the single and double quotes &.\nOther base-85 encodings like Z85 and are designed to be safe in source code.\n\n# History\n\n## btoa version\nThe original btoa program always encoded full groups (padding the source as necessary), with a prefix line of \"xbtoa Begin\", and suffix line of \"xbtoa End\", followed by the original file length (in decimal and [hexadecimal](https://bliptext.com/articles/hexadecimal)) and three 32-bit [checksums](https://bliptext.com/articles/checksum).\nThe decoder needs to use the file length to see how much of the group was padding.\nThe initial proposal for btoa encoding used an encoding alphabet starting at the ASCII space character through \"t\" inclusive, but this was replaced with an encoding alphabet of \"!\"\nto \"u\" to avoid \"problems with some mailers (stripping off trailing blanks)\".\nThis program also introduced the special \" \" short form for an all-zero group.\nVersion 4.2 added a \" \" exception for a group of all ASCII [space](https://bliptext.com/articles/space-punctuation) characters (0x20202020).\n\n## ZMODEM version\n\"ZMODEM Pack-7 encoding\" encodes groups of 4 octets into groups of 5 printable ASCII characters in a similar, or possibly in the same way as Ascii85 does.\nWhen a [ZMODEM](https://bliptext.com/articles/zmodem) program sends pre-compressed 8-bit data files over [7-bit data channels](https://bliptext.com/articles/8-bit-clean), it uses \"[ZMODEM](https://bliptext.com/articles/zmodem) Pack-7 encoding\".\n\n## Adobe version\nAdobe adopted the basic btoa encoding, but with slight changes, and gave it the name Ascii85.\nThe characters used are the ASCII characters 33 through 117 inclusive (to represent the base-85 digits 0 through 84), together with the letter (as a special case to represent a 32-bit 0 value), and white space is ignored.\nAdobe uses the delimiter \" \" to mark the end of an Ascii85-encoded string and represents the length by truncating the final group: If the last block of source bytes contains fewer than 4 bytes, the block is padded with up to 3 null bytes before encoding.\nAfter encoding, as many bytes as were added as padding are removed from the end of the output.\nThe reverse is applied when decoding: The last block is padded to 5 bytes with the Ascii85 character, and as many bytes as were added as padding are omitted from the end of the output (see example).\nThe padding is not arbitrary.\nConverting from binary to base 64 only regroups bits and does not change them or their order (a high bit in binary does not affect the low bits in the base64 representation).\nIn converting a binary number to base85 (85 is not a power of two) high bits do affect the low order base85 digits and conversely.\nPadding the binary low (with zero bits) while encoding and padding the base85 value high (with s) in decoding assures that the high order bits are preserved (the zero padding in the binary gives enough room so that a small addition is trapped and there is no \"carry\" to the high bits).\n In Ascii85-encoded blocks, whitespace and line-break characters may be present anywhere, including in the middle of a 5-character block, but they must be silently ignored.\nAdobe's specification does not support the exception.\n\n## Example for Ascii85\nA quote from [Thomas Hobbes's](https://bliptext.com/articles/thomas-hobbes) [Leviathan](https://bliptext.com/articles/leviathan-hobbes-book):\nIf this is initially encoded using US-ASCII, it can be reencoded in Ascii85 as follows:\n9jqo^BlbD-BleB1DJ+*+F(f,q/0JhKFCj@.4Gp$d7F!,L7@<6@)/0JDEF@3BB/F*&OCAfu2/AKYi( DIb:@FD,*)+C]U=@3BN#EcYf8ATD3s@q?d$AftVqCh[NqF-FD5W8ARlolDIal( DIdu D.RTpAKYo'+CT/5+Cei#DII?(E,9)oF*2M7/c\nSince the last 4-tuple is incomplete, it must be padded with three zero bytes:\nSince three bytes of padding had to be added, the three final characters 'YkO' are omitted from the output.\nDecoding is done inversely, except that the last 5-tuple is padded with 'u' characters:\nSince the input had to be padded with three 'u' bytes, the last three bytes of the output are ignored and we end up with the original period.\nThe input sentence does not contain 4 consecutive zero bytes, so the example does not show the use of the 'z' abbreviation.\n\n## Compatibility\nThe Ascii85 encoding is compatible with 7-bit and 8-bit [MIME](https://bliptext.com/articles/mime), while having less overhead than [Base64](https://bliptext.com/articles/base64).\nOne potential compatibility issue of Ascii85 is that some of the characters it uses are significant in markup languages such as [XML](https://bliptext.com/articles/xml) or [SGML](https://bliptext.com/articles/sgml).\nTo include ascii85 data in these documents, it may be necessary to escape the [quote](https://bliptext.com/articles/quotation-mark), [angle brackets](https://bliptext.com/articles/bracket), and [ampersands](https://bliptext.com/articles/ampersand).\n\n# RFC 1924 version\nPublished on [April 1, 1996](https://bliptext.com/articles/april-fools-day-request-for-comments), informational : \"A Compact Representation of [IPv6](https://bliptext.com/articles/ipv6) Addresses\" by [Robert Elz](https://bliptext.com/articles/kevin-robert-elz) suggests a base-85 encoding of [IPv6](https://bliptext.com/articles/ipv6) addresses as an [April Fools' Day](https://bliptext.com/articles/april-fools-day) joke.\nThis differs from the scheme used above in that he proposes a different set of 85 ASCII characters, and proposes to do all arithmetic on the 128-bit number, converting it to a single 20-digit base-85 number (internal whitespace not allowed), rather than breaking it into four 32-bit groups.\nThe proposed character set is, in order, –, – , – , and then the 23 characters.\nThe highest possible representable address, 2128−1 = 74×8519 + 53×8518 + 5×8517 + ..., would be encoded as.\nThis character set excludes the characters, making it suitable for use in [JSON](https://bliptext.com/articles/json) strings (where and would require escaping).\nHowever, for SGML-based protocols, notably including XML, string escapes may still be required (to accommodate, and ).","current_revision":null,"created_by":"kACnuQmH5k9Nr5VNVEpVeg7XpvUmMctD","created_at":"2025-01-25T21:27:27.394Z","updated_at":"2025-01-25T21:27:27.394Z","search_vector":"'ascii85':1","search_content":" \n \n\n# \n**Ascii85**, also called **Base85**, is a form of [binary-to-text encoding](https://bliptext.com/articles/binary-to-text-encoding) developed by Paul E. Rutter for the [btoa](https://bliptext.com/articles/btoa) utility.\nBy using five [ASCII](https://bliptext.com/articles/ascii) characters to represent four bytes of [binary data](https://bliptext.com/articles/binary-data) (making the encoded size 1⁄4 larger than the original, assuming eight bits per [ASCII](https://bliptext.com/articles/ascii) character), it is more efficient than [uuencode](https://bliptext.com/articles/uuencode) or [Base64](https://bliptext.com/articles/base64), which use four characters to represent three bytes of data (1⁄3 increase, assuming eight bits per [ASCII](https://bliptext.com/articles/ascii) character).\nIts main modern uses are in [Adobe](https://bliptext.com/articles/adobe-systems)'s [PostScript](https://bliptext.com/articles/postscript) and [Portable Document Format](https://bliptext.com/articles/portable-document-format) file formats, as well as in the [patch](https://bliptext.com/articles/patch-unix) encoding for [binary files](https://bliptext.com/articles/binary-file) used by [Git](https://bliptext.com/articles/git).\n\n# Overview\nThe basic need for a binary-to-text encoding comes from a need to communicate arbitrary [binary data](https://bliptext.com/articles/binary-data) over preexisting [communications protocols](https://bliptext.com/articles/communications-protocol) that were designed to carry only English language [human-readable](https://bliptext.com/articles/human-readable) text.\nThose communication protocols may only be 7-bit safe (and within that avoid certain ASCII control codes), and may require [line breaks](https://bliptext.com/articles/line-break-computing) at certain maximum intervals, and may not maintain [whitespace](https://bliptext.com/articles/whitespace-computer-science).\nThus, only the 94 [printable ASCII characters](https://bliptext.com/articles/ascii) are \"safe\" to use to convey data.\nEighty-five is the minimum integer value of n such that n5 ≥ 2564; so any sequence of 4 bytes can be encoded as 5 symbols, as long as at least 85 distinct symbols are available.\n(Five [radix](https://bliptext.com/articles/radix)-85 digits can represent the integers from 0 to 4,437,053,124 inclusive, which suffice to represent all 4,294,967,296 possible 4-byte sequences.)\n\n# Encoding\nWhen encoding, each group of 4 bytes is taken as a 32-bit binary number, most significant byte first (Ascii85 uses a [big-endian](https://bliptext.com/articles/big-endian) convention).\nThis is converted, by repeatedly dividing by 85 and taking the remainder, into 5 radix-85 digits.\nThen each digit (again, most significant first) is encoded as an ASCII printable character by adding 33 to it, giving the ASCII characters 33 through 117.\nBecause all-zero data is quite common, an exception is made for the sake of [data compression](https://bliptext.com/articles/data-compression), and an all-zero group is encoded as a single character instead of.\nGroups of characters that decode to a value greater than 232 − 1 (encoded as ) will cause a decoding error, as will characters in the middle of a group.\nWhite space between the characters is ignored and may occur anywhere to accommodate line-length limitations.\n\n# Limitations\nThe original specification only allows a stream that is a multiple of 4 bytes to be encoded.\nEncoded data may contain [characters](https://bliptext.com/articles/escape-character) that have special meaning in many programming languages and in some text-based protocols, such as left-angle-bracket, backslash , and the single and double quotes &.\nOther base-85 encodings like Z85 and are designed to be safe in source code.\n\n# History\n\n## btoa version\nThe original btoa program always encoded full groups (padding the source as necessary), with a prefix line of \"xbtoa Begin\", and suffix line of \"xbtoa End\", followed by the original file length (in decimal and [hexadecimal](https://bliptext.com/articles/hexadecimal)) and three 32-bit [checksums](https://bliptext.com/articles/checksum).\nThe decoder needs to use the file length to see how much of the group was padding.\nThe initial proposal for btoa encoding used an encoding alphabet starting at the ASCII space character through \"t\" inclusive, but this was replaced with an encoding alphabet of \"!\"\nto \"u\" to avoid \"problems with some mailers (stripping off trailing blanks)\".\nThis program also introduced the special \" \" short form for an all-zero group.\nVersion 4.2 added a \" \" exception for a group of all ASCII [space](https://bliptext.com/articles/space-punctuation) characters (0x20202020).\n\n## ZMODEM version\n\"ZMODEM Pack-7 encoding\" encodes groups of 4 octets into groups of 5 printable ASCII characters in a similar, or possibly in the same way as Ascii85 does.\nWhen a [ZMODEM](https://bliptext.com/articles/zmodem) program sends pre-compressed 8-bit data files over [7-bit data channels](https://bliptext.com/articles/8-bit-clean), it uses \"[ZMODEM](https://bliptext.com/articles/zmodem) Pack-7 encoding\".\n\n## Adobe version\nAdobe adopted the basic btoa encoding, but with slight changes, and gave it the name Ascii85.\nThe characters used are the ASCII characters 33 through 117 inclusive (to represent the base-85 digits 0 through 84), together with the letter (as a special case to represent a 32-bit 0 value), and white space is ignored.\nAdobe uses the delimiter \" \" to mark the end of an Ascii85-encoded string and represents the length by truncating the final group: If the last block of source bytes contains fewer than 4 bytes, the block is padded with up to 3 null bytes before encoding.\nAfter encoding, as many bytes as were added as padding are removed from the end of the output.\nThe reverse is applied when decoding: The last block is padded to 5 bytes with the Ascii85 character, and as many bytes as were added as padding are omitted from the end of the output (see example).\nThe padding is not arbitrary.\nConverting from binary to base 64 only regroups bits and does not change them or their order (a high bit in binary does not affect the low bits in the base64 representation).\nIn converting a binary number to base85 (85 is not a power of two) high bits do affect the low order base85 digits and conversely.\nPadding the binary low (with zero bits) while encoding and padding the base85 value high (with s) in decoding assures that the high order bits are preserved (the zero padding in the binary gives enough room so that a small addition is trapped and there is no \"carry\" to the high bits).\n In Ascii85-encoded blocks, whitespace and line-break characters may be present anywhere, including in the middle of a 5-character block, but they must be silently ignored.\nAdobe's specification does not support the exception.\n\n## Example for Ascii85\nA quote from [Thomas Hobbes's](https://bliptext.com/articles/thomas-hobbes) [Leviathan](https://bliptext.com/articles/leviathan-hobbes-book):\nIf this is initially encoded using US-ASCII, it can be reencoded in Ascii85 as follows:\n9jqo^BlbD-BleB1DJ+*+F(f,q/0JhKF Cj@.4Gp$d7F!,L7@ @3BB/F*&OCAfu2/AKYi( DIb:@FD,*)+C]U=@3BN#EcYf8ATD3s@q?d$AftVqCh[NqF -FD5W8ARlolDIal( DId u D.RTpAKYo'+CT/5+Cei#DII?(E,9)oF*2M7/c\nSince the last 4-tuple is incomplete, it must be padded with three zero bytes:\nSince three bytes of padding had to be added, the three final characters 'YkO' are omitted from the output.\nDecoding is done inversely, except that the last 5-tuple is padded with 'u' characters:\nSince the input had to be padded with three 'u' bytes, the last three bytes of the output are ignored and we end up with the original period.\nThe input sentence does not contain 4 consecutive zero bytes, so the example does not show the use of the 'z' abbreviation.\n\n## Compatibility\nThe Ascii85 encoding is compatible with 7-bit and 8-bit [MIME](https://bliptext.com/articles/mime), while having less overhead than [Base64](https://bliptext.com/articles/base64).\nOne potential compatibility issue of Ascii85 is that some of the characters it uses are significant in markup languages such as [XML](https://bliptext.com/articles/xml) or [SGML](https://bliptext.com/articles/sgml).\nTo include ascii85 data in these documents, it may be necessary to escape the [quote](https://bliptext.com/articles/quotation-mark), [angle brackets](https://bliptext.com/articles/bracket), and [ampersands](https://bliptext.com/articles/ampersand).\n\n# RFC 1924 version\nPublished on [April 1, 1996](https://bliptext.com/articles/april-fools-day-request-for-comments), informational : \"A Compact Representation of [IPv6](https://bliptext.com/articles/ipv6) Addresses\" by [Robert Elz](https://bliptext.com/articles/kevin-robert-elz) suggests a base-85 encoding of [IPv6](https://bliptext.com/articles/ipv6) addresses as an [April Fools' Day](https://bliptext.com/articles/april-fools-day) joke.\nThis differs from the scheme used above in that he proposes a different set of 85 ASCII characters, and proposes to do all arithmetic on the 128-bit number, converting it to a single 20-digit base-85 number (internal whitespace not allowed), rather than breaking it into four 32-bit groups.\nThe proposed character set is, in order, –, – , – , and then the 23 characters.\nThe highest possible representable address, 2128−1 = 74×8519 + 53×8518 + 5×8517 + ..., would be encoded as.\nThis character set excludes the characters, making it suitable for use in [JSON](https://bliptext.com/articles/json) strings (where and would require escaping).\nHowever, for SGML-based protocols, notably including XML, string escapes may still be required (to accommodate, and ).","revisionCount":0},"hasMore":false,"nextCursor":null}