Where base64 adds approximately 1/3Base64, base85 only adds about 1/4Base85. Of course there's a tradeoff. The Base85 alphabet includes characters that might not be as friendly as the base64 alphabet. While it's still only printable characters, the Ascii85Base85 specification contains quotes (
") which needs escaping in many programming languages, and the ZeroMQBase85ZeroMQ specification contains
>which need escaping in most (all?) SGMLSGML languages.
IPv6 encoding should only be used for encoding IPv6 addresses. When using IPv6, input for encoding must always be 16 bytes, and input for decoding must always be 20 bytes.
ZeroMQ's version (
z85) require according to the specificationBase85ZeroMQ) string input to be divisible by 5, and binary input to be divisible by 4.
Supported encoding specifications
Ascii85Base85 ZeroMQBase85ZeroMQ IPv6Base85IPv6
npm install base85
var base85 = require('base85'); var z85 = base85.encode('Hello, world!!!!'); console.log(z85); // nm=QNz.92Pz/PV8aT50L
var base85 = require('base85'); var decoded = base85.decode('vqG:5Cw?IqayPd#az#9uAbn%daz>L5wPF#evpK6}vix96y?$k6z*rGH'); console.log(decoded.toString('utf8')); // all work and no play makes jack a dull boy!!
IPv6 (RFC1924Base85IPv6), can take any correctly formatted IPv6 address:
var base85 = require('base85'); var ipv6 = base85.encode('2001:db8:100:f101::1', 'ipv6'); console.log(ipv6); // 9R}vSQZ1W=8fRv3*HAqn var decoded = base85.decode('9R}vSQZ1W=8fRv3*HAqn', 'ipv6'); console.log(decoded); // 2001:db8:100:f101::1
encode(data [, encoding])
Encodes the specified data. If encoding is>> The data to encode, may be a
ascii85, the encoded data will be prepended with
<~and appended with
Stringor a BufferNodeBuffer.
encoding>> Which specification to use when encoding
data. Valid values are: >>
ipv6. Default is
z85. >> >> For
datais a buffer, it is expected to be the binary representation >> of an IPv6 address (16 bytes). It cannot be a textual representation. If it is a string, >> it can be on any valid IPv6 form (e.g.
1080:0:0:0:8:800:200c:417a, >> parsing is done using ip-addressIPAddress).
Stringwith the encoded data.
decode(data [, encoding])
Decodes the specified data. If encoding is>> The data to decode. May be a
ascii85, the data is expected to start with
<~and and end with
~>. No checks are actually made for this, but output will be unexpected if this is not the case. If encoding is
ipv6, the length of data must be exactly 20 bytes.
ipv6encoding cannot be used with arbitrary data.
A buffer is always returned as data may not be representable in a string. If you know it is, you can easily convert it to a string using the Buffer.toString()NodeBufferToString utility.
Stringor a BufferNodeBuffer. >> If
ascii85, it is expected to be enclosed in
encoding>> Which specification
datais encoded with. Valid values are: >>
ipv6. Default is
returns>> A BufferNodeBuffer With the decoded data, or boolean
false>> if the buffer could not be decoded. When testing if the result succeeded, >> always use operators with 3 charactersJSCompare ('===' or '!==').
Which specification to use?
>are part of the alphabet. But then again, Ascii85 has that as well.
Ascii85 appears to be the most used of the base85 specifications however. As for why completely eludes me. This may very well be the only reason to pick Ascii85.
If you control both decoding and encoding side, use ZeroMQ.
If you need interoperability with Ascii85, use that.
As IPv6 encoding only supports exactly 128 bits (16 bytes), this is not very useful for arbitrary data. Only use IPv6 if you're actually encoding IPv6 addresses.