Hacker News Reader

Comment by dullcrisp | Hacker News Reader

It looks like they’re counting on most data being padded to 32 bits. The simplicity due to lack of padding rules seems to be the only real advantage this encoding has over base 64. Otherwise you’re right, offering up a new standard because there are too many competing base 64 standards makes no sense.

View on HN

All the issues mentioned in these comments is a good indication why this encoding isn't more widely known/used.

I myself typically binary compress then base64 encode.

Good to know I'm not the only one who has done this! I once wrote a template generation tool that embedded its input configuration into its output files as base64-encoded gzip'd JSON. Worked quite well at allowing template regeneration.

For your trouble, you save some extra bytes with 85 vs 64.

With the added bonus of funny characters which are a pain to encode in JSON, XML and URLs. I guess I'll keep using using URL safe Base64, thank you.

Modifying the base alphabet is simple if there are a couple of problem characters.

I use 85 in json just fine without escaping overhead. Never tried for URLs or XML.

and then the webserver probably recompresses again via gzip.

>The simplicity due to lack of padding rules seems to be the only real advantage

Because there is no padding rule given, it's impossible to use the standard to encode most binary strings.

For example, how would you encode/decode these?

  0x0000000000000000  
  0x00000000000000
  0x000000000000
  0x0000000000
  0x00000000 
  0x000000

If the situation requires decoding strings of unknown length, you simply prefix the length.

It was rhetorical question. What you describe is not defined in the format. You can't use the format to exchange strings of unknown length.

If people would start using this encoding, different users would adopt different solutions padding, length prefixes etc. and it becomes mess.

It's not defined in the format, sure. That doesn't mean the format is bad. The format also doesn't specify how to interpret the binary data, or how to encode multiple strings, or automatically checksum it for you. But you can obviously use the format to exchange strings of variable length, or encode both integers and images, send multiple strings, or add your own checksum.

It's not "impossible to encode" that content just because you need to decide how to represent it. It's not "a mess" if some people use fixed-length strings and some use length-prefixed strings. It's just reality for any encoding scheme - you build layers around it, according to how you want to use it.

The same way the context of your software determines whether this binary string is supposed to represent a float, a name, a hash, or a pixel-art masterpiece, it will also determine the appropriate serialization.

You could only encode the ones whose length was a multiple of 8. 0x00000000 would be 00000. 0x0000000000000000 would be 00000 00000. How would you encode binary 000000 in hex?

"Hex(adecimal)" is not an encoding scheme, it's a number basis. "Binary 00000" as a number is just zero, which is written equivalently as "0", "00"... in hexadecimal. This is different from a chunk of data consisting of six bits that all happen to be zero. And indeed, you need to decide on how to convey that, and simply saying "hex" - or "binary" or "decimal" for that matter - is not enough, that is correct.

Reply on news.ycombinator.com