web-dev-qa-db-fra.com

API File de HTML5 - Utilisations BLOB?

J'ai une entrée de fichier: (( jsbin )

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

Qui, lorsque le fichier est sélectionné, montre de petites images de l'image sélectionnée:

Je peux le faire de de deux manières :

en utilisant 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);
    }
    // ...
}

en utilisant 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);
     }
 }

Comme vous pouvez le voir, les deux fonctionnent:

enter image description here

[~ # ~] mais [~ # ~]

Le résultat html est différent:

enter image description here

Question:

Avec le premier, je sais déjà ce que je peux faire, ce sont des données purement data-uri.

Mais quand dois-je utiliser la deuxième approche (blob)? Je veux dire - que puis-je faire blob:http%3A//run.jsbin.com/82b29cc5-8452-4ae2-80ca-a949898f4295?

p.s. mdn explication sur URL.createObjectURL ne m'aide pas quand dois-je utiliser chacun.

javascripthtmlblobfileapi
20
Royi Namir

La longueur d'un blob: L'URL est toujours inférieure à une limite raisonnable.

Les URL de données peuvent être arbitrairement grandes. Par conséquent, lorsqu'une URL de données est trop longue, certains navigateurs (IE, tousse) n'afficheront plus l'image. Donc, si vous voulez afficher de très gros fichiers, utilisez blob: (ou filesystem: URL) pourrait avoir plus de sens que les URL de données.

En outre, vous pouvez récupérer directement les données d'un blob: URL (à condition que le blob n'ait pas encore été révoqué, par exemple parce que le document a été déchargé et que la même politique d'origine n'est pas violée) en utilisant XMLHttpRequest. Par exemple, le code suivant obtient le contenu d'une URL blob sous forme de texte:

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 vous souhaitez soumettre le contenu d'un fichier à un serveur en utilisant XMLHttpRequest, cela n'a pas vraiment de sens d'utiliser un blob: ou data: URL . Soumettez simplement l'objet File directement à l'aide de l'objet FormData . Si vous avez perdu la référence File d'origine et que vous n'avez qu'un blob: URL, vous pouvez ensuite utiliser l'extrait de code précédent pour récupérer à nouveau un objet Blob à utiliser dans FormData.

Donné un data:- URL, il est loin d'être facile de récupérer les données d'origine. Firefox et Opera 12- permettent l'utilisation d'un data:- URL dans XMLHttpRequest. Chrome, Internet Explorer, Safari et Opera 15+ refusent de charger une URL de données via XMLHttpRequest. Donc, en ce qui concerne la récupération de données, blob: Les URL sont également supérieures à data:- URL.

Si vous souhaitez afficher le résultat d'un fichier dans un cadre différent sur la même origine, utilisez certainement un blob: URL. Si vous souhaitez manipuler des données contenues dans un Blob dans un cadre différent (éventuellement sur une origine différente), n'utilisez pas d'URL de blob ou de données , envoyez les données directement en utilisant postMessage .

blob:- Les URL sont généralement meilleures que data:- URL pour représenter les données (binaires). Pour les petites données (max 20 Ko), data: Les URL peuvent être un meilleur choix en raison de la gamme plus élevée de navigateurs pris en charge: comparer puis-je utiliser des URL Blob avec puis-je utiliser des URI de données (bien que si vous écrivez une application HTML5 complexe, il y a de fortes chances que vous n'allez pas prendre en charge IE9-).

39
Rob W

Voici les principales différences dans la façon dont vous pouvez utiliser les deux types d'URL:

URL de données:

Avantages:

  • vous pouvez en extraire des données très facilement
  • vous pouvez les envoyer à un autre utilisateur ou via HTTP, et les données sont toujours là
  • Peu importe où ou comment ils ont été créés, si les données sont valides, vous verrez le contenu dans n'importe quel navigateur, sur n'importe quel système d'exploitation, n'importe où

Les inconvénients:

  • Les URL de données sont souvent d'une longueur prohibitive, de sorte que IE peut ne pas être en mesure de les gérer et peut devenir ennuyeux à gérer dans n'importe quel navigateur
  • Ils sont moins efficaces que les URL BLOB (vous devez lire le fichier pour le créer, vous ne le faites pas avec les BLOB, etc.)

URL BLOB:

Avantages:

  • Ils sont beaucoup plus courts que les URL de données, ce qui les rend beaucoup plus faciles à gérer
  • vous pouvez accéder à leurs données, mais comme l'URL n'est qu'une référence opaque aux données, les données doivent être accessibles à l'aide d'un FileReader et les données ne peuvent pas être extraites directement de l'URL, comme dans les URL de données
  • car ils ont une longueur raisonnable, ils sont plus faciles à gérer et ont un meilleur support IE

Les inconvénients:

  • Les données ne sont pas accessibles dans l'URL elle-même (l'URL est une référence opaque) et elles ne sont pas stockées dans le cloud
  • En raison de la con # 1, vous ne pouvez pas envoyer l'URL au serveur/à un autre utilisateur, car ils ne pourront pas accéder aux données. L'URL est donc uniquement pour vous.
  • Vous ne pouvez pas non plus accéder aux données de l'URL BLOB dans un autre navigateur (même sur la même machine)
  • De plus, vous ne pouvez pas accéder à une URL BLOB à partir d'une origine différente, même sur le même navigateur

Cette liste donne l'impression que les URL de données sont un avantage évident, mais les URL BLOB sont plus rapides à créer et, sauf si vous devez envoyer l'URL à d'autres utilisateurs ou au serveur, vous devez les utiliser car elles sont plus rapides, plus faciles à utiliser , plus gérable et meilleur pour IE. Mais si vous avez besoin d'envoyer une URL au serveur ou à un autre utilisateur, je recommanderais en quelque sorte de transmettre le blob directement en utilisant XHR2. Les URL de données ne sont pas géniales.

11
markasoftware