This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author cvrebert
Recipients Julian, akira, cvrebert, ezio.melotti, jleedev, ncoghlan, pitrou, rhettinger, serhiy.storchaka, vstinner
Date 2014-05-16.04:20:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1400214011.78.0.403321149039.issue17909@psf.upfronthosting.co.za>
In-reply-to
Content
I agree that the state of encoding detection in the new RFC seems unclear, given that the old RFC prefaced the part about the encoding detection with:
> Since the first two characters of a JSON text will always be ASCII
> characters

But in the new RFC:
> Appendix A.  Changes from RFC 4627
[...]
>    o  Changed the definition of "JSON text" so that it can be any JSON
>       value, removing the constraint that it be an object or array.

Thus,
> "ಠ_ಠ"
whose 2nd character is decidedly non-ASCII, is now a valid JSON text (i.e. standalone JSON document).

There seems to have been a thread about encoding detection in the RFC 7159 working group, but I don't have the time to read through it all:

> Re: [Json] JSON: remove gap between Ecma-404 and IETF draft
> http://www.ietf.org/mail-archive/web/json/current/msg01936.html

It eventually leads to a dedicated sub-thread:

> [Json] Encoding detection (Was: Re: JSON: remove gap between Ecma-404 and IETF draft)
> http://www.ietf.org/mail-archive/web/json/current/msg01959.html
History
Date User Action Args
2014-05-16 04:20:11cvrebertsetrecipients: + cvrebert, rhettinger, ncoghlan, pitrou, vstinner, ezio.melotti, akira, Julian, serhiy.storchaka, jleedev
2014-05-16 04:20:11cvrebertsetmessageid: <1400214011.78.0.403321149039.issue17909@psf.upfronthosting.co.za>
2014-05-16 04:20:11cvrebertlinkissue17909 messages
2014-05-16 04:20:10cvrebertcreate