- From: Glenn Maynard <glenn@zewt.org>
- Date: Wed, 7 Aug 2013 08:29:24 -0500
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: WHATWG <whatwg@lists.whatwg.org>, Chang Shu <cshu01@gmail.com>
On Wed, Aug 7, 2013 at 5:28 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Tue, Aug 6, 2013 at 9:48 PM, Chang Shu <cshu01@gmail.com> wrote: > > But it appears to me we have to introduce > > another pair of coders, say BinaryDecoder/BinaryEncoder, in addition > > to TextDecoder/TextEncode since the signatures of the decode/encode > > functions are different. > > So TextDecoder is bytes to string and TextEncoder is string to bytes. > If we always represent the base64-variant as a sequence of bytes the > signature seems fine. If you want to get a string out of those bytes > again you could utf-8 decode it for instance. > If base64 was treated as a sequence of bytes then both encoding and decoding would be bytes to bytes, which doesn't match either of those. base64 data is a string, though. Having encode to a UTF-8 binary array to convert to base64, and decode back to a string after decoding base64, would be pretty awkward for the common case. Signature-wise, you'd want TextDecoder to convert from data to base64, and TextEncoder to convert from base64 to data. The only annoying thing is that results in the function names being backwards (logically the former is "encoding to base64" and the latter is "decoding base64"). That's livable, though. -- Glenn Maynard
Received on Wednesday, 7 August 2013 13:29:49 UTC