Define string vs base32 vs base64

[DonaldTsang]

Might be a good idea to have a YAML !!str to !!binary (binary as in base64) equivalent.
Base64 should be standardized to be HTML and JSON safe, either RFC 4648 §5 (- and _) or, next best option, RFC 4648 + and / (might cause issues with comments if there are double slash in the data).
base32 should be either Crockford's, or second best, RFC 4648 (more confusable characters).

[jordanbtucker]

What benefit does this have over storing Base64 encoded data in a string?

[DonaldTsang]

@jordanbtucker it IS base64 in a string, just that we need some kind of "flag" or "header" to note is as such.

[DonaldTsang]

Just a note: We are not even considering

• 32-bit base85 0.99 (standardized "somewhat")
• 128-bit base69 0.95 (more efficient than base64)
• 256-bit base76 0.97 (more efficient than base64)

since these are more niche formats for packing more data than base64

[jordanbtucker]

How would you implement this in an ES5 compatible way?

[DonaldTsang]

@jordanbtucker perhaps instead of "string" maybe ["format", "string"] ? I think "octet-stream" is a common flag as well?

[jordanbtucker]

I still don't understand. Can you give a full example of a JSON5 document that uses your proposed feature?

[DonaldTsang]

Here is an example in standard JSON with base64 encoding

{
    "mimetype" : "application/octet-stream",
    "metadata" : [ ],
    "value" :   "TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFzb24sIGJ1dCBieSB0aGlz
    IHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3aGljaCBpcyBhIGx1c3Qgb2Yg
    dGhlIG1pbmQsIHRoYXQgYnkgYSBwZXJzZXZlcmFuY2Ugb2YgZGVsaWdodCBpbiB0aGUgY29udGlu
    dWVkIGFuZCBpbmRlZmF0aWdhYmxlIGdlbmVyYXRpb24gb2Yga25vd2xlZGdlLCBleGNlZWRzIHRo
    ZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm5hbCBwbGVhc3VyZS4=",
}

Surly there could be a way for JSON5 to trim the fat and make base64 object wrappers "shorter"?

[jordanbtucker]

Yes, there could be a way for JSON5 to make this shorter, but why? Why isn't your example good enough?

[DonaldTsang]

Too many characters or too clunky (my first thought)? if I can design my syntax then s"base64string" or something where the first s is the flag of the string? And the same can be applied to different encodings or something? Maybe it is too much complexity?

[jordanbtucker]

This breaks ES5 compatibility.

[DonaldTsang]

What would be the most lightweight yet compatible way of labeling a string as base64 or some other common encoding?

[jordanbtucker]

You could encode the string like this:

'base64:SGVsbG8sIFdvcmxkIQ=='

Then use a recover function to parse it.

[DonaldTsang]

'b64:SGVsbG8sIFdvcmxkIQ==' looks even slimmer TBH, maybe we can write other compatibility documents outside the JSON5 standard (but by the JSON5 committee) to aid in designing API recommendations?

[zamicol]

JSON5 supports Hex in "0x" and "0X" forms, which is awesome:
https://github.com/json5/json5/blob/4cf57da675f55c619f959132eb58a5683ca4a9c7/lib/parse.js#L416

I wanted to confirm and explicitly state that JSON5 will never support base64 since it would break ES5 compatibility.

(I would not be in favor, just double checking to make sure.)

Thanks for all you do Jordan.

[jordanbtucker]

@zamicol I can confirm that there are no plans to include support for a Base64 literal value in JSON5. Please see #35 for a discussion on the recommended ways to represent binary data in a JSON5 document.