前端開發中的字符編碼

前端開發過程當中會接觸各類各樣的編碼，比較常見的主要是 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 形式的編碼，與 UTF-8 編碼的區別僅在於前綴（這是由規範 RFC3986 決定的，將非 ASC 字符進行某種形式編碼，並轉換爲 16 進制，並在字節前加上「％」）。所以經過 unescape(encodeURIComponent(s)) 能夠轉化爲 UTF-8 字節。固然，也可本身寫一個轉換函數，按照必定規則便行爲 UTF-8 編碼的字節，以下例：

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

經過簡單的 replace 函數，就能夠完成 URL 編碼到 UTF-8 編碼的轉換，進而完成寬字節字符到base64編碼的轉換。有了這個函數，咱們手動生成一些 data URI 形式的內容，只需制定 MIME 類型和編碼方式，就能夠實現文本的轉換，如如下代碼：

<a href="data:text/html;charset=utf-8;base64,PHNjcmlwdD5hbGVydCgxMik8L3NjcmlwdD4=" >abc</a>
// 未編碼前：<a href="javascript: alert(1)">test</a>

前端 UTF-8 編碼與後端 GBK 編碼的兼容

目前前端大都採用 UTF-8 進行編碼，不論是 html、js 抑或是 css，然後端則因爲歷史緣由大都採用 GBK 或 GB2312 進行解碼，所以前端經過 parameter 傳遞的 URL 編碼的字符串就不可能直接在後臺進行解碼，爲了更好的兼容性，前端可進行兩次 URL 編碼，即 encodeURIComponent（encodeURIComponent（「中國」）），這樣後端接收到參數後，先使用 GBK 或 GB2312 解碼，獲得了 UTF-8 編碼後再使用 UTF-8 解碼便可。兩次編碼主要是利用「ASC 字符使用 GBK 或 GB2312 編碼不變」的特色完成，富有技巧。

HTML 實體編碼與進制編碼

實體編碼針對HTML的預留字符而言，如 <> 等。實體編碼有兩種形式 &實體名; 或 &entity_number;，因爲瀏覽器對 &實體名; 的兼容性有差異，所以最好採用實體號的形式編碼。

進制編碼，顧名思義將ASC字符對應的碼值按照十六進制或十進制編碼，並轉化爲 &#x;(16進制) 或&#D;(10進制) 形式。

單單針對實體編碼而言並無什麼特殊強調的點，之因此把它單獨列爲一個章節，意在強調這兩種編碼與 js 代碼的做用域的關係。

一、<div onclick="document.write('<img src=1 onerror=alert(23)>')">cccc</div> 
二、<div onclick="document.write('&lt;img src=1 onerror=alert(23)&gt;')">cccc</div>
三、&#x3c;&#x69;&#x6d;&#x67;&#x20;&#x73;&#x72;&#x63;&#x3d;&#x31;&#x20;&#x6f;&#x6e;&#x65;&#x72;&#x72;&#x6f;&#x72;&#x3d;&#x61;&#x6c;&#x65;&#x72;&#x74;&#x28;&#x32;&#x33;&#x29;&#x3e;
四、<img src=1 onerror=&#x61;&#x6c;&#x65;&#x72;&#x74;&#x28;&#x32;&#x33;&#x29;>

<script>
    五、document.write('&lt;img src=1 onerror=alert(23)&gt;');
    六、document.write('<img src=1 onerror=&#x61;&#x6c;&#x65;&#x72;&#x74;&#x28;&#x33;&#x29;>');
    七、document.write('&#x3c;&#x69;&#x6d;&#x67;&#x20;&#x73;&#x72;&#x63;&#x3d;&#x31;&#x20;&#x6f;&#x6e;&#x65;&#x72;&#x72;&#x6f;&#x72;&#x3d;&#x61;&#x6c;&#x65;&#x72;&#x74;&#x28;&#x32;&#x33;&#x29;&#x3e;')
    八、document.write('\u003c\u0069\u006d\u0067\u0020\u0073\u0072\u0063\u003d\u0031\u0020\u006f\u006e\u0065\u0072\u0072\u006f\u0072\u003d\u0061\u006c\u0065\u0072\u0074\u0028\u0032\u0033\u0029\u003e')
</script>

代碼中列舉了 8 個例子：

• 第一個在事件處理函數 onclick 中輸出 HTML 片斷；

• 第二個則輸出經實體編碼後的 HTML 片斷；

• 第三個則是直接針對 <img src=1 onerror=alert(23)> 作 16 進制編碼；

• 第四個則是針對 onerror 事件處理函數作 16 進制編碼；

• 第五個則是在腳本中輸出實體編碼的字符；

• 第六個針對事件處理函數作 16 進制編碼；

• 第七個則針對全部的字符作 16 進制編碼；

• 第八個則是在 script 中直接輸出 <img src=1 onerror=alert(23)> 的 unicode 編碼

對比結果，前兩個例子在點擊後都會彈出 alert；第三個例子則在頁面中顯示文本 <img src=1 onerror=alert(23)>；第四個例子則會在頁面加載初期彈出 alert；第5、七會輸出字符串；第6、八則會在第四個例子中的 alert 以後也彈出 alert。如今分析這些結果，經過第一二個例子可知道，HTML 標籤中（除 script 標籤）的內聯 js 代碼能夠進行 HTML 實體編碼，這是很是重要的一點，咱們能夠更爲明確的進行驗證：

<div onclick="alert('&lt;img src=1 onerror=alert(23)&gt;')">cccc</div>

輸出的結果天然是 <img src=1 onerror=alert(23)>，這的確論證了咱們上文提到的這一點；第三個例子說明了HTML解析器在進行詞法分析前，首先進行解碼，十六進制和十進制皆可，所以，結果天然輸出形如 <img src=1 onerror=alert(23)> 的字符串；第四個例子則緊接着論證了內聯在 HTML 的並採用十六進制編碼的 js 代碼一樣會被正確解析並執行，這說明了進制編碼一樣可被 HTML 解析器解析；第5、七個例子說明在 js 中一樣可使用實體編碼和進制編碼，解析的結果會渲染在頁面上；第六個例子則論證了上一觀點，只針對事件處理函數作進制編碼，執行後頁面彈出 alert；第八個例子則是在 js 中執行 unicode 編碼的字符串，正常 alert。

因而可知，js 代碼內聯在 HTML 的非 script 標籤內，則會遵照 HTML 編碼規範：進制編碼和實體編碼；而在 js 代碼（script 標籤內以及 js 文件內）中，則聽從 js 編碼：1. unicode 形式編碼(uxxxx) 2. 普通的 16 進制編碼(xH)，這可經過第八個例子獲得證實。之因此在本節提到這麼多編碼特色，主要提醒你們在預防 XSS 時須要注意的幾點：

• 檢測用戶輸入時，不只僅須要防範相似 <> 這樣的字符，經過 unicode 編碼或進制編碼仍有可能注入代碼

• 須要針對特定的關鍵字作過濾，如 eval、write、prototype

• 儘量禁止內聯事件處理函數的使用

• js 過濾 src/href/action 屬性，如 javascript:, data:

JS 編碼

其實在上節中已提到了 js 編碼，即 js 可執行 unicode 編碼和十六（八）進制編碼後的字符串，可是不支持十進制編碼的字串。具體操做可經過經常使用的幾個函數來實現，如 eval，write，setTimeout，Function 執行編碼後的字符串；一樣，對於十進制編碼的字串，經過結合 String.fromCharCode 和 eval 一樣能夠執行。

在此附上筆者實現的字符轉換，更爲靈活的實現各類自定義形式的字串編碼：

var Code = {};
    /**
     *
     * @param str 待編碼字串
     * @param jinzhi 進制編碼
     * @param prefix 前綴
     * @param postfix 後綴
     * @param count 總共編碼的位數，默認爲4
     * @returns {string}
     */
    Code.encode = function({str = '',jinzhi = '16',prefix = '\\u',postfix = ';',count = '4'} = {}){
        var ret = '';
        var addZero,tmp;
        for(let i=0;i<str.length;i++){
            tmp = str.charCodeAt(i).toString(jinzhi);
            addZero = count - tmp.length + 1;
            ret += prefix + new Array(addZero).join('0') + tmp + postfix;
        }
        return ret;
    };
    Code.decode = function({str = '',jinzhi = '16',prefix = '\\u',postfix = ';'} = {}){
        var ret = '';
        var splits = str.split(';');
        for(let i=0;i<splits.length;i++){
            let tmp = splits[i].replace(prefix,'');
            ret += String.fromCharCode(parseInt(tmp,jinzhi));
        }
        return ret;
    };

    console.log(Code.encode({str: '<img src=@ onerror=alert(123) />'}));
    console.log(Code.decode({str: Code.encode({str: '<img src=@ onerror=alert(123) />'})}))

另外，對於 js 輸出點的過濾其實並不只限於上文提到的如 eval、setTimeout、Function 等幾個，因爲 JS 語法比較靈活相對「漏洞」較多，可以使用的「線索」也越豐富，如前段時間在 Stackoverflow 上發現的一個問題，即

(0)['constructor']['constructor']('return "abc;"')()

一樣能夠執行 JS 代碼，確實挺有特色的，具體爲何上述形式能夠執行代碼，請讀者本身仔細品味。