Closed Bug 213047 Opened 16 years ago Closed 4 years ago

btoa only works with ISO-8859-1


(Core :: Internationalization, defect, major)

Not set





(Reporter: smontagu, Assigned: smontagu)




(1 file)

The btoa() function currently fails with NS_ERROR_DOM_INVALID_CHARACTER_ERR if
the input (in UTF-16) contains characters outside the range of ISO-8859-1, even
if all the characters are single-byte in the encoding of the page.

I think we should be converting the input to the page charset and then
converting to base64, just as we do for escape().
Duplicate of this bug: 439711
-> major per bug 439711 comment 3
Severity: normal → major
What does it do in other UAs?  Will changing behavior here break any webpages?
He made it major due to how completely useless btoa is for user input and if it is fixed then extenion developers don't need to make their own Base64 encoding function.
Attachment 343605 [details] fails in Safari also. 

My original suggestion in comment 0 to convert the input to the page encoding is not foolproof, since user input can easily include characters not representable in the page encoding. Maybe a better solution is to explicitly convert the input to UTF-8 before calling btoa?
If we're talking about extensions then we don't need to necessarily change the web-facing btoa.  We could provide an XPCOM API for doing this instead.

This bug is about web-facing btoa.  If we need a separate bug for extensions (based on the conclusions reached in this bug), so be it.

My gut feeling is that the suggestion in the last sentence of comment 6 will break sites (any site that is ISO-8859-1 and that does conversion one way on the client and the other on the server, for example!), but I eagerly await a decent analysis of IE's behavior (ideally IE7/quirks, IE7/standards, IE8/standards, in case they differ) here.  That will give us a good starting point for what web sites expect.
(In reply to comment #7)

> My gut feeling is that the suggestion in the last sentence of comment 6 will
> break sites

Then you misunderstood it: I meant that even if we didn't change any code, the extension developer could do the conversion before calling btoa.
QA Contact: amyy → i18n
I'm really confused about this. The API is called "btoa". binary to ascii.

So by definition, shouldn't it be able to take any binary data? Why is certain data not allowed?

In particular, I don't understand why this doesn't work:

btoa("Firefox Hello — Join the conversation");

Yet if I go to any base 64 encoder, it properly encodes to:


What am I missing?

Changes to this API can be discussed in all the usual venues for that spec, which does not include this bugzilla instance.
Closed: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.