Why would a JSON file be GBs in size? I think that's the more interesting question.
Because it has GBs of data? There's no size limit on JSON.
Parsing malformed JSON
31–40 of 57 posts
Re: Parsing malformed JSON
#32Earlier quoted context omitted.
I've written a relatively popular Atom/RSS feed parser for Go [0]. I struggled with this very issue but I ultimately ended up attempting to be robust against out-of-spec feeds. A super strict feed parsing library is less useful than one that can successfully parse certain classes of broken feeds. It is a fine line to walk -- I won't add a great deal of complexity to support overly broken feeds, but if it is relativel…
Nothing new under the sun: http://www.xml.com/pub/a/2003/01/22/dive-into-xml.html
I read those threads while I was first starting to write my parser.
I found it interesting, if you look in the thread you'll see that this was a big disagreement between Pilgrim and Aaron Swartz.
Re: Parsing malformed JSON
#33Please don't do things like this. It only encourages people to be lazy about producing conforming documents, and different parsers that try to compensate for syntax errors are going to do so in different ways. We learnt this the hard way with HTML.
Re: Parsing malformed JSON
#34Should you really assume malformed JSON is even correct?
Re: Parsing malformed JSON
#35This reminds me "Parsing JSON is a minefield" post a few weeks ago, TL;DR, JSON is not standardized or (having multiple standards) making parsing / validating JSON data very tricky in edge cases. https://news.ycombinator.com/item?id=12796556
What are the multiple standards of JSON? I am only aware of one standard; it is the implementations that are the problem.
Re: Parsing malformed JSON
#36Earlier quoted context omitted.
I've written a relatively popular Atom/RSS feed parser for Go [0]. I struggled with this very issue but I ultimately ended up attempting to be robust against out-of-spec feeds. A super strict feed parsing library is less useful than one that can successfully parse certain classes of broken feeds. It is a fine line to walk -- I won't add a great deal of complexity to support overly broken feeds, but if it is relativel…
I'm doing this with WebDAV too. When I come across a bug that's clearly an implementation problem I weigh how prevalent the software is, how likely they will be able to fix it and if possible I add a user-agent specific workaround so new clients can't rely on the same bug with my server.
But then we add the IE-nightmare of using an accepted user-agent in a new product to workaround cases like this
Re: Parsing malformed JSON
#37This reminds me "Parsing JSON is a minefield" post a few weeks ago, TL;DR, JSON is not standardized or (having multiple standards) making parsing / validating JSON data very tricky in edge cases. https://news.ycombinator.com/item?id=12796556
What are the multiple standards of JSON? I am only aware of one standard; it is the implementations that are the problem.
Read the original article that I linked in the HN discussion, skip through to the section where it says "Yet JSON is defined in at least six different documents". You're welcome.
Re: Parsing malformed JSON
#38i don't get malformed json, i tell the sender to re-send data as json
Re: Parsing malformed JSON
#39JSON should have a nicer way of dealing with double quotes in data. That would avoid many encoding mistakes.
> JSON should have a nicer way of dealing with double quotes in data. That would avoid many encoding mistakes.
So you update the standard to this nicer way of dealing with double quotes, and now people forget to indicate whether they're using the nice new way or the ugly old way, or they mix the two approaches ….
Re: Parsing malformed JSON
#40This reminds me "Parsing JSON is a minefield" post a few weeks ago, TL;DR, JSON is not standardized or (having multiple standards) making parsing / validating JSON data very tricky in edge cases. https://news.ycombinator.com/item?id=12796556
[deleted]