- From: And Clover <and-py@doxdesk.com>
- Date: Thu, 26 Aug 2010 19:31:01 +0200
On 2010-08-26 13:58:24, Julian Reschke wrote: > Not convinced. There's already one way to escape these things, and this > is supported in all UAs. Totally agree. If a web author isn't sufficiently experienced to remember to call an HTML-encoding function, there is no reason to believe they'll think to call a base64-encoding function either. The proposal adds more parsing complexity (and XML incompatibility) for no obvious gain. However, I'm all for making standardised HTML-encoder/decoder and base64-encoder/decoder functions available at a `window` or ECMAScript language level. `atob`/`btoa` do the job, but they're byte encoders not characters; they expect 'binary' strings where each charCode is the ordinal value of a byte. That is to say, they `btoa` encodes the input string using genuine-ISO-8859-1 and not UTF-8. This is necessary for a general-purpose base64 implementation (otherwise many base64 strings would not be decodable at all), but may be unexpected. Is it worth providing a UTF-8-based variant or argument? Otherwise users would have to convert from UTF-8-misdecoded-as-ISO-8859-1 strings manually. (That's not difficult, using `decodeURIComponent(escape(s))`, but this trick isn't obvious or well-known.) -- And Clover mailto:and at doxdesk.com http://www.doxdesk.com/
Received on Thursday, 26 August 2010 10:31:01 UTC