Base85 (Ascii85) encode and decode functionality
Want to see pretty graphs? Log in now!
npm install base85
|16||downloads in the last week|
|49||downloads in the last month|
|Last Published By|
|Version||1.1.0 last updated 11 days ago|
|Keywords||base85, ascii85, encode, decode, binary-to-text|
Simple utility to manage base85. Where base64 adds approximately 1/3,
base85 only adds about 1/4. 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 Ascii85 specification contains
") which needs escaping in many programming languages,
and the ZeroMQ specification contains
> which need escaping
in most (all?) SGML languages.
Supported encoding specifications
npm install base85
var base85 = require('base85'); console.log(base85.encode('Hello, world!')); // 'nm=QNz.92Pz/PV8aP' console.log(base85.encode('Hello, world!', 'ascii85')); // ' <~87cURD_*#TDfTZ)+T~>'
var base85 = require('base85'); var decoded = base85.decode('vqG:5Cw?IqayPd#az#9uAbn%daz>L5wPF#evpK6}vix96y?$k6z*q'); console.log(decoded.toString('utf8')); // 'all work and no play makes jack a dull boy'
Doesn't support the z-abbreviation for Ascii85. This means that data encoded with this
support will cause the library to return false. An all-zero input buffer will be encoded
<~!!!!!~>, rather than
Doesn't support IPv6 encoding specification (RFC1924) for now. This baby requires requires 128-bit arithmetic, which is rather problematic. I'm thrilled to see that the author of the RFC took this in consideration, specifically - quote from the RFC: "This is not considered a serious drawback in the representation, but a flaw of the processor designs." Silly processor designers.
Encodes the specified data. If encoding is
ascii85, the encoded data will be prepended with
<~and appended with
data The data to encode, may be a
Stringor a Buffer.
Stringwith the encoded data.
Decodes the specified data. If encoding is
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.
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() utility.
data The data to decode. May be a
Stringor a Buffer. Expected to be enclosed in