<body> <!-- Изначально в документе имеется только площадка сброса -->
<div id="droptarget">C6pocbTe сюда файлы изображений</div>
</body>
</html>
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
хранит частично или полностью прочитанные данные в виде строки или объекта