如果我将图像(jpg或png)转换为base64,它将变大还是具有相同的尺寸?

建议在我的网站上使用base64编码的图像吗?

评论

您唯一想做的事情就是如果您只能使用纯文本资源,并且由于某种原因而无法使用原始图像格式。

这里有一个很好的答案:stackoverflow.com/questions/1533113/…

base64使得无法进行深层链接。这可能是一个加分。

@Wug-知道这是一个迟到的答复,事情已经发生了变化,但是一定可以通过发送bas64来提高性能。通过websocket发送带有base64编码图像(较小的图像)的消息,要比单独请求每个图像更有效率。

这是一个好问题。我一直在寻找“保存二进制图像还是对base64进行编码?”的好答案。我找到了几个像这样的好答案

#1 楼

大约大37%:


非常粗略地讲,Base64编码的二进制数据的最终大小等于原始数据大小的1.37倍。 br />资料来源:http://en.wikipedia.org/wiki/Base64

评论


不能超过原始大小的137%,是原始大小的137%:-)大37%(根据您的来源)。

– Eric J.
2012年7月9日在20:14

我要说的是原始大小的4/3。

– Kiwixz
2014年8月28日在17:16

将图像转换为base64的图像大小是否有限制?

–151291
16 Dec 13'在12:50

@Blender但是对于我来说,当我将一个70kb的位图转换为字符串时,它变成了500kb。不是37%。我已经将一个5mb的图像压缩为70kb,然后将该压缩后的图像转换为字符串,成为了500kb。

– KJEjava48
17年4月19日在6:05



@ KJEjava48:如何将其转换为字符串?

– Blender
17年4月19日在6:14

#2 楼

这是对何时使用base64编码以及何时不使用base64编码的真正有用的概述。用Gzip压缩的二进制文件将具有较小的文件大小。

Takeaway =对UI图标等进行编码和gzip压缩有一些优势,但对较大的图像这样做是不明智的。

#3 楼

在base64中,它将更大。另外,Base64的填充开销很小。并非所有位都与Base64一起使用,因为它最初是为在只能正确处理非二进制数据的系统上对二进制数据进行编码而开发的。
这意味着编码后的图像将大33%-36% (33%来自未使用每个字节2个位,加上可能的填充占了其余3%)。

评论


8/6是1.333,而不是1.25。正如此处其他答案所指出的那样,1.25是不正确的

–ishahak
18小时前

@ishahak是的,已更正它。我确实对接受的答案发表了评论,应该仔细检查我自己的看法。

– Eric J.
8小时前

修好了!

–ishahak
6小时前

#4 楼

答案是:这取决于。

尽管base64-images较大,但在某些情况下base64是更好的选择。

base64-images的大小

Base64使用64个不同的字符,这是2 ^ 6。因此base64每8位字符存储6位。因此,从未转换的数据到base64数据的比例是6/8。这不是精确的计算,而是一个粗略的估计。

示例:

一个48kb的图像大约需要64kb作为base64转换后的图像。

计算: (48/6)* 8 = 64

Linux系统上的简单CLI计算器:
$ cat /dev/urandom|head -c 48000|base64|wc -c
64843


Base64图像和网站

这个问题很难回答。一般来说,使用base64图像越大,感觉越少。但是请考虑以下几点:HTML文件或CSS文件中的许多嵌入式图像可以具有相似的字符串。对于PNG,您经常会发现重复的“ A”字符。使用gzip(有时称为“放气”),甚至可能在尺寸上胜出。但这取决于图像内容。
HTTP1.1的请求开销:尤其是使用很多cookie时,每个请求很容易有几千字节的开销。嵌入base64图像可能节省带宽。
不要对base64编码SVG图像,因为gzip在XML上比在base64上更有效。协调两个相关的请求。
深层链接:如果要防止下载图像,则从HTML页面提取图像会有些棘手。


#5 楼

将图像编码为base64会使图像大30%。

请参阅Wikipedia文章中有关数据URI方案的详细信息,其中指出:


Base64编码的数据URI的大小比其二进制等效文件大1/3。 (但是,如果HTTP服务器使用gzip压缩响应,则此开销将减少到2-3%)


#6 楼

如果要使用base64编码的图像,肯定会花费更多的空间和带宽。但是,如果您的站点上有很多小图像,则可以通过将图像编码为base64并将它们放入html来减少页面加载时间。这样,客户端浏览器将不需要与图像建立大量连接,而是将它们包含在html中。

评论


但是,一旦HTTP 2真正通过,这将不是问题。

–菲利普
16-11-23在16:29

@Philip是的,但是我喜欢将可移植性因素包含在HTML文件中的所有资源。这将有助于在网络参差不齐的区域进行移动Web缓存。

– aalaap
17年4月18日在11:47

@aalaap的问题是,如果您在页面上进行了一次更改,则需要重新加载所有内容,包括图像。如果您将资产分开,则这些资产的使用期限会更高,并且将存储在缓存中,而不是在缓存中重新加载时会在其自身的页面上过期。

–菲利普
17年4月19日在15:05