- From: Robin Berjon <robin@w3.org>
- Date: Mon, 03 Mar 2014 15:06:19 +0100
- To: Yehuda Katz <wycats@gmail.com>, Jonathan Kelly <jonathank.kelly@gmail.com>
- CC: "public-nextweb@w3.org" <public-nextweb@w3.org>
On 25/02/2014 20:07 , Yehuda Katz wrote: > Rails actually already supports JSON parameters. In general, it uses > `accept-charset` on the client to force the browser to give it UTF-8 > (trying to figure out and transcode other encodings is a huge headache; > I did most of this work in Rails 3, and `accept-charset` was like manna > from heaven). Yes, processing forms before encodings were supported as they are today was a nightmare. It was common to include a canary and try to figure out what encoding deformation had been applied to all of one's data by looking at what was wrong with the canary. > Ideally, it would be sent as a Content-Type > "application/json;charset=utf-8" when provided an `accept-charset` of > "utf-8". I *believe* that if this was how it worked, existing Rails > would work out of the box. I can't speak for other server-side frameworks. That is unnecessary (and also a violation of the JSON RFC: application/json does not support parameters). By defining the application/json enctype such that it is always UTF8 the need to ever care about UTF-8, ever, goes away. -- Robin Berjon - http://berjon.com/ - @robinberjon
Received on Monday, 3 March 2014 14:06:28 UTC