I'm using the Javascript window.atob()
function to decode a base64-encoded string (specifically the base64-encoded content from the GitHub API). Problem is I'm getting ASCII-encoded characters back (like â¢
instead of ™
). How can I properly handle the incoming base64-encoded stream so that it's decoded as utf-8?
相关问题
- Is there a limit to how many levels you can nest i
- How to toggle on Order in ReactJS
- void before promise syntax
- Keeping track of variable instances
- Can php detect if javascript is on or not?
Small correction, unescape and escape are deprecated, so:
Things change. The escape/unescape methods have been deprecated.
You can URI encode the string before you Base64-encode it. Note that this does't produce Base64-encoded UTF8, but rather Base64-encoded URL-encoded data. Both sides must agree on the same encoding.
See working example here: http://codepen.io/anon/pen/PZgbPW
For OP's problem a third party library such as js-base64 should solve the problem.
including above solution if still facing issue try as below, Considerign the case where escape is not supported for TS.
for csv_content you can try like below.
Here's some future-proof code for browsers that may lack
escape/unescape()
. Note that IE 9 and older don't supportatob/btoa()
, so you'd need to use custom base64 functions for them.A more comprehensive example for UTF-8 encoding and decoding can be found here: http://jsfiddle.net/47zwb41o/
If treating strings as bytes is more your thing, you can use the following functions
I would assume that one might want a solution that produces a widely useable base64 URI. Please visit
data:text/plain;base64,4pi44pi54pi64pi74pi84pi+4pi/
to see a demonstration (copy the data uri, open a new tab, paste the data URI into the address bar, then press enter to go to the page). Despite the fact that this URI is base64-encoded, the browser is still able to recognize the high code points and decode them properly. The minified encoder+decoder is 1058 bytes (+Gzip→589)Below is the source code used to generate it.
Then, to decode the base64 data, either HTTP get the data as a data URI or use the function below.
The advantage of being more standard is that this encoder and this decoder are more widely applicable because they can be used as a valid URL that displays correctly. Observe.
In addition to being very standardized, the above code snippets are also very fast. Instead of an indirect chain of succession where the data has to be converted several times between various forms (such as in Riccardo Galli's response), the above code snippet is as direct as performantly possible. It uses only one simple fast
String.prototype.replace
call to process the data when encoding, and only one to decode the data when decoding. Another plus is that (especially for big strings),String.prototype.replace
allows the browser to automatically handle the underlying memory management of resizing the string, leading a significant performance boost especially in evergreen browsers like Chrome and Firefox that heavily optimizeString.prototype.replace
. Finally, the icing on the cake is that for you latin script exclūsīvō users, strings which don't contain any code points above 0x7f are extra fast to process because the string remains unmodified by the replacement algorithm.I have created a github repository for this solution at https://github.com/anonyco/BestBase64EncoderDecoder/