|
|
毕竟脚本的理念仅仅是用来处理一些简单的交互的，对于处理字节流之类的复杂问题完全不该是脚本的职责。不过作为一种探索，我们还是可以挖掘下其中的乐趣。当然，首先要明确的是，对于二进制的读取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页，转载需保留来源！
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
