有使用Blob来设置内容的原因，而不使用FileReader或URL.createObjectURL

Question

我知道我可以使用FileReader或URL.createObjectURL将Blob解析成一个字符串并用它设置image.src。

但我想知道我是否可以用Blob直接设置图像内容？

Answer 1

你不能用image.src直接设置Blob。 image.src需要您提供基于http链接，base64数据或虚拟blob URL地址的URL。 Blob是一个二进制对象，不属于任何上述选项。正如你所说Blob需要URL.createObjectURL将其转换为可以被image.src识别的虚拟blob url地址。

Answer 2

使用您使用URL.createObejctURL(blob);创建的blobURL。

在评论中，您声明您对浏览器支持和内存使用有疑虑（您甚至谈论内存泄漏......）。

Browser support

只有少数版本的Chrome确实支持FileReader对象，而不支持URL.createObjectURL（IIRC即v14）。 Internet Explorer在IE10中添加了支持，就像它们对Blob对象和FileReader一样。

Memory usage

blobURL只是指向已经在内存中或仅在磁盘上的数据的指针。指针在内存中没有重量。 另一方面，dataURL是二进制数据的字符串表示。它的权重比它所代表的数据多34％左右（因为二进制文件需要映射到更安全的字符）。

现在，要绘制URI的另一端的图像，

• 对于blobURI，浏览器会直接解析它并从中生成位图=>内存使用量〜图像大小的2.5倍（就像从服务器下载一样）。
• 对于dataURI，浏览器首先解析字符串（但不能去除它）以获得对二进制格式（1.34x + 1x）的访问权，然后它将解析它并从中生成位图（+ 2.5x = > 4.84x）。

不仅如此，如果你要在多个地方分配这个dataURI，那么每次你复制字符串时它的数据量会增加1.34倍，并且考虑到缓存dataURI的难度，你最终会使用很多内存代表相同的二进制数据......

内存泄漏？ 不。没有内存泄漏。只是当blob被blobURL引用时，只要blobURL没有被撤销，GarbageCollector就不能收集这个Blob。但鉴于blobURL的生命周期与创建它的Document相关联，它在下次刷新时无论如何都会死亡。 此外，如果您正在处理来自用户磁盘的数据，那么blobURL实际上只是一个指针，并且没有数据存储在内存中。

---

FileReader的readAsDataURL方法实际上只有少数用例，除非您确定必须使用它，否则只需使用blobURL。