Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Parsing JSON is a Minefield

seriot.ch

Post reply on HN
Print view View original

41–50 of 301 posts

Re: Parsing JSON is a Minefield

#42

Post by lucb1e »

gt2 wrote: post #26
newsat13 wrote: post #22

Anyone else seeing forbidden? Forbidden You don't have permission to access to this document on this server.

yes, same here

You are not the only ones, but it works for me. Google cache link is posted elsewhere in the thread: https://news.ycombinator.com/item?id=12797047

Re: Parsing JSON is a Minefield

#43

Post by inimino »

amelius wrote: post #30

One of the biggest flaws of JSON is that it doesn't support "undefined". This makes translating Javascript structures to and from JSON actually not preserve the original value. Sigh.

There are lots of reasons beyond this one why arbitrary JS values can't roundtrip through JSON. This is a conscious design decision, not an oversight.

Re: Parsing JSON is a Minefield

#44

Post by lucb1e »

indexerror wrote: post #4

> In conclusion, JSON is not a data format you can rely on blindly. What does HN suggest for configuration files (to be written by a human essentially)? I am looking at YAML and TOML. My experience with JSON based config files was horrible.

> What does HN suggest for configuration files (to be written by a human essentially)?

JSON.

YAML confuses many people by being whitespace-sensitive; ini files I find too limited.

Re: Parsing JSON is a Minefield

#45

Post by tantalor »

indexerror wrote: post #4

> In conclusion, JSON is not a data format you can rely on blindly. What does HN suggest for configuration files (to be written by a human essentially)? I am looking at YAML and TOML. My experience with JSON based config files was horrible.

Protocol Buffers text format: https://developers.google.com/protocol-buffers/docs/overview...

Re: Parsing JSON is a Minefield

#46

Post by inimino »

lucb1e wrote: post #31
andrewvijay wrote: post #28

Bad thing to read when I'm writing a sass to json module

The encoding takeaway seems simple: escape everything with \uxxxx characters that is outside of the ASCII range /[ -~]/ (regex) and you'll be pretty much fine. Set the encoder to utf-8, don't leave [dangling,commas,], and a few other things that are obvious from json.org.

Escaping everything outside of ASCII is terribly human-unfriendly and wasteful in bytes as well.

Re: Parsing JSON is a Minefield

#50

Post by DonHopkins »

robert_tweed wrote: post #9
indexerror wrote: post #4

> In conclusion, JSON is not a data format you can rely on blindly. What does HN suggest for configuration files (to be written by a human essentially)? I am looking at YAML and TOML. My experience with JSON based config files was horrible.

Funnily enough, as I've been experimenting with Chef and trying to stick to JSON config files where allowed, I was again struck that (a) it's not a good choice for config files (b) it's an OK choice though (c) lots of people are using it anyway (d) nearly everyone that does so (including Chef) allows comments, so in reality are not actually using JSON at all. Point (d) is the important one. I really think we need a s…

Reflecting the great tradition of "C++", I hereby propose calling it "//JSON".
Post reply on HN