javascript - simple - ¿Qué está haciendo en realidad el método HTML5 File.slice?

upload image js

Question

Estoy trabajando con una API personalizada para permitir que un usuario cargue un archivo (de, con suerte, tamaño arbitrario). Si el archivo es demasiado grande, se dividirá y se manejará en varias solicitudes al servidor.

Estoy escribiendo un código que usa File y FileReader (HTML5) como muchos ejemplos en línea. En general (de lo que leo en línea) para una transferencia de archivos fragmentada, las personas primero obtendrán una cantidad de datos de su objeto de archivo

var file = $(''input[type=file]'')[0].files[0];
var blob = file.slice(start,end)

Luego use un FileReader para leer el blob readAsArrayBuffer(blob) o readAsBinaryString(blob)

Y finalmente en el FileReader.onload(e) , envíe los datos al servidor. Repita este proceso para todos los fragmentos en el archivo.

Mis preguntas son

¿Por qué necesito usar un FileReader ? Si no lo uso, y simplemente envío blobs con File.slice , ¿hay alguna garantía de que la operación de corte se realizará antes de intentar enviar los datos en cada solicitud? ¿ File objeto File carga todo el archivo cuando se crea (seguramente no?). ¿ File.slice busca la posición estipulada por los parámetros y luego lee la información? La documentación no me da pistas sobre cómo se implementa.

Answer 1

Lo importante a tener en cuenta es que File hereda de Blob, File no tiene realmente un método de corte, obtiene este método de Blob. File solo agrega un par de atributos de metadatos.

La mejor manera de pensar en un Blob (o archivo) es como un puntero a los datos, pero no a los datos reales en sí. Algo así como un identificador de archivo en otros idiomas.

En realidad, no se puede acceder a los datos en una Blob sin usar un lector, que se lee de forma asincrónica para evitar el bloqueo de la cadena de interfaz.

El método Blob slice () simplemente devuelve otro Blob, pero nuevamente, esto no es información, es solo un puntero a un rango de datos dentro del Blob original, más o menos como un puntero delimitado a una vista. Para obtener realmente los bytes del Blob cortado, aún necesita usar un lector. En el caso de un blob cortado, su lector está limitado.

Esto solo tiene la intención de ser una conveniencia para que no tenga que llevar un conjunto de desplazamientos relativos y absolutos en su código, solo puede obtener una vista limitada de los datos y usar el lector como si estuviera leyendo desde un byte. 0.

En el caso de XMLHttpRequest (suponiendo que el navegador admita la interfaz más nueva), los datos serán transmitidos en el envío y restringidos por los límites del blob. Básicamente, funcionará de la misma forma en que te imaginas que funcionaría si enviaste un puntero a un método de transmisión (que es básicamente lo que está pasando debajo de las coberturas). https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Sending_and_Receiving_Binary_Data#Sending_binary_data

Básicamente, es un lector perezoso. Si el blob ya está cargado / leído desde el sistema de archivos, o fue creado en la memoria, simplemente va a usar eso. Sin embargo, cuando estés utilizando un archivo, se cargará de forma perezosa y se transmitirá de forma asíncrona fuera del hilo principal.

La lógica básica aquí es que los desarrolladores de navegadores nunca quieren que una lectura ocurra sincrónicamente porque podría bloquear el hilo principal, por lo que todas las API están diseñadas en torno a esa filosofía central. Observe cómo Blob.slice () es sincrónico: así es como sabe que no está haciendo ningún IO, simplemente está configurando límites y (posiblemente) punteros de archivo.