Closed
Bug 213047
Opened 21 years ago
Closed 9 years ago
btoa only works with ISO-8859-1
Categories
(Core :: Internationalization, defect)
Core
Internationalization
Tracking
()
RESOLVED
INVALID
People
(Reporter: smontagu, Assigned: smontagu)
References
Details
Attachments
(1 file)
965 bytes,
text/html
|
Details |
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().
Comment 1•16 years ago
|
||
Comment 4•16 years ago
|
||
What does it do in other UAs? Will changing behavior here break any webpages?
Comment 5•16 years ago
|
||
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.
Assignee | ||
Comment 6•16 years ago
|
||
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?
Comment 7•16 years ago
|
||
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.
Assignee | ||
Comment 8•16 years ago
|
||
(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.
Updated•15 years ago
|
QA Contact: amyy → i18n
Comment 9•14 years ago
|
||
Wontfix?
Comment 10•9 years ago
|
||
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: RmlyZWZveCBIZWxsbyDigJQgSm9pbiB0aGUgY29udmVyc2F0aW9u What am I missing?
Comment 11•9 years ago
|
||
https://html.spec.whatwg.org/multipage/#dom-windowbase64-btoa Changes to this API can be discussed in all the usual venues for that spec, which does not include this bugzilla instance.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•