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 <petejson@codalogic.com>wrote: > ----- Original Message From: "Henri Sivonen" > > On Thu, Nov 21, 2013 at 3:39 PM, Anne van Kesteren <annevk@annevk.nl> >> 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 > json@ietf.org > https://www.ietf.org/mailman/listinfo/json >
Received on Friday, 22 November 2013 16:40:20 UTC