Bug 101278

Created attachment 172437 [details] Patch

Not a full implementation yet (streaming, labels/names, BOM handling, etc) and no tests. But the basics work: d = new TextDecoder('utf-16'); d.decode(new Uint8Array([65, 00, 66, 00, 67, 00])); // => "ABC" e = new TextEncoder('utf-8'); e.encode('abc'); // => [97, 98, 99] (I also went crazy with adding the files to every build system I could find as that appeared to be the precedent - except the xcodeproj since I didn't have a mac handy.)

Comment on attachment 172437 [details] Patch Nice start! Let's see what the EWS bots say.

Is this an implementation of http://encoding.spec.whatwg.org/ ?

Comment on attachment 172437 [details] Patch Attachment 172437 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/14733698 New failing tests: fast/regions/floats-basic-in-variable-width-regions.html fast/dynamic/subtree-parent-static-y.html fast/regions/render-region-renderer.html fast/spatial-navigation/snav-unit-overflow-and-scroll-in-direction.html platform/mac/fast/loader/file-url-mimetypes-2.html fast/regions/float-pushed-width-change.html fast/images/repaint-subrect-grid.html platform/mac/editing/spelling/removing-underline-after-accepting-autocorrection-using-punctuation.html

(In reply to comment #4) > Is this an implementation of http://encoding.spec.whatwg.org/ ? That's the goal, yes.

Created attachment 173130 [details] Patch

NOTE: Still not ready for a review. Now uses TextCodec which is in theory the right WebCore API for encode/decode calls. Streaming for decode is hooked up, but notably TextCodecUTF16 actually ignored the |flush| flag and never actually flushes.

What is the use case for this API? My concern is that there are many little knobs in codecs (what to do with invalid input, how to encode things that don't fit into target encoding, whether to strip BOM etc.) All use cases combined seem fairly marginal, and each of them needs a different behavior. Will we end up with a ton of options that will need to be agreed upon and supported in all browsers?

(In reply to comment #9) > What is the use case for this API? Encoding/decoding text from Typed Arrays, e.g. parsing legacy file formats, packing binary data for upload, etc. > My concern is that there are many little knobs in codecs (what to do with invalid input, how to encode things that don't fit into target encoding, whether to strip BOM etc.) Spec is here: http://encoding.spec.whatwg.org/#api - there's been quite a bit of discussion on WHATWG, you can check the archives. Some of the history of open issues is also captured at http://wiki.whatwg.org/wiki/StringEncoding > All use cases combined seem fairly marginal, and each of them needs a different behavior. Will we end up with a ton of options that will need to be agreed upon and supported in all browsers? The goal has been supporting the use case while matching the existing encoding/decoding behavior of the Web platform, which is what the rest of that spec details - avoiding as many knobs as possible for legacy encodings unless required by existing content.

> The goal has been supporting the use case while matching the existing encoding/decoding behavior of the Web platform All the knobs that I mentioned are needed to implement various parts of the Web platforms. In fact, a new knob is being added right now in bug 101569. I did not think about legacy encodings, just about different modes of operation (e.g. encoding for form submission, encoding for XMLHttpRequest posting, encoding for WebSocket posting, encoding for URL).