Live data from Hacker News

Parsing JSON is a Minefield

seriot.ch

161–170 of 301 posts

Re: Parsing JSON is a Minefield

#162
post #156
post #34

Earlier quoted context omitted.

Parsing HTML is literally orders of magnitude more complex. It is pretty rare to need to parse JSON yourself (what environment doesn't have that available?) but it isn't that difficult. It's a simple language.

what environment doesn't have that available? Autocad LISP is the one I ran into. At least it didn't 4 years ago. I'm sure there are other niche cases. Although I'll admit I punted and wrote a trivial 'parser' that was only able to read and write the particular JSON I was dealing with in that project.

Wouldn't be possible to write an external tool that converts JSON to s-expressions and vice-versa?

Re: Parsing JSON is a Minefield

#163
post #156

Earlier quoted context omitted.

what environment doesn't have that available? Autocad LISP is the one I ran into. At least it didn't 4 years ago. I'm sure there are other niche cases. Although I'll admit I punted and wrote a trivial 'parser' that was only able to read and write the particular JSON I was dealing with in that project.

Wouldn't be possible to write an external tool that converts JSON to s-expressions and vice-versa?

Sure, but then you're just adding additional layers to what was supposed to a fairly straight forward script. Much easier to just include everything in a single program so you can just say give path to input json file here, give name of output file here, and run.

Re: Parsing JSON is a Minefield

#164
post #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)

Similarly, Python's encoder violates the JSON specification by default, as it produces `Infinity`, `NaN` and `-NaN`, which other JSON parsers choke on.

Re: Parsing JSON is a Minefield

#165

> 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…

JSON with comments? How about { "object":{ "foo":1,"bar":"New Jersey"} , "_comment": "blah blah blah" }

A bit hackish, but always worked for me.

Re: Parsing JSON is a Minefield

#166
post #34
post #14

Well, first and most obviously, if you are thinking of rolling your own JSON parser, stop and seek medical attention. Secondly, assume that parsing your input will crash, so catch the error and have your application fail gracefully. This is the number one security issue I encounter in "security audited" PHP. (The second being the "==" vs. "===" debacle that is PHP comparison.) As one example, consider what happens wh…

Parsing HTML is literally orders of magnitude more complex. It is pretty rare to need to parse JSON yourself (what environment doesn't have that available?) but it isn't that difficult. It's a simple language.

Last time I worked on a FileMaker DB, it didn't have JSON support. I don't know if that has changed in the last few years.

Re: Parsing JSON is a Minefield

#167

If JSON is comparable to minefield, then I guess XML and ASN.1 are nothing short of nuclear Armageddon in complexity and ones ability to shoot themselves into the leg ;-)

Also, as someone who has written an XML parser, according to some of the comments in this threads I'm way beyond medical help, and should give up on life :).

Well, every person you spared from that experience owes you a beer...

Re: Parsing JSON is a Minefield

#168
post #34

Earlier quoted context omitted.

Parsing HTML is literally orders of magnitude more complex. It is pretty rare to need to parse JSON yourself (what environment doesn't have that available?) but it isn't that difficult. It's a simple language.

Silent moment for those of us using niche languages to meet production requirements in environments that do not allow third-party code and do not have JSON parsing in the std lib...

If you don't have a solution, or you're not happy with your current solution, take a look at parsec style parsing. you can make a lot of progress with just a few combinators, and those style parsers are pretty easy to read.

You can get an implementation working with a fairly high level of confidence that it's right.

If it's not fast enough, make a pretty printer for your AST. Then do a CPS transform (by hand) on your library and parser, so you can make the stack explicit. Make sure the transformed version pretty prints exactly the same way.

Then make a third version that prints out the code that should run when parsing a document, rather than doing the parsing directly. You'll get a big case switch for each grammar you want to parse. Your pretty printer will help you find many bugs.

It's a pretty achievable path to get your grammar correct, and then get a specialized parser for it.

Re: Parsing JSON is a Minefield

#169

Am I wrong in seeing that PHP seems to fail the least weirdly in the full results?

It's more complicated in practice. Prior to PHP 7.0, the official JSON extension was replaced with a completely different one in many distributions due to licensing issues, and since PHP 7.0, PHP's official JSON extension is yet another completely different implementation.

Re: Parsing JSON is a Minefield

#170
post #48

Wrote my own JSON parser ( https://github.com/MJPA/SimpleJSON ) a while ago... not sure how it's a minefield unless I'm missing something?

Perhaps you'd be interested to know that your JSONDemo program fails the following tests: hang: y_number_huge_exp.json segfault: n_structure_100000_opening_arrays.json n_structure_open_array_object.json fail: n_number_then_00.json n_string_unescaped_tab.json n_structure_capitalized_True.json

I would :)

Was going to run the tests myself later but needed a box with python3 on it!

Post reply on HN