Re: [Json] Encoding detection (Was: Re: JSON: remove gap between Ecma-404 and IETF draft)

[Tim Bray <[e-mail]>]

I’ve been using JSON for quite a few years, but hardly ever in either a
to-browser or from-browser role; what I care about is mostly its use in
RESTful APIs generally and identity APIs specifically.  In those scenarios,
it would be seen as wildly inappropriate to use anything but UTF-8; I’ve
never actually seen anything else.  In practice, it would be very unlikely
for anyone to deploy UTF-16 or any other non-UTF-8 flavor in a non-browser
scenario.

Having said that, I’m still, hundreds of messages later, not 100% sure what
our draft should say about BOMs :(


On Fri, Nov 22, 2013 at 3:33 AM, Pete Cordell <[e-mail]>wrote:

> ----- Original Message From: "Henri Sivonen"
>
>  On Thu, Nov 21, 2013 at 3:39 PM, Anne van Kesteren <[e-mail]>
>> wrote:
>>
>>> XHR's responseType = "json" only supports UTF-8 (optionally with a
>>> leading BOM), across the board.
>>>
>>
>> Good point. I wrote the code that enforces that constraint, but I forgot.
>>
>> Well, there's an interoperability reason against UTF-16, too, then.
>>
>
> Personally I think we have to be careful not to fall into the trap of
> assuming that the only use-case for JSON will be in "to browser"
> communications.  I'm hoping that for the IETFs purposes we'll be looking at
> JSONs wider utility into broader areas, which may even include logging to
> files and interprocess communication where there might be sensible reasons
> to choose something other than UTF-8.
>
>
> Pete Cordell
> Codalogic Ltd
> C++ tools for C++ programmers, http://codalogic.com
> Read & write XML in C++, http://www.xml2cpp.com
>
> _______________________________________________
> json mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/json
>