前端开发过程中会接触各种各样的编码，比较常见的主要是UTF－8和HTML实体编码，但是web前端的世界却不止这两种编码，而且编码的选择也会 造成一定的问题，如前后端开发过程中不同编码的兼容、多字节编码可能会造成的XSS漏洞等。因此，本文旨在更好的全面了解涉及前端开发领域的字符编码，避 免可能出现的交互和开发中的忽视的漏洞。
URL编码
我曾经在URL编码解码和base64一文中讲述了URL编码中的三组函数，并对比了这三组函数与base64编码的关系，在此简要说明一下。
escape/unescape函数针对宽字符做unicode编码，并针对码值做十六进制编码，所以使用escape针对汉字编码会得到形 如”\uxxxx”的结果；encodeURI/decodeURI,encodeURIComponent/decodeURIComponent函数 针对宽字节编码却不同于escape，首先针对宽字节字符进行UTF－8编码，然后针对编码后的结果进行“％”替换，得到结果。以上所述都是针对宽字节字 符而言，对于编码靠前的ASCII字符而言，上述三组函数的安全字符的范围也有所不同，具体可在上文中了解。
base64编码
base64编码在前端通常用于图片和icon的编码，它将每3个8位字节为一组，分成4组6位字节，并且每个字节的高位补零，形成4个8位的字 节，由此可看出base64编码是可逆推的。在大多数浏览器中，提供了ASCII字符的base64编码函数，即window.btoa()。该函数无法 针对宽字节进行base64编码，若针对中文编码，则需现转换位UTF－8编码，然后进行base64编码。
function unicodeToBase64(s){ return window.btoa(unescape(encodeURIComponent(s))) }
通过encodeURIComponent对宽字节字符编码，是“％xx”形式的编码，与UTF8编码的区别仅在于前缀（这是由规范RFC3986决定的，将非ASC字符进行某种形式编码，并转换为16进制，并在字节前加上“％”）。因此通过unescape(encodeURIComponent(s))可以转化为UTF8字节。当然，也可自己写一个转换函数，按照一定规则便行为UTF－8编码的字节，如下例：
```
unescape(encodeURIComponent("中国")) //结果："ä¸å›½"
encodeURIComponent("中国") //结果："%E4%B8%AD%E5%9B%BD"
console.log("\u00E4\u00B8\u00AD\u00E5\u009B\u00BD") // 结果： "ä¸å›½"
```
通过简单的replace函数，就可以完成URL编码到UTF8编码的转换，进而完成宽字节字符到base64编码的转换。有了这个函数，我们手动生成一些data URI形式的内容，只需制定MIME类型和编码方式，就可以实现文本的转换
