Hacker News Reader

Comment by deathanatos | Hacker News Reader

> And thus JSON can't... […] properly encode non-Latin text (no, — hexadecimal encoding is even worse than no encoding);

This is (RFC) valid JSON:

  "我喜欢吃鱼。"

Sure, JSON has some corner cases. Binary protocols can, and do, as well. While I'm sure that non-compliant JSON examples exist in the wild, I would think that overall they're exceedingly rare compared to compliant ones.

And if you don't like the limitations of JSON, extending the format for your particular use-case is a valid solution. (Though I would argue that going w/ a well-known format that already supports your needs is a more pragmatic one.)

View on HN

> This is (RFC) valid JSON:

You mean, "valid, according to the latest 2017 RFC". Such young RFC is still to raw, too immature to adopt, especially if it concerns data interchange formats. IPv6 was created in 1995, and it apparently still too young!

I fear, that a proper full-featured JSON spec, with comment support, mandatory UTF-8 and strict prohibition of hex-encoding won't be created and implemented by most JSON parsers till at least 2090. At that point the JSON format itself will likely become insufficiently hip for general use (just like XML suddenly stopped being hip enough in early 2000's).

> You mean, "valid, according to the latest 2017 RFC". Such young RFC is still to raw, too immature to adopt, especially if it concerns data interchange formats. IPv6 was created in 1995, and it apparently still too young!

No, I mean valid, according to the oldest, 2013 RFC and all later standards. Non-ASCII characters, encoded directly w/o escaping, have always been supported by JSON. (JSON comes from JavaScript's syntax, and it's legal there, too.)

> I fear, that a proper full-featured JSON spec, with comment support

Many of us use JSON as a language to exchange data, service to service. Comments do no good in that regard. JSON, even w/ comments, is not terribly friendly. I'd recommend TOML or YAML, depending on the situation.

> mandatory UTF-8

JSON is required to be encoded in one of the Unicode UTF encodings. So, it's not required to be UTF-8, but it's pretty close, and I don't think I've yet run across a JSON document that wasn't UTF-8.

> strict prohibition of hex-encoding

I don't think you'd really want this. (Particularly if you want human-friendly features, like comments…) In debug situations, certain non-printing characters are just easier to deal w/ if they're not printed, for example.

Reply on news.ycombinator.com