Question

我有一个简单的rails应用程序，用于使用canvasContext.toDataURL()将用户创建的图像存储在HTML5网站中。有一个索引操作，显示缩略图列表，以及每个图像的显示操作，显示图像。

我在后端非常懒，我只存储原始图像的base64编码data:image/png;base64,...字符串和缩略图，它也是在客户端生成的。图像使用<img src="data:"/> URI包含在页面中。

现在，由于在v9之前的IE中不完全支持这一点，我将不得不实现某种解决方法，可能是通过使用data-属性包含生成的图像的URL然后替换source属性使用jQuery加载页面后。

这提出了一个问题，即使用data:网址将相当大的图片内嵌到HTML中是否是一种好的做法...

是否有任何建议或最佳做法？图像可能高达500 KiB，并且每个图像仅使用一次。包含图像的页面在创建后不会更改，因此它应该可以缓存，包括图像。包含缩略图（大约60 KiB）的索引页面使用分页，因此页面几乎不可缓存。您可以假设HTML页面将在生产中缩小或压缩。

Answer 1

这不是一个好主意。我会使用普通的单独图像资源。

使用内联图片

你破坏静态图像的所有可缓存性 - 使用内联图像，每次HTML页面更改时，所有图像数据也必须重新加载。
gzipping / deflating将花费更长时间，并产生次优结果（因为图像数据更难以压缩，效率更低）。
互联网的其余部分面向HTML文档和图像是独立的资源：预取程序，缓存系统，代理......
然后你有浏览器兼容性，正如你所指出的，对于较旧的IE来说是糟糕的。

Answer 2

最佳实践是：不要。

无论如何，你需要一个解决方法，这将彻底复制基本功能，所以你只是另一个地方可能出错，还有更多的案例需要测试。

您说图像应该是可缓存的，但您发送它们的方式不允许您包含有关缓存的信息。但是，通过在单独的HTTP请求上发送图像的更常见方法，您可以发送expires和max-age请求，以指示图像一年内不会更改。如果您对图像不会发生变化非常有信心，您还可以设置最后修改过的电子标签（您甚至不需要任何逻辑来决定etag，只需发送“IMMUTABLE”作为标签并且通过发送304甚至没有检查来响应每个条件GET（因为再次，如果你是超级自信，你只会这样做，否则你仍然可以对304实施更传统的检查）

如果图像只使用一次，那么让图像由创建它的东西提供，并根据查询中的某些识别功能（只是特定于您正在做的事情）写入图像并将其写入流中浏览器。您仍然可以在应用程序中更好地分离，以便在自己的位置完成此操作。

即使使用gzip，你也不会在流大小上打败它。

Answer 3

我的建议？不要这样做。

使用后端库可以更轻松地修改真实文件，所以不要。如果您想在页面中使用base64，可以使用HTML5轻松完成。

var xhr = new XMLHttpRequest();
xhr.open('GET', 'images/myimage.png', true);
xhr.responseType = 'arraybuffer';

xhr.onload = function(e){
    if(this.status == 200){
        var bb = new WebKitBlobBuilder(); // Or MozBlobBuilder, MSBlobBuilder, etc.
        bb.append(this.response);

        var reader = new FileReader();
        reader.readAsDataURL(bb.getBlob('image/png'));
        reader.onloadend = function(e){
            $("#myimage").attr("src", reader.result);
        };
    }
};

xhr.send();

使用数据内联图像的最佳实践：-URLs？

3 个答案: