Base 64编码与加载图像文件

Question

所以我正在研究php中的一些东西，我必须从sql数据库中获取我们的图像，它们将在base64中编码。显示这些图像的速度是至关重要的，所以我试图弄清楚是否更快将数据库数据转换为图像文件，然后将其加载到浏览器中，或者只是回显原始base64数据并使用：

<img src="data:image/jpeg;base64,/9j/4AAQ..." />

FireFox和其他Gecko浏览器支持哪种版本。

所以回顾一下，传输实际图像文件或base64代码会更快。使用ajax加载图像时，它需要更少的http请求吗？

图像总数不会超过100个像素。

Answer 1

• Base64编码使文件更大，因此传输速度更慢。
• 通过在页面中包含图像，每次都必须下载。外部图像通常只下载一次，然后由浏览器缓存。
• 与所有浏览器不兼容

Answer 2

嗯，我不同意你们中的任何人。有些情况下，您需要加载越来越多的图像。并非所有页面都包含3个图像。实际上我正在一个你要加载200多张图像的网站上工作。当100000用户在非常负载的站点上请求200个图像时会发生什么。返回图像的服务器磁盘应该崩溃。更糟糕的是，您需要向服务器发出如此多的请求，而不是使用base64。对于如此多的缩略图，我更喜欢预先保存在数据库中的base64表示。我在http://www.stoimen.com/2009/04/23/when-you-should-use-base64-for-images/找到了解决方案和强有力的论证。这家伙真的是在这种情况下做了一些测试。我印象深刻，也做了我的测试。现实就像它说的那样。对于在一个页面中加载的大量图像，来自服务器的一个响应非常有用。

Answer 3

如果不修改图像，为什么要反复重新生成图像。假设，即使基于1000种不同条件显示1000种不同的可能图像，我仍然认为磁盘上的1000张图像更好。请记住，基于磁盘的映像可以通过浏览器缓存并节省带宽等等。

Answer 4

不要认为data://适用于IE7或以下版本。

当请求图像时，您可以将其保存到文件系统，然后从那时起服务。如果数据库中的图像数据发生更改，则只需删除该文件即可。从img.domain.com也可以从其他域名服务。除非您需要，否则您可以从网络服务器免费获得上次修改或电子标签的所有好处，而无需启动PHP。

如果你正在使用apache：

# If the file doesn't exist:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^/(image123).jpg$ makeimage.php?image=$1

Answer 5

为了回答最初的问题，我进行了一项测试，测量了96 ppi的jpeg图像400x300像素：

base64ImageData.Length
177732

bitmap.Length
129882

Answer 6

这是一个非常快速和简单的解决方案。虽然图像大小将增加大约33％，但使用base64将显着减少http请求的数量。

Google图片和Yahoo图片正在使用base64并在线提供图片。检查源代码，你会看到它。

当然这种方法存在缺点，但我认为其好处超过了成本。 我发现的缺点是设备速度慢。例如，在iPhone 3GS中，谷歌图像提供的图像渲染速度非常慢，因为图像来自服务器，必须在浏览器中解压缩。因此，如果客户的设备速度较慢，那么在渲染图像时他会受到一点影响。

Answer 7

通常，使用base64编码会将字节大小增加大约1/3。因此，您将不得不将1/3字节从数据库移动到服务器中，然后通过线路将这些额外的1/3字节移动到浏览器。

当然，随着图像尺寸的增大，所提到的开销也会按比例增加。

话虽这么说，我认为将文件更改为数据库中的字节表示并传输它们是个好主意。

Answer 8

回答OP问题。 作为静态文件，直接通过Web服务器通过磁盘。 仅100像素时，它们非常适合Web服务器进行内存缓存。 几乎所有在那里的Web服务器都有大量的信息，缓存策略，配置和操作方法。

事实-就用户体验（您所指的图像速度）而言，最好的选择是使用具有CDN功能的对象存储。期间。

“ DB”作为静态存储选择非常昂贵-就所有开销处理，DB的负担，财务负担以及技术债务而言。

一些答案​​中的一些内容

Google图片和Yahoo图片正在使用base64并投放图片 排队。检查源代码，您会看到它。

不。他们绝对不会。图像主要通过静态文件“ Web服务器”提供，具体是gstatic.com： 例如https://ssl.gstatic.com/gb/images/p1_2446527d.png

紧凑-您只有一个文件。同样如果文件被压缩，base64 图像几乎被压缩到普通图像的大小。

实际上，没有优势，再加上压缩所需的处理？

页面在单个请求中检索。 同样，多个并行请求而不是单个较大的负载。

当100000个用户请求在一个非常 已加载的网站。服务器的磁盘，应返回映像 坍方。 您仍将发送相同数量的数据，但是连接时间更长，并且使数据库承受压力。其次，运行具有100000个并发连接的工厂站点的可能性……即使是这样，如果您在单个服务器上运行所有这些，则您是一个愚蠢的管理员。

通过将图像-二进制Blob或base64存储在数据库中，您所做的一切都会增加数据库的巨大开销。要么您拥有大量的RAM，要么通过DB进行的查询无论如何都会从磁盘上消失。 而且，如果DID具有无限的RAM，则可以从Ramdisk提供bin映像-理想情况下，通过子域中配置的备用专用，轻量级Web服务器静态文件和优化的缓存，将是最快，最轻的负载！

前瞻性计划？到目前为止，您只能进行扩展，而扩展数据库则比较昂贵（相对而言）。同样，您说的磁盘将“ sp

在这种情况下，如果您要向100000个并发用户提供100幅图像，则图像的提供应该是CDN对象存储的域。

Answer 9

如果您想要最快的速度，那么您应该在上传/修改它们时将它们写入磁盘，并让Web服务器提供静态文件。 Rojoca的建议也很好，因为它们最小化了php的调用。从另一个域提供服务的另一个好处是（大多数）浏览器会并行发出请求。

除非这一切，当您查询数据时，检查它是否是上次修改，然后将其写入磁盘并从那里进行服务。您需要确保遵守If-Modified-Since标头，以免不必要地传输数据。

如果您无法写入磁盘或其他缓存，那么最好将其作为二进制数据存储在数据库中并将其流出。调整缓冲区大小将有助于此。

Answer 10

我已经使用了base64图像一次或两次图标（10x10像素左右）。

Base64图片专业人士：

• compact - 你有单个文件。如果文件被压缩，base64图像也会被压缩到几乎正常图像的大小。
• 页面在单个请求中被检索。

Base64图像缺点：

• 实际上，你可能需要在包含图像的所有页面上使用脚本引擎（例如PHP）。
• 如果更改了图像，则必须重新下载所有缓存页面。
• 因为图像是内联的，所以不能使用CDN或静态内容Web服务器。

普通图像专业人士：

• 如果你使用SPDY协议，至少理论上，页面+图像+ CSS也会加载单个请求。
• 您可以在图片上设置过期时间，因此内容将从浏览器中缓存。