本文解析了浏览器原生支持的Base64编码解码方法，重点介绍atob和btoa函数的语法与用法。通过对比第三方库，说明使用原生方法的优势，并提供针对IE8/IE9的Polyfill兼容方案，帮助开发者优化前端代码选型。
浏览器原生JS Base64编码解码：atob与btoa详解及IE兼容方案
此前曾介绍过利用JS实现剪切板粘贴上传图片的方法，今日将重点探讨JS中的Base64编码与解码技术。
基础不牢，选型糟糕
1. 基础不牢，选型糟糕
技术选型的失误往往源于对技术广度认知的不足。就在数月前，面对前端HTML字符信息转换为Base64的需求，我直接选用了一个开源的base64.js库。该库使用简便，只需在浏览器中引入该JS文件即可进行Base64编码，具体操作如下：
若需解码，则调用decode方法，示例如下：
尽管数据准确且功能运行良好，当时自认为这是一个完美的解决方案。然而今日才发现，浏览器早已原生支持JS Base64的加密与解密功能。此前那种依赖第三方库的做法不仅冗余，更是完全不必要的技术选型，可谓徒劳无功。
由于对JS基础掌握不够扎实或技术视野受限，导致花费大量时间寻找Base64的JS语言库，学习其API用法，最终却换来了一个冗余且完全不需要加载的JS文件。回顾来看，这确实是一个糟糕的技术选型。
原生atob和btoa方法
2. 原生atob和btoa方法
实际上，自IE10+浏览器起，所有主流浏览器均已原生提供Base64编码与解码方法。这些方法不仅适用于常规浏览器环境，同样可在Service Worker环境中使用。
这两个原生方法分别名为atob和btoa，具体语法规范如下：
1）Base64解码
在浏览器环境中的语法为：
var decodedData = window.atob(encodedData);或者在浏览器或JS Worker线程中的语法为：
var decodedData = self.atob(encodedData);例如：
window.atob('emhhbmd4aW54dQ==');
// 返回：'zhangxinxu'
乍看atob这个名称，可能会觉得奇怪，难以理解其含义。我们可以将其理解为“A到B”，即从A转换到B。这里的B是否指Base64呢？很遗憾，猜错了。实际上A才代表Base64，而B代表普通字符。这里的“Low”意指普通、非编码状态。因此，记忆技巧可以是：B代表“Low B”（普通字符），A代表Base64，这与首字母的对应关系是相反的。
因此，atob表示将Base64字符转换为普通字符，即执行Base64解码操作。
2）Base64编码
在浏览器环境中的语法为：
var encodedData = window.btoa(stringToEncode);或者在浏览器或JS Worker线程中的语法为：
var encodedData = self.btoa(stringToEncode);例如：
window.btoa('zhangxinxu');
// 返回：'emhhbmd4aW54dQ=='
同样，btoa这个名称初看也令人困惑。我们可以将其理解为“B到A”，即从B转换到A。那么B和A分别指代什么？与atob方法一致，B指的是普通的字符串（即“Low B”），而A指的是Base64编码后的字符。
因此，btoa方法表示将普通字符转换为Base64字符，即执行Base64编码操作。
IE8/IE9的polyfill
3. IE8/IE9的polyfill
目前，仍有不少PC端项目需要兼容IE9浏览器。因此，我们可以专门针对这些旧版浏览器引入一段Polyfill脚本或单独的JS文件。
在实际使用中，我们可以借助IE条件注释来实现无缝对接。具体做法是在HTML中嵌入以下代码：
[if IE]条件注释适用于所有IE浏览器。由于IE10+已不再支持著名的IE条件注释，而Chrome等现代浏览器本身也不支持这一IE私有语法，因此上述script标签的引入仅在IE9及更低版本的浏览器中生效。这恰好符合我们仅希望为IE8和IE9浏览器引入Polyfill的需求，实现了完美的衔接。
也就是说，对于原生支持atob和btoa方法的浏览器而言，这段代码被视为无需关心的HTML注释；而对于不支持这两个方法的IE9及更低版本浏览器，则会加载base64-polyfill.js文件，从而使其也支持window.btoa和window.atob语法。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持本站。