[whatwg] StringEncoding: Allowed encodings for TextEncoder
Glenn Maynard
glenn at zewt.org
Tue Aug 7 07:32:37 PDT 2012
On Mon, Aug 6, 2012 at 11:39 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> I seem to have a recollection that we discussed only allowing encoding
> to UTF8 and UTF16LE, UTF16BE. This in order to promote these formats
> as well as stay in sync with other APIs like XMLHttpRequest.
>
Not an objection, but where does XHR limit sent data to those encodings?
send(FormData) forces UTF-8 (which is even more restrictive);
send(Document) seems to allow any encoding *except* for UTF-16 (presumably
web compat since that's a weird criteria).
I'm not sure that staying in sync with XHR--which has its own pile of
legacy code to support--is worthwhile here anyway, but limiting to Unicode
seems fine in its own right, especially since the restriction can always be
lifted later if real needs come up.
However I currently can't find any restrictions on which target
> encodings are supported in the current drafts.
>
> One wrinkle in this is if we want to support arbitrary encodings when
> encoding, that means that we can't use "insert a the replacement
> character" as default error handling since that isn't available in a
> lot of encoding formats.
>
I don't think this part is a real hurdle. Just replace with "?" for
non-Unicode encodings.
On Tue, Aug 7, 2012 at 8:10 AM, Joshua Cranmer <Pidgeot18 at verizon.net>wrote:
> I found that the wiki version of the proposal cites <
> http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html> as the way to
> find encodings.
>
That spec documents the encodings which are used anywhere in the platform,
but that doesn't necessarily mean every API needs to support all those
encodings. It's almost all backwards-compatibility.
--
Glenn Maynard
More information about the whatwg
mailing list