Minutes from 10/5 internationalization ad-hoc meeting

Joshua Bell jsbell at chromium.org
Tue Oct 16 09:18:05 PDT 2012


On Mon, Oct 15, 2012 at 5:51 PM, Gillam, Richard <gillam at lab126.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121016/4d0afd4d/attachment.html>


More information about the es-discuss mailing list