StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Piskvor's right, base64-encoded-anything is longer than raw. You base64-encode something to get it down a channel with a limited character repertoire, not as a means of reducing size.</p> <p>Perhaps the question should be: Is Base64-encoded BSON smaller then <strong>JSON</strong>?</p> <p>If so then JSON-vs-BSON is very much dependent on the content. For example arbitrary floating point numbers like <code>1.2345678901234567</code> are more efficiently stored in 8 binary bytes in BSON than the JSON string digit version. But the more common numbers like, say, <code>1</code>, are much more efficiently stored as strings in JSON.</p> <p>For string values, BSON loses 4 bytes for a length word, but gets some back for every <code>"</code> and <code>\</code> JSON has to escape, plus more in strings with control characters where JSON has to use a hex sequence. (Some JSON encoders also <code>\u</code>-escape every non-ASCII character to ensure safe transmission regardless of character set.)</p> <p>IMO: BSON does not have a big compactness advantage over JSON in general. Its strength lies more in simplicity of decoding in a low-level language, plus datatypes JavaScript doesn't have. It can have marginal advantages for binary strings and a few other cases; it's certainly worth checking for a particular workload. But it's telling that the examples in the BSON specification itself are considerably smaller in JSON.</p> <p>As for base64-encoded BSON: the same, except 33% worse.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload