Parsing JSON is a Minefield
seriot.ch
Parsing JSON is a Minefield
1–10 of 301 posts
Re: Parsing JSON is a Minefield
#2I still love JSON regardless :) Client / server side languages have first class support for serialization and in most cases the data structures are rather easy.
I'd be very skeptical if one would suggest an alternative format for a web based project, however I can imagine such situations.
Re: Parsing JSON is a Minefield
#3> In conclusion, JSON is not a data format you can rely on blindly.
That was definitely not my take-away from the article. More like "JSON is not a data format you can rely on blindly if you are using an esoteric edge-case and/or an alpha-stage parsing library." I haven't ever run into a single JSON issue that wasn't due to my own fat fingers or trying to serialize data that would have been better suited to something like BSON.
Re: Parsing JSON is a Minefield
#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.
Re: Parsing JSON is a Minefield
#5> 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.
In my personal experience TOML works really well. It's a little reminiscent of .ini files, but definitely is better.
Re: Parsing JSON is a Minefield
#6> 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.
YAML or TSV depending on whether your configuration looks like a rectangular table.
If you want extreme flexibility using C++ as the main language, take a look at my project: https://github.com/jzwinck/pccl
It lets you configure your C++ apps using Python. Config items can even be Python functions.
Re: Parsing JSON is a Minefield
#7> 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.
Re: Parsing JSON is a Minefield
#8> 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.
I don't have a specific recommendation, but when I see a project uses a JSON file as configuration, I wonder: "hasn't the author ever needed to include a comment in the configuration ?".
Re: Parsing JSON is a Minefield
#9> 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 standard for json-with-comments. JSONC or whatever, but it should have a different standard filename and it should have an RFC dictating what is and isn't allowed. Personally I would allow only // comments because there are too many subtle issues with C-style comments, but it may be too late to agree on that.
Half the point of JSON is that if application A stores its data as JSON then application B can parse that without any nasty surprises. Except, there are now probably thousands of noncompliant implementations in the wild that only exist because the standard doesn't allow comments. Each one of those standards adds subtle differences (in addition to the comments themselves) depending largely on how they remove the comments before passing to the standards-compliant JSON parser (assuming they do that, which being DC's recommended approach, is as close to a standard as currently exists).
Re: Parsing JSON is a Minefield
#10"NaN and Infinity"
Yeah. And I learned this the hard way with the Perl module JSON::XS. It successfully encodes a Perl NaN, but its decoder will choke on that JSON. (Reported it to the maintainer who insists that is consistent with the documentation and wouldn't fix it)