JavaScript優化篇：BASE64極速版

　　網(LieHuo.Net)教程 BASE64原理很簡單，但要寫出一個高效的，尤其是用JS這樣高靈活低效率的腳本，還需斟酌一翻。

　　先看看網上比較流行的版本。首先聲明64個常量字符：

　　這一步大家都一樣，也沒有更好的方法列出這些字符。但接下來的做法，就大有講究了。因為這里的key是一個String，所以各個版本里都大量充斥著charAt，甚至indexOf函數來操作這個key。用charAt來訪問key的第n個字符，這還在清理之中;但用indexOf來確定字符的位置，就不可原諒了。在VBScript里倒還能湊合著用，但在JS里這種做法是很糟糕的，顯然沒有把其靈活性發揮出來。何謂靈活性，用最短的話說就是多用哈希表。哈希表是JS與生俱來就有的東西，其效率是其他方法都不能相比的。顯然，在BASE64這樣數字與字符頻繁轉換的算法里，hash是該大顯身手的。

　　再談charAt的問題。charAt雖然不會像indexOf那樣效率數量級的下降，但也不是最優秀的。腳本程序分兩類，一類是自己寫的，另類就是系統內置在瀏覽器中的，就是所謂的[Native Code]。后者的效率當然是遠高于前者，這大家都知道。所以盡可能多讓代碼交給系統執行，有時看起來可能計算量變大了，但最終的速度反倒提升了。

　　就說BASE64解碼的過程，參數是個String，按常規的方法就是先charAt其每個字符。如果有1萬個字符，那么charAt也就運行了1萬次。能否將多次charAt函數的執行合并到1次本地代碼的調用上呢,當然可以：

　　var arr = str.split('');

　　之后的str.charAt(i)就可以用arr[i]代替了。此方法雖多開辟的一塊內存，但最終的效率還是有所提高，并且增強了代碼可讀性。當然，在運行速度極快的瀏覽器比如FireFox,Chrome就沒什么區別，甚至還可能倒退。

　　最后就是一個層次上的問題。網上常有人在說BASE64如何支持中文。按照這種說法，BASE64用來編碼解碼字符串了，這與其意義多少有些偏離。BASE64的最初就是將二進制文件轉成可見字符，在郵件里發送。因此其意義就在于二進制與字符的轉換，而不是字符與字符的轉換。JS沒有二進制，但可以用0-255的數組來模擬。所以：

　　function 編碼函數(Array[]){return String;}

　　function 解碼函數(String){return Array[];}

　　至于中文的問題，無非就是Unicode與ANSI的轉換。JS貌似沒有現成的轉換函數，若要實現可以用Unicode與ANSI的對照表。但雙方的編碼/解碼都統一使用Unicode，也就

　　不存在支不支持的問題了。

　　最終的代碼：

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈