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