javascript - read - La API de archivos de Html5-¿Usos BLOB?

read file javascript

Question

Tengo una entrada de archivo: (jsbin)

 <input type="file" accept="image/*" id="input" multiple onchange=''handleFiles(this)'' />

Que, cuando se selecciona el archivo, muestra pequeñas imágenes de la imagen seleccionada:

Puedo hacerlo de dos maneras :

utilizando FileReader:

function handleFiles(t) //t=this
{
var fileList = t.files;
for (var i = 0; i < fileList.length; i++)
{
var file = fileList[i];
var img = document.createElement("img");
img.style... = ...
document.getElementById(''body'').appendChild(img);
var reader = new FileReader();
reader.onload = (function (aImg)
{
return function (e)
{
aImg.src = e.target.result;
};
})(img);
reader.readAsDataURL(file);
}
// ...
}

utilizando ObjectURL / BLOB:

 function handleFiles(t)
{
var fileList = t.files;
for (var i = 0; i < fileList.length; i++)
{
var file = fileList[i];
var img = document.createElement("img");
img.src = window.URL.createObjectURL(file);
img.onload = function (e)
{
window.URL.revokeObjectURL(this.src);
}
document.getElementById(''body'').appendChild(img);
}
}

Como puedes ver, ambos trabajan:

PERO

El resultado html es diferente:

Pregunta:

Con el primero, ya sé lo que puedo hacer, son solo datos de uri de datos.

Pero, ¿cuándo debo usar el segundo enfoque (blob)? Quiero decir, ¿qué puedo hacer blob:http%3A//run.jsbin.com/82b29cc5-8452-4ae2-80ca-a949898f4295 ?

ps mdn explicación sobre URL.createObjectURL no me ayuda acerca de cuándo debo usar cada uno.

Answer 1

Estas son las principales diferencias en cómo puede usar los dos tipos de URL:

URLs de datos:

Pros:

• Usted puede obtener datos de ellos muy fácilmente
• puede enviarlos a otro usuario o a través de HTTP, y los datos aún están allí
• No importa dónde o cómo se crearon, si los datos son válidos, verá el contenido en cualquier navegador, en cualquier sistema operativo, en cualquier lugar

Contras:

• Las direcciones URL de datos a menudo son prohibitivamente largas, por lo que es posible que IE no pueda manejarlas y que resulte molesto manejarlas en cualquier navegador
• Son menos eficientes que las URL de BLOB (tienes que leer el archivo para crearlo, no tienes BLOB, etc.)

BLOB URLs:

Pros:

• Son mucho más cortos que los URL de datos, lo que los hace mucho más manejables
• puede acceder a sus datos, pero como la URL es solo una referencia opaca a los datos, se debe acceder a los datos utilizando un FileReader y los datos no se pueden extraer directamente de la URL, como en las URL de datos
• Debido a que tienen una longitud razonable, son más fáciles de tratar y tienen mejor soporte de IE

Contras:

• No se puede acceder a los datos en la propia URL (la URL es una referencia opaca) y no se almacena en la nube
• Debido a la contra # 1, no puede enviar la URL al servidor / a un usuario diferente, ya que no podrán acceder a los datos. Así que la URL es solo para ti.
• Tampoco puede acceder a los datos desde la URL de BLOB en un navegador diferente (incluso en la misma máquina)
• Además, no puede acceder a una URL BLOB desde un origen diferente, incluso en el mismo navegador

Esta lista hace que parezca que las URL de datos son una ventaja obvia, pero las URL de BLOB son más rápidas de crear y, a menos que necesite enviar la URL a otros usuarios o al servidor, debe usarlas porque son más rápidas y fáciles de usar. , más manejable, y mejor para IE. Pero si necesita enviar una url al servidor oa otro usuario, recomendaría transmitir el blob directamente mediante XHR2. Los urls de datos no son tan buenos.

Answer 2

La longitud de un blob: URL siempre está por debajo de un límite razonable.

Las URL de datos pueden ser arbitrarias de gran tamaño. En consecuencia, cuando una URL de datos es demasiado larga, algunos navegadores (IE, tos ) no volverán a mostrar la imagen. Por lo tanto, si desea mostrar archivos muy grandes, el uso de blob: (o filesystem: URL) podría tener más sentido que los URL de datos.

Además, puede recuperar directamente los datos de un blob: URL ^{(siempre que el blob aún no haya sido revocado, por ejemplo, porque el documento se descargó y no se viola la misma política de origen)} utilizando XMLHttpRequest . Por ejemplo, el siguiente código obtiene el contenido de una URL de blob como texto:

var blobUrl = URL.createObjectURL(new Blob([''Test''], {type: ''text/plain''}));
var x = new XMLHttpRequest();
// set x.responseType = ''blob'' if you want to get a Blob object:
// x.responseType = ''blob'';
x.onload = function() {
alert(x.responseText);
};
x.open(''get'', blobUrl);
x.send();

Si desea enviar el contenido de un archivo a un servidor utilizando XMLHttpRequest , realmente no tiene sentido usar un blob: o data: URL . Simplemente envíe el objeto File directamente usando el objeto FormData . Si perdió la referencia del File original y solo tiene un blob: URL, puede usar el fragmento anterior para obtener un objeto Blob nuevamente para usarlo en FormData .

Dado un data: -URL, no es fácil recuperar los datos originales. Firefox y Opera 12- permiten el uso de data: -URL en XMLHttpRequest . Chrome, Internet Explorer, Safari y Opera 15+ rechazan cargar una URL de datos a través de XMLHttpRequest. Por lo tanto, con respecto a la recuperación de datos, blob: URL también son superiores a los data: -URLs.

Si desea mostrar el resultado de un archivo en un marco diferente en el mismo origen, definitivamente use un blob: URL. Si desea manipular los datos contenidos en un Blob en un marco diferente (posiblemente en un origen diferente), no use Blob o URL de datos , envíe los datos directamente utilizando postMessage .

blob: -URLs generalmente son mejores que los data: -URLs para representar datos (binarios). Para datos pequeños (máximo 20 kb), data: URL de data: pueden ser una mejor opción debido a la mayor variedad de navegadores compatibles: Comparar ¿Puedo usar URLs de blobs con URI de datos ^{(aunque si está escribiendo una aplicación HTML5 compleja, probabilidades) es que no vas a soportar IE9-)} .