And not to mention whether the browser's built-in HTTP plug-ins support binary data flow, JavaScript itself has no binary processing capabilities. A smart reader might want to say that it's possible to use VBScript. Yes, because Vbscript,ie,activex are all products of Microsoft, so they have a seamless combination. The HTTP component of IE can indeed read binary data, and it can only allow VBScript to read. But for other browsers, there is nothing to do.
After all, the idea of scripting is simply a matter of dealing with simple interactions, and it's not entirely a function of scripting to deal with complex problems like byte streams. But as an exploration, we can still tap into the fun. Of course, the first thing to be clear, for binary read JS is really powerless, but we can simulate to achieve the same effect, follow me below.
For example now want to do a push box game, a total of 200 off. The only thing that's worth considering is where to keep the 200-map data. If the direct hard plug in a script file seems too large, or stored separately in a file, but in what format ... But for the push box game, simple text format is enough, but for some maps more complex may use BASE64 encoding, and then downloaded by the client's HTTP components to decode the use. BASE64 encoding in JS is still very common, after all, it is not subject to any environmental restrictions, can handle strings on the line.
Since there is a BASE64, then why can not have base128,base256? If you can achieve "BASE256", is not the binary byte stream? If so, then this method has long been circulated, and there are so many BASE64 to do: After all, this is a string, rather than a byte string, there must be a difference. may wish to put a binary file, read it back as a text file, and soon you'll find that more than once the characters in the file appear 127 (0x7F), the error immediately occurs, and if there is a 0x00 byte, the subsequent content will vanish, meaning that less than half of the 256 characters can be used.
However, don't forget that this test uses just the most basic ASCII encoding, and that's not the only way to support powerful XMLHTTP, so try Unicode characters. Save a few characters in Notepad as a text file in Unicode format. Read with XMLHTTP, the display is exactly the same as in Notepad, but when you open the file in the 16 editor, it's very different. FF fe two bytes appear at the beginning of the file, and each subsequent content is separated by a 0. After all, this is a 16-bit Unicode character, in addition to basic ASCII, but also to save the country's text. For example, one Chinese occupies 2 bytes, while the English digit still occupies 2 bytes, but the high level is filled by 0 (note that the high byte is behind the low byte).
The XMLHTTP can be shown successfully to show that Unicode is still supported. Now try to modify the data in the file to see if it's going to go beyond those ranges to make an error. Modify the data as follows: FFFE 0001 0203 7f00 8000 8100. With XMLHTTP test, although the display is garbled, but there is no error, the returned string with charCodeAt (i) and ToString (16) method A try, the true colours! After testing, Unicode does not have scope limitations like ASCII, but one exception: 0x0000!
As we all know, 0x00 is the end mark of ASCII. But in the Unicode world everything is 16-digit, so the character Fu Yu also became 0x0000. It seems a bit regrettable here, but then the goal is clear: if you can get rid of the 0x0000 in the file and add 0xFEFF before, you can let JavaScript read it.
get rid of it and restore it, just call him coding and decoding it. The method of encoding is seen in the wisdom of benevolence, the simplest way is to record the position of each 0x0000, and then removed, in the client according to the location of the record to restore back. Although simple, but also don't forget, 0x00 in the binary file is quite a lot, even if the 0x0000 is also. So there is a lot of record of their content, obviously not very good. When it comes to recording, why do we have to record the location of 0x0000? In turn, we should record the least number of characters in this file and its position, and then replace the 0x0000 place with this character, which, when decoded, can be determined to be a 0x0000 when the character is present, but the current position is not in the record. In fact, there must be a character that doesn't appear at all in a file under 64K (why do you think it over), even if it's over 64K, there's a lot of files that don't have a character. After all, there are more than 65536 Unicode characters, and few files will use them all, unless it is a very redundant compressed file, but not a lot.
In this way, coding decoding ideas have been clear, the rest of the nature is to achieve them.
Just mentioned the least (or none) of the Unicode characters in the source file, which may be called key
First, define the newly generated binary file header format:
Copy Code code as follows:
0xFEFF. Unicode file header, which is required
The value of the key. In order not to let 0x0000 become key, in the search for the process of ignoring 0x0000
The number of key occurrences is +1. +1 is to avoid this position appears 0x0000, the back is the same
05 06
07 08 The position of the 1th key is stored in 4 bytes for each key.
0A
0B 0C ...
0D 0E
0F 10 The position of the nth key
11 12 File Data content ...
Current 1/2 page
12 Next read the full text
