This blog post describes a bug in a common usage pattern of JSON:
http://timelessrepo.com/json-isnt-a-javascript-subset
That is, there are some characters which are legal in JSON
serializations, but not in JavaScript strings.
This works OK for JSON parsers, but a common use case of JSON is
JSONP, where the result of a request is presumed to be executable
javascript:
<script src="http://someapi.com/jsonp?callback=foo"> might return a response:
foo({"some_json":"which might or might not be legal javascript"})
The post also suggests a solution -- to replace literal U+2028 - Line
separator and U+2029 - Paragraph separator with their escape sequences
\u2028 and \u2029.
This is a nice solution in that it makes the JSON valid JS while
keeping the same semantics. Of course there's the annoyance of
processing the full string, comparable in overhead to utf-8 encoding,
I presume.
So, to start with, is there a maintainer for the json module, or how
should I go about discussing implementing this solution?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4