[
https://issues.apache.org/jira/browse/COUCHDB-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526855#comment-13526855
]
Paul Joseph Davis commented on COUCHDB-1624:
--------------------------------------------
So, if we rely on json.org's production that says "no control characters" then
technically speaking the 0xC293 breaks this definition as Unicode lists it as a
<control> code point. Although if we go back to RFC4627 and read its EBNF and
the description around strings, it specifically defines control characters as
U+0000 to U+001F which does not include the 0+0093 code point that's causing
issues.
Granted RFC4627 (and json.org's interpretation thereof) is always a bit light
on the details so this sort of gray area is unfortunately quite common. Given
that RFC4627 defines control characters explicitly and the fact that all of the
major parsers I've tested (Yajl, Ruby, Python) all accept this as valid JSON
I'm going to stick by calling it a bug in that Java JSON parser.
> CouchDB shouldn't accept or serve JSON with control-characters
> --------------------------------------------------------------
>
> Key: COUCHDB-1624
> URL: https://issues.apache.org/jira/browse/COUCHDB-1624
> Project: CouchDB
> Issue Type: Bug
> Affects Versions: 1.2
> Reporter: Nils Breunese
> Attachments: 10571721.json, Test.java
>
>
> According to http://www.json.org/ control-characters are not valid characters
> in JSON. Due to a character encoding bug one of our applications was sending
> JSON with control-characters to CouchDB. CouchDB happily accepts this
> (invalid) JSON and also serves it, but then we started getting problems in a
> client that uses the Svenson JSON library which (correctly) complains about
> invalid characters in the JSON served by CouchDB.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
