Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><code>readAsBinaryString</code> says that the data must be represented as a <a href="http://www.w3.org/TR/file-upload/#binary-string" rel="noreferrer"><strong>binary string</strong></a>, where:</p> <blockquote> <p>...every byte is represented by an integer in the range [0..255].</p> </blockquote> <p>JavaScript originally didn't have a "binary" type (until ECMAScript 5's WebGL support of <a href="https://www.khronos.org/registry/typedarray/specs/latest/" rel="noreferrer">Typed Array</a>* <em>(details below)</em> -- it has been superseded by ECMAScript 2015's <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/ArrayBuffer" rel="noreferrer">ArrayBuffer</a>) and so they went with a String with the guarantee that no character stored in the String would be outside the range 0..255. (They could have gone with an array of Numbers instead, but they didn't; perhaps large Strings are more memory-efficient than large arrays of Numbers, since Numbers are floating-point.)</p> <p>If you're reading a file that's mostly text in a western script (mostly English, for instance), then that string is going to look a <em>lot</em> like text. If you read a file with Unicode characters in it, you should notice a difference, since JavaScript strings are <a href="http://www.unicode.org/faq//utf_bom.html#UTF16" rel="noreferrer">UTF-16</a>** <em>(details below)</em> and so some characters will have values above 255, whereas a "binary string" according to the File API spec wouldn't have any values above 255 (you'd have two individual "characters" for the two bytes of the Unicode code point).</p> <p>If you're reading a file that's not text at all (an image, perhaps), you'll probably still get a very similar result between <code>readAsText</code> and <code>readAsBinaryString</code>, but with <code>readAsBinaryString</code> you <em>know</em> that there won't be any attempt to interpret multi-byte sequences as characters. You don't know that if you use <code>readAsText</code>, because <code>readAsText</code> will use an <a href="http://www.w3.org/TR/file-upload/#encoding-determination" rel="noreferrer">encoding determination</a> to try to figure out what the file's encoding is and then map it to JavaScript's UTF-16 strings.</p> <p>You can see the effect if you create a file and store it in something other than ASCII or UTF-8. (In Windows you can do this via Notepad; the "Save As" as an encoding drop-down with "Unicode" on it, by which looking at the data they seem to mean UTF-16; I'm sure Mac OS and *nix editors have a similar feature.) Here's a page that dumps the result of reading a file both ways:</p> <pre><code>&lt;!DOCTYPE HTML&gt; &lt;html&gt; &lt;head&gt; &lt;meta http-equiv="Content-type" content="text/html;charset=UTF-8"&gt; &lt;title&gt;Show File Data&lt;/title&gt; &lt;style type='text/css'&gt; body { font-family: sans-serif; } &lt;/style&gt; &lt;script type='text/javascript'&gt; function loadFile() { var input, file, fr; if (typeof window.FileReader !== 'function') { bodyAppend("p", "The file API isn't supported on this browser yet."); return; } input = document.getElementById('fileinput'); if (!input) { bodyAppend("p", "Um, couldn't find the fileinput element."); } else if (!input.files) { bodyAppend("p", "This browser doesn't seem to support the `files` property of file inputs."); } else if (!input.files[0]) { bodyAppend("p", "Please select a file before clicking 'Load'"); } else { file = input.files[0]; fr = new FileReader(); fr.onload = receivedText; fr.readAsText(file); } function receivedText() { showResult(fr, "Text"); fr = new FileReader(); fr.onload = receivedBinary; fr.readAsBinaryString(file); } function receivedBinary() { showResult(fr, "Binary"); } } function showResult(fr, label) { var markup, result, n, aByte, byteStr; markup = []; result = fr.result; for (n = 0; n &lt; result.length; ++n) { aByte = result.charCodeAt(n); byteStr = aByte.toString(16); if (byteStr.length &lt; 2) { byteStr = "0" + byteStr; } markup.push(byteStr); } bodyAppend("p", label + " (" + result.length + "):"); bodyAppend("pre", markup.join(" ")); } function bodyAppend(tagName, innerHTML) { var elm; elm = document.createElement(tagName); elm.innerHTML = innerHTML; document.body.appendChild(elm); } &lt;/script&gt; &lt;/head&gt; &lt;body&gt; &lt;form action='#' onsubmit="return false;"&gt; &lt;input type='file' id='fileinput'&gt; &lt;input type='button' id='btnLoad' value='Load' onclick='loadFile();'&gt; &lt;/form&gt; &lt;/body&gt; &lt;/html&gt; </code></pre> <p>If I use that with a "Testing 1 2 3" file stored in UTF-16, here are the results I get:</p> <pre>Text (13): 54 65 73 74 69 6e 67 20 31 20 32 20 33 Binary (28): ff fe 54 00 65 00 73 00 74 00 69 00 6e 00 67 00 20 00 31 00 20 00 32 00 20 00 33 00</pre> <p>As you can see, <code>readAsText</code> interpreted the characters and so I got 13 (the length of "Testing 1 2 3"), and <code>readAsBinaryString</code> didn't, and so I got 28 (the two-byte <a href="http://www.unicode.org/faq//utf_bom.html#UTF16" rel="noreferrer">BOM</a> plus two bytes for each character).</p> <hr> <p>* <a href="https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/response" rel="noreferrer">XMLHttpRequest.response</a> with <code>responseType = "arraybuffer"</code> is supported in HTML 5.</p> <p>** <em>"JavaScript strings are UTF-16"</em> may seem like an odd statement; aren't they just Unicode? No, a JavaScript string is <a href="http://www.ecma-international.org/ecma-262/5.1/#sec-8.4" rel="noreferrer">a series of UTF-16 code units</a>; you see surrogate pairs as two individual JavaScript "characters" even though, in fact, the surrogate pair as a whole is just one character. See the link for details.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload