php Base 64 编码与加载图像文件

Base 64 encode vs loading an image file

提问by teh_noob

So I am working on something in php where I have to get my images from a sql database where they will be encoded in base64. The speed of displaying these images is critical so I am trying to figure out if it would be faster turn the database data into an image file and then load it in the browser, or just echo the raw base64 data and use:

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

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

Which is supported in FireFox and other Gecko browsers.

FireFox 和其他 Gecko 浏览器支持该功能。

So to recap, would it be faster to transfer an actual image file or the base64 code. Would it require less http request when using ajax to load the images?

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

The images would be no more than 100 pixels total.

图像总数不超过 100 像素。

采纳答案by some

Well I don't agree with anyone of you. There are cases when you've to load more and more images. Not all the pages contain 3 images at all. Actually I'm working on a site where you've to load more than 200 images. What happens when 100000 users request that 200 images on a very loaded site. The disks of the server, returning the images should collapse. Even worse you've to make so much request to the server instead of one with base64. For so much thumbnails I'd prefer the base64 representation, pre-saved in the database. I found the solution and a strong argumentation at http://www.stoimen.com/2009/04/23/when-you-should-use-base64-for-images/. The guy is really in that case and made some tests. I was impressed and make my tests as well. The reality is like it says. For so much images loaded in one page the one response from the server is really helpful.

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

回答by some

• Base64 encoding makes the file bigger and therefore slower to transfer.
• By including the image in the page, it has to be downloaded every time. External images are normally only downloaded once and then cached by the browser.
• It isn't compatible with all browsers

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

回答by Mir Nazim

Why regenerate the image again and again if it will not be modified. Hypothetically, even if there are a 1000 different possible images to be shown based on 1000 different conditions, I still think that 1000 images on the disks are better. Remember, disk based images can be cached by the browser and save bandwidth etc etc.

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

回答by esbenr

To answer the initial question, I ran a test measuring a jpeg image 400x300 px in 96 ppi:

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

base64ImageData.Length
177732

bitmap.Length
129882

回答by esbenr

It's a very fast and easy solution. Although the image size will increase about 33% in size, using base64 will reduce significantly the number of http requests.

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

Google images and Yahoo images are using base64 and serving images inline. Check source code and you'll see it.

谷歌图片和雅虎图片使用 base64 并在线提供图片。检查源代码，你会看到它。

Of course there are drawbacks on this approach, but I believe the benefits outweighs the costs. A cons I have found is in slow devices. For example, In iPhone 3GS the images served by google images are very slow to render, since the images come gziped from the server and must be uncompressed in the browser. So, if the customer has a slow device, he will suffer a little when rendering the images.

当然，这种方法有缺点，但我相信收益大于成本。我发现的一个缺点是在慢速设备中。例如，在 iPhone 3GS 中，由 google 图像提供的图像渲染非常慢，因为图像来自服务器的 gzip，必须在浏览器中解压缩。因此，如果客户的设备速度较慢，他在渲染图像时会受到一些影响。

回答by rojoca

Don't think data://works in IE7 or below.

不要认为data://在 IE7 或更低版本中有效。

When an image is requested you could save it to the filesystem then serve that from then on. If the image data in the database changes then just delete the file. Serve it from another domain too like img.domain.com. You can get all the benefits of last-modified, or e-tags for free from your webserver without having to start up PHP unless you need too.

当请求图像时，您可以将其保存到文件系统，然后从那时起提供该图像。如果数据库中的图像数据发生变化，则只需删除该文件。也可以从另一个域（例如 img.domain.com）提供它。您可以从您的网络服务器免费获得 last-modified 或 e-tags 的所有好处，而无需启动 PHP，除非您也需要。

If you're using apache:

如果您使用的是 apache：

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

回答by casperOne

Generally, using base64 encoding is going to increase the byte size by about 1/3. Because of that, you are going to have to move 1/3 bytes from the database into the server, and then move those extra same 1/3 bytes over the wire to the browser.

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

Of course, as the size of the image grows, the overhead mentioned will increase proportionately.

当然，随着图像大小的增长，提到的开销也会成比例地增加。

That being said, I think it is a good idea to change the files into their byte representations in the db, and transmit those.

话虽如此，我认为将文件更改为 db 中的字节表示形式并传输这些文件是个好主意。

回答by Nick

I have used base64 images once or twice for icons (10x10 pixels or so).

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

Base64 images pros:

Base64 图像的优点：

• compact - you have single file. also if file is compressed, base64 image is compressed almost to the size of normal image.
• page is retrieved in single request.

• 紧凑 - 你有一个文件。此外，如果文件被压缩，base64 图像几乎被压缩到普通图像的大小。
• 在单个请求中检索页面。

Base64 images cons:

Base64 图像的缺点：

• to be realistic, you probably need to use scripting engine (such PHP) on all pages that contains the image.
• if image is changed, all cached pages must be re-downloaded.
• because image is inline, you can not use CDN or static content web server.

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

Normal images pros:

普通图像优点：

• if you are use SPDY protocol, at least theoretical, page + images + CSS will load with single request too.
• you can set expiration on the image, so content will be cached from the browsers.

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

回答by Coopz

To answer the OP Question. As static files, directly via disk thru web server. at only 100px they are ideally suited to in memory caching by the Web server. There is a plethora of info ,caching strategies, configs, how-to's for just about every web server out there.

回答 OP 问题。作为静态文件，直接通过磁盘通过 Web 服务器。只有 100px，它们非常适合 Web 服务器的内存缓存。几乎每个 Web 服务器都有大量的信息、缓存策略、配置、操作方法。

Infact - The best option in terms of user experience (the image speed you refer to) is to use a CDN capable object store. period.

事实上 - 就用户体验（您所指的图像速度）而言，最佳选择是使用支持 CDN 的对象存储。时期。

The "DB" as static storage choice is simply expensive - in terms of all the overhead processing, the burden on the DB, as well as financially, and in terms of technical debt.

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

A few things, from several answers

一些事情，来自几个答案

Google images and Yahoo images are using base64 and serving images inline. Check source code and you'll see it.

谷歌图片和雅虎图片使用 base64 并在线提供图片。检查源代码，你会看到它。

No. They absolutely do NOT. Images are mostly served from a static file "web server" Specfically gstatic.com: e.g. https://ssl.gstatic.com/gb/images/p1_2446527d.png

不，他们绝对不会。图像主要由静态文件“网络服务器”提供，特别是 gstatic.com：例如https://ssl.gstatic.com/gb/images/p1_2446527d.png

compact - you have single file. also if file is compressed, base64 image is compressed almost to the size of normal image.

紧凑 - 你有一个文件。此外，如果文件被压缩，base64 图像几乎被压缩到普通图像的大小。

So actually, No advantage at all, plus the processing needed to compress?

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

page is retrieved in single request. Again, multiple parallel requests as opposed to a single larger load.

What happens when 100000 users request that 200 images on a very loaded site. The disks of the server, returning the images should collapse. You will still be sending The same amount of data, but having a Longer connection time, as well as stressing your database. Secondly the odds of a run of the mill site having 100000 concurrent connections... and even if so, if you are running this all of a single server you are a foolish admin.

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

当 100000 个用户在一个负载非常大的网站上请求 200 张图片时会发生什么。服务器的磁盘，返回图像应该崩溃。您仍然会发送相同数量的数据，但连接时间更长，并且会给您的数据库带来压力。其次，运行具有 100000 个并发连接的工厂站点的可能性……即使是这样，如果您在单个服务器上运行所有这些，那么您就是一个愚蠢的管理员。

By storing the images - binary blobs or base64 in the DB, all you are doing it adding huge overhead to the DB. Either, you have masses and masses of RAM, or your query via the DB will come off the disk anyway. And, if you DID have such unlimited RAM, then serving the bin images off a Ramdisk - ideally via an alternative dedicated, lightweight webserver static file & caching optimised, configured on a subdomain, would be the fastest, lightest load possible!

通过在数据库中存储图像 - 二进制 blob 或 base64，您所做的一切都会给数据库增加巨大的开销。要么，你有大量的内存，要么你通过数据库的查询无论如何都会从磁盘上消失。而且，如果您确实拥有如此无限的 RAM，那么从 Ramdisk 提供 bin 图像 - 理想情况下，通过替代的专用轻量级 web 服务器静态文件和缓存优化，在子域上配置，将是最快、最轻的负载！

Forward planning? You can only scale up so far, and scaling a DB is expensive (relatively speaking). Again the disks you say will "sp

前瞻规划？到目前为止，您只能扩展，并且扩展数据库的成本很高（相对而言）。同样，您说的磁盘将“sp

In such a case, where you are serving 100's of images to 100000 concurrent users, the serving of you images should be the domain of CDN Object store.

在这种情况下，您要为 100000 个并发用户提供 100 个图像，您的图像的服务应该是 CDN 对象存储的域。

回答by Richard Levasseur

If you want the fastest speed, then you should write them to disk when they are uploaded/modified and let the webserver serve static files. Rojoca's suggestions are good, too, since they minimize the invocation of php. An additional benefit of serving from another domain is (most) browsers will issue the requests in parallel.

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

Barring all that, when you query for the data, check if it was last modified, then write it to disk and serve from there. You'll want to make sure you respect the If-Modified-Since header so you don't transfer data needlessly.

除此之外，当您查询数据时，请检查它是否最后修改过，然后将其写入磁盘并从那里提供服务。您需要确保尊重 If-Modified-Since 标头，以免不必要地传输数据。

If you can't write to disk, or some other cache, then it would be fastest to store it as binary data in the database and stream it out. Adjusting buffer sizes will help at that point.

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