On Mon, Oct 15, 2012 at 5:51 PM, Gillam, Richard <[email protected]> wrote:
> ** > > *Encoding conversion and detection.* Most of the time, text has already > been converted to UTF-16 before it surfaces in JavaScript, so the use cases > here basically all revolve around reading legacy file formats and > communicating with external libraries that use a non-Unicode character > encoding. We tended to agree that these use cases will dwindle over > time, so this functionality will decline in value over time. The tables > and code are also potentially big and complicated (depending on which/how > many encodings an implementer chose to support, or we mandated support > for), and we didn’t think we wanted all ES implementers to have to carry > them around all the time. Despite fairly strong objections from Google, > we agreed this was out of scope and shouldn’t be in a general-purpose > standard. > FYI - To support those use cases within browsers, I drafted an API [1] for encoding/decoding into/out of typed arrays, with plenty of input from the whatwg list. Going forward, Anne van Kesteren will be integrating it into his Encoding spec [2].. I don't think this contradicts the above conclusions by the internationalization effort - the primary use case for non-legacy data is for encoding/decoding ES strings into/out of binary buffers as UTF-8. The secondary use case is for parsing legacy data formats where the Web is the target platform, not ES itself, so having this be a browser API makes sense. Mozilla is apparently quite far along with an implementation. [1] http://wiki.whatwg.org/index.php?title=StringEncoding [2] http://encoding.spec.whatwg.org
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
