這篇文章將為大家詳細(xì)講解有關(guān)前端開發(fā)中的字符編碼有哪些，小編覺得挺實(shí)用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

創(chuàng)新互聯(lián)服務(wù)項(xiàng)目包括愛民網(wǎng)站建設(shè)、愛民網(wǎng)站制作、愛民網(wǎng)頁制作以及愛民網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，愛民網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到愛民省份的部分城市，未來相信會繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

前端開發(fā)過程中會接觸各種各樣的編碼，比較常見的主要是UTF－8和HTML實(shí)體編碼，但是web前端的世界卻不止這兩種編碼，而且編碼的選擇也會 造成一定的問題，如前后端開發(fā)過程中不同編碼的兼容、多字節(jié)編碼可能會造成的XSS漏洞等。因此，本文旨在更好的全面了解涉及前端開發(fā)領(lǐng)域的字符編碼，避 免可能出現(xiàn)的交互和開發(fā)中的忽視的漏洞。

URL編碼

我曾經(jīng)在URL編碼解碼和base64一文中講述了URL編碼中的三組函數(shù)，并對比了這三組函數(shù)與base64編碼的關(guān)系，在此簡要說明一下。
escape/unescape函數(shù)針對寬字符做unicode編碼，并針對碼值做十六進(jìn)制編碼，所以使用escape針對漢字編碼會得到形 如”\uxxxx”的結(jié)果；encodeURI/decodeURI,encodeURIComponent/decodeURIComponent函數(shù) 針對寬字節(jié)編碼卻不同于escape，首先針對寬字節(jié)字符進(jìn)行UTF－8編碼，然后針對編碼后的結(jié)果進(jìn)行“％”替換，得到結(jié)果。以上所述都是針對寬字節(jié)字 符而言，對于編碼靠前的ASCII字符而言，上述三組函數(shù)的安全字符的范圍也有所不同，具體可在上文中了解。

base64編碼

base64編碼在前端通常用于圖片和icon的編碼，它將每3個8位字節(jié)為一組，分成4組6位字節(jié)，并且每個字節(jié)的高位補(bǔ)零，形成4個8位的字 節(jié)，由此可看出base64編碼是可逆推的。在大多數(shù)瀏覽器中，提供了ASCII字符的base64編碼函數(shù)，即window.btoa()。該函數(shù)無法 針對寬字節(jié)進(jìn)行base64編碼，若針對中文編碼，則需現(xiàn)轉(zhuǎn)換位UTF－8編碼，然后進(jìn)行base64編碼。

function unicodeToBase64(s){ return window.btoa(unescape(encodeURIComponent(s))) }

通過encodeURIComponent對寬字節(jié)字符編碼，是“％xx”形式的編碼，與UTF8編碼的區(qū)別僅在于前綴（這是由規(guī)范RFC3986決定的，將非ASC字符進(jìn)行某種形式編碼，并轉(zhuǎn)換為16進(jìn)制，并在字節(jié)前加上“％”）。因此通過unescape(encodeURIComponent(s))可以轉(zhuǎn)化為UTF8字節(jié)。當(dāng)然，也可自己寫一個轉(zhuǎn)換函數(shù)，按照一定規(guī)則便行為UTF－8編碼的字節(jié)，如下例：

``` unescape(encodeURIComponent("中國")) //結(jié)果："中å?½" encodeURIComponent("中國") //結(jié)果："%E4%B8%AD%E5%9B%BD" console.log("\u00E4\u00B8\u00AD\u00E5\u009B\u00BD") // 結(jié)果： "中å?½" ```

通過簡單的replace函數(shù)，就可以完成URL編碼到UTF8編碼的轉(zhuǎn)換，進(jìn)而完成寬字節(jié)字符到base64編碼的轉(zhuǎn)換。有了這個函數(shù)，我們手動生成一些data URI形式的內(nèi)容，只需制定MIME類型和編碼方式，就可以實(shí)現(xiàn)文本的轉(zhuǎn)換，如以下代碼：

```

abc // 未編碼前：test ```

前端UTF8編碼與后端GBK編碼的兼容

目前前端大都采用UTF8進(jìn)行編碼，不管是html、js抑或是css，而后端則由于歷史原因大都采用GBK或GB2312進(jìn)行解碼，因此前端通過 parameter傳遞的URL編碼的字符串就不可能直接在后臺進(jìn)行解碼，為了更好的兼容性，前端可進(jìn)行兩次URL編碼，即 encodeURIComponent（encodeURIComponent（“中國”）），這樣后端接收到參數(shù)后，先使用GBK或GB2312解碼， 得到了UTF8編碼后再使用UTF8解碼即可。兩次編碼主要是利用“ASC字符使用GBK或GB2312編碼不變”的特點(diǎn)完成，富有技巧。

HTML實(shí)體編碼與進(jìn)制編碼

實(shí)體編碼針對HTML的預(yù)留字符而言，如“<>”等。實(shí)體編碼有兩種形式&實(shí)體名;或&entity_number;，由于瀏覽器對&實(shí)體名;的兼容性有差別，因此***采用實(shí)體號的形式編碼。

進(jìn)制編碼，顧名思義將ASC字符對應(yīng)的碼值按照十六進(jìn)制或十進(jìn)制編碼，并轉(zhuǎn)化為&#x;(16進(jìn)制)或&#D;(10進(jìn)制)形式。

單單針對實(shí)體編碼而言并沒有什么特殊強(qiáng)調(diào)的點(diǎn)，之所以把它單獨(dú)列為一個章節(jié)，意在強(qiáng)調(diào)這兩種編碼與js代碼的作用域的關(guān)系。

')">cccc