JavaScript. Подробное руководство, 6-е издание

URL-адреса двоичных объектов имеют то же происхождение (раздел 13.6.2), что и сценарии, создавшие их. Это делает их более универсальными по сравнению с URL-адресами file://, которые имеют иное происхождение, из-за чего последние сложнее использовать в веб-приложениях. URL-адреса двоичных объектов считаются допустимыми только в документах с общим происхождением. Если, например, с помощью метода postMessage передать URL-адрес двоичного объекта в окно с документом, имеющим другое происхождение, для этого окна URL-адрес будет бессмысленным.

URL-адреса двоичных объектов не являются постоянными. Такой URL-адрес перестанет быть действительным, как только пользователь закроет документ или выйдет из документа, в котором был создан этот URL-адрес. Нельзя, например, сохранить URL-адрес двоичного объекта в локальном хранилище и затем повторно использовать его, когда пользователь начнет новый сеанс работы с веб-приложением.

Имеется также возможность вручную «прекращать» действие URL-адреса двоичного объекта вызовом метода URL. revokeObjectURL (или webkitURL.revokeObjectURL), и, как вы могли заметить, пример 22.10 использует эту возможность. Это связано с проблемой управления памятью. После того как миниатюра будет отображена, двоичный объект становится ненужным и его следует сделать доступным для утилизации сборщиком мусора. Но если веб-броузер будет хранить ссылку на созданный двоичный объект в виде URL-адреса двоичного объекта, он не сможет утилизировать его, даже если он не будет больше использоваться в приложении. Интерпретатор JavaScript не может следить за использованием строк, и если URL-адрес по-прежнему остается допустимым, он вправе предположить, что этот адрес все еще используется. Это означает, что интерпретатор не сможет утилизировать двоичный объект, пока не будет прекращено действие URL-адреса. Пример 22.10 работает с локальными файлами, не требующими утилизации, но представьте, какие серьезные утечки памяти могут быть при работе с двоичными объектами, создаваемыми в памяти методом BlobBuilder или загружаемыми с помощью объекта XMLHttpRequest и сохраняемыми во временных файлах.

URL-схема blob:// явно проектировалась как упрощенный вариант схемыи при обращении по URL-адресу blob:// броузеры должны действовать как своеобразные HTTP-серверы. При запросе недействительного URL-адреса двоичного объекта броузер должен послать в ответ код состояния 404 «Not Found». При запросе URL-адреса двоичного объекта с другим происхождением броузер должен вернуть код состояния 403 «Not Allowed». URL-адреса двоичных объектов могут использоваться только в запросах GET, и в случае успешного выполнения запроса броузер должен отправить код состояния 200 «ОК» и заголовок Content-Type со значением свойства type двоичного объекта Blob. Поскольку URL-адреса двоичных объектов действуют как упрощенные URL-адресаих содержимое можно «загружать» с помощью объекта XMLHttpRequest. (Однако, как будет показано в следующем разделе, содержимое двоичного объекта можно прочитать более непосредственным способом - с помощью объекта FileReader.)

22.6.5. Чтение двоичных объектов

До сих пор двоичные объекты были для нас непрозрачными фрагментами данных, которые позволяют обращаться к их содержимому только косвенным способом, посредством URL-адресов двоичных объектов. Объект FileReader дает возможность читать символы или байты, хранящиеся в двоичном объекте, и его можно рассматривать как противоположность объекту BlobBuilder. (Для него больше подошло бы имя BlobReader, поскольку он может работать с любыми двоичными объектами, а не только с файлами.) Так как двоичные объекты могут быть очень большими и храниться в файловой системе, прикладной интерфейс чтения их содержимого действует асинхронно, во многом подобно тому, как действует объект XMLHttpRequest. Фоновым потокам доступна также синхронная версия прикладного интерфейса в виде объекта FileReaderSync, хотя они могут использовать и асинхронную версию.

Чтобы воспользоваться объектом FileReader, сначала необходимо создать его экземпляр с помощью конструктора FileReader. Затем определить обработчики событий. Обычно в приложениях определяются обработчики событий «load» и «error» и иногда - обработчик событий «progress». Сделать это можно посредством свойств onload, onerror и onprogress или с помощью стандартного метода addEventListener. Кроме того, объекты FileReader генерируют события «loadstart», «loadend» и «abort», которые соответствуют одноименным событиям в объекте XMLHttpRequest (раздел 18.1.4).

После создания объекта FileReader и регистрации необходимых обработчиков событий можно передать двоичный объект, содержимое которого требуется прочитать, одному из четырех методов: readAsText, readAsArrayBuffer, readAsDataURL и readAsBinaryString. (Разумеется, можно сначала вызвать один из этих методов и лишь потом зарегистрировать обработчики событий - благодаря однопоточной природе JavaScript, о которой рассказывалось в разделе 22.4, обработчики событий не могут быть вызваны, пока ваша функция не вернет управление и броузер не сможет продолжить цикл обработки событий.) Первые два метода являются наиболее важными, и только они будут описаны здесь. Каждый из этих методов чтения принимает двоичный объект Blob в первом аргументе. Метод readAsText принимает необязательный второй аргумент, определяющий имя кодировки текста. Если кодировка не указана, метод автоматически будет обрабатывать текст в кодировках ASCII и UTF-8 (а также текст в кодировке UTF-16 с маркером порядка следования байтов (byte-order mark, BOM)).

По мере чтения содержимого указанного двоичного объекта объект FileReader будет обновлять значение своего свойства readyState. Первоначально это свойство получает значение 0, показывающее, что еще ничего не было прочитано. Когда становятся доступны какие-нибудь данные, оно принимает значение 1 и по окончании чтения - значение 2. Свойство result хранит частично или полностью прочитанные данные в виде строки или объекта ArrayBuffег. Веб-приложения обычно не опрашивают свойства readyState и result и вместо этого используют обработчик события onprogress или onload.

Пример 22.11 демонстрирует, как использовать метод readAsText для чтения локальных текстовых файлов, выбранных пользователем.

Пример 22.11. Чтение текстовых файлов с помощью объекта FileReader

  <script>
  // Читает указанный текстовый файл и отображает его в элементе <рге> ниже
  function readfile(f) {
   var reader = new FileReader; // Создать объект FileReader
   reader.readAsText(f); // Прочитать файл
   reader.onload = function { // Определить обработчик события
   var text = reader.result; 11 Это содержимое файла
   var out = document.getElementById("output"); // Найти элемент output
   out.innerHTML = // Очистить его
   out.appendChild(document.createTextNode(text));// Вывести содержимое
   } // файла
   reader.onerror = function(e) { // Если что-то пошло не так
   console.log("Error", .e); // Вывести сообщение об ошибке
   };
  }
  </script>
  // Выберите файл для отображения:
  <input type="file" onchange=”readfile(this. files[0])"x/input>
  <pre id="output"x/pre>

Метод readAsArrayBuffer похож на метод readAsText, за исключением того, что требует приложить чуть больше усилий при работе с результатом, возвращая объект ArrayBuffег вместо строки. Пример 22.12 демонстрирует использование метода readAsArrayBuffer для чтения первых четырех байтов из файла в виде целого числа с прямым порядком следования байтов.