|
|
畢竟腳本的理念僅僅是用來處理一些簡單的交互的，對于處理字節流之類的復雜問題完全不該是腳本的職責。不過作為一種探索，我們還是可以挖掘下其中的樂趣。當然，首先要明確的是，對于二進制的讀取JS確實是無能為力的，不過我們可以來模擬，以達到相同的效果，下面就跟著我來吧。
比如現在想要做個推箱子的小游戲，共200關。這時唯一值得考慮到事就出現了：把這200關地圖數據保存在何處？如果直接硬塞在一個腳本文件里似乎顯得太大，或者單獨保存在一個文件里，但是用什么格式。。。不過對于推箱子游戲來說簡單的文本格式也夠了，但對于一些地圖較復雜的也許就會使用BASE64編碼，然后由客戶端的HTTP組件下載下來解碼使用。BASE64編碼在JS中還是很常用的，畢竟它不受任何的環境限制，能夠處理字符串就行。
既然有個BASE64，那為什么就不能有BASE128，BASE256了呢？如果能實現“BASE256”，豈不就是二進制字節流了？如果真可以如此，那這種方法早就流傳開了，還留著那么多的BASE64做什么：）畢竟這是字符串，而不叫字節串，那肯定是有區別的。不妨把一個二進制的文件，當作文本文件讀取回來試試，很快你就會發現超過一旦文件中出現127（0x7F）以上的字符，馬上就出錯了；如果存在個0x00字節的話，后面的內容都會蕩然無存，這意味著256個字符中能夠利用的還不到一半。
然而，可別忘了這個測試使用的僅僅是最基本的ASCII編碼，對于功能強大的XMLHTTP支持的也絕不僅限于如此，那么就試試Unicode字符會怎樣。在記事本隨便輸幾個字符，保存為Unicode格式的文本文件。這時用XMLHTTP讀取，顯示出來的與記事本里的一模一樣，但是再用16進制編輯器打開此文件時，就大不相同了。在文件的開頭出現了FF FE兩字節，后面的每個內容都是由一個0隔開。畢竟這是16位的Unicode字符，除了基本的ASCII外，還要保存各國的文字。例如一個中文就占用了2個字節，而英文數字仍然占用2字節，只是高位由0填充罷了（注意高位字節是在低位字節后面的）。
XMLHTTP能夠成功顯示出來就說明Unicode還是支持的。現在試著修改文件里面的數據，看看超過了那些范圍才會出錯。把數據修改成如下：FFFE 0001 0203 7F00 8000 8100 FF00 FFFF。用XMLHTTP測試，雖然顯示的都是亂碼，但并沒出錯，返回的字符串用charCodeAt(i)及toString(16)方法一試，原形畢露！幾經測試，Unicode并不像ASCII那樣有范圍限制，但唯獨一個例外：0x0000！
眾所周知，0x00就是ASCII的結束標志。但到了Unicode的世界里一切都是16位的，因此字符尾也成了0x0000。到了這里似乎有點遺憾，但接著的目標很明確：如果能夠去掉文件中的0x0000，并在之前加上0xFEFF，就能夠讓JavaScript讀取了。
去掉以及恢復，不妨就稱他編碼與解碼吧。編碼的方法就見智見仁了，最簡單的辦法就是記錄下每個0x0000的位置，然后除去；在客戶端按照記錄的位置再復原回去。雖然簡單，但也別忘了，0x00在二進制文件中是相當多的，即便是0x0000也是。這樣光是記錄他們的內容就有很多，顯然不是很好。既然說到要記錄，為何一定要記錄0x0000的位置？反過來想，我們應該記錄這個文件中出現次數最少的字符，以及它的位置，然后把0x0000的地方替換成這個字符；解碼的時候一旦出現這個字符，但當前位置又不在記錄中，就可以確定這就是個0x0000。事實上，在64K以下的文件中肯定有個字符根本就不會出現的（為什么仔細考慮下就明白），即使是在64K以上，還是有非常多的文件不存在某個字符的。畢竟一個Unicode字符有65536之多，很少有文件會把他們全都用上，除非是個冗余極小的壓縮文件，但也不會很多。
到此，編碼解碼思路已明了，剩下自然是實現他們。
剛才提到了源文件中出現最少（甚至是沒有）的Unicode字符，不妨就稱作key
首先來定義新生成的二進制文件頭格式：
復制代碼 代碼如下:
00 01 0xFEFF。 Unicode文件頭，這是必須的
02 03 Key值。 為了不讓0x0000成為Key，在尋找的過程中忽略0x0000
03 04 Key出現的次數+1。 +1是為了避免該位置出現0x0000，后面的也都一樣
05 06
07 08 第1個Key的位置 用4字節保存每個Key的位置。
09 0A
0B 0C 。。。
0D 0E
0F 10 第n個Key的位置
11 12 文件數據內容。。。
JavaScript技術：JS幻想 讀取二進制文件第1/2頁，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
