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

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

如果不修改,为什么要一次又一次地重新生成图像?假设,即使根据1000种不同的条件显示1000种不同的可能图像,我仍然认为磁盘上的1000种图像更好。记住,基于磁盘的图像可以被浏览器缓存,节省带宽等。

不要以为 data:// 在IE7或更低版本中工作。

当一个映像被请求时,您可以将它保存到文件系统中,然后从那时起提供服务。如果数据库中的图像数据发生更改,则只需删除该文件。从另一个域(如img.domain.com)提供服务。您可以从Web服务器免费获得上次修改的所有好处,或者电子标签,而不必启动PHP,除非您也需要。

如果您使用的是Apache:

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

这是一个非常快速和简单的解决方案。尽管图像大小将增加约33%,但使用base64将显著减少HTTP请求的数量。

Google Images和Yahoo Images正在使用base64并在线服务图像。检查源代码,您将看到它。

当然,这种方法也有缺点,但我相信好处大于成本。 我发现的一个缺点是设备速度慢。例如,在iPhone3GS中,谷歌图片提供的图片渲染速度非常慢,因为这些图片是从服务器上gzip传输的,必须在浏览器中解压缩。因此,如果客户有一个缓慢的设备,他会在渲染图像时受到一些影响。

为了回答最初的问题,我运行了一个测试,测试了一个使用96 ppi的jpeg图像400x300 px:

base64ImageData.Length
177732

bitmap.Length
129882

通常,使用base64编码将使字节大小增加大约1/3。因此,您必须将数据库中的1/3字节移动到服务器中,然后将这些额外的1/3字节通过连接移动到浏览器中。

当然,随着图像大小的增加,上面提到的开销将成比例增加。

也就是说,我认为将这些文件更改为它们在数据库中的字节表示形式并传输它们是一个好主意。

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

除此之外,当您查询数据时,请检查数据是否是上次修改的,然后将其写入磁盘并从中提供服务。您需要确保尊重if-modified-since头,这样就不会不必要地传输数据。

如果您不能写入磁盘或其他缓存,那么将其作为二进制数据存储在数据库中并输出将是最快的。此时调整缓冲区大小将有所帮助。

我曾经使用过一次或两次base64图像作为图标(10x10像素左右)。

base64图像专业:

• 压缩—您只有一个文件。另外,如果文件被压缩,base64图像几乎被压缩到正常图像的大小。
• 在单个请求中检索页。

base64图像对比:

• 为了现实起见,您可能需要在包含图像的所有页面上使用脚本引擎(比如PHP)。
• 如果更改了图像,则必须重新下载所有缓存的页面。
• 因为图像是内联的,所以不能使用cdn或静态内容Web服务器。

普通图像优点:

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