Minutes from 10/5 internationalization ad-hoc meeting
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
> 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
To support those use cases within browsers, I drafted an API  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 ..
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss