.net保存base64图片_图片Base64编码的利与弊分析

图片处理在前端工作中可谓占据了很重要的一壁江山。而图片的 base64 编码可能相对一些人而言比较陌生&＃xff0c;本文不是从纯技术的角度去讨论图片的 base64 编码。标题略大&＃xff0c;不过只是希望通过一些浅显的论述&＃xff0c;让你知道什么是图片的 base64 编码&＃xff0c;为什么我们要用它&＃xff0c;我们如何使用并且方便的使用它&＃xff0c;并让你懂得如何去在前端的实际工作中运用它。

什么是 base64 编码?

我不是来讲概念的&＃xff0c;直接切入正题&＃xff0c;图片的 base64 编码就是可以将一副图片数据编码成一串字符串&＃xff0c;使用该字符串代替图像地址。

这样做有什么意义呢&＃xff1f;我们知道&＃xff0c;我们所看到的网页上的每一个图片&＃xff0c;都是需要消耗一个 http 请求下载而来的(所有才有了 csssprites 技术的应运而生&＃xff0c;但是 csssprites 有自身的局限性&＃xff0c;下文会提到)。

没错&＃xff0c;不管如何&＃xff0c;图片的下载始终都要向服务器发出请求&＃xff0c;要是图片的下载不用向服务器发出请求&＃xff0c;而可以随着 HTML 的下载同时下载到本地那就太好了&＃xff0c;而 base64 正好能解决这个问题。

那么图片的 base64 编码长什么样子呢&＃xff1f;举个栗子。www.google.com 的首页搜索框右侧的搜索小图标使用的就是base64编码。我们可以看到&＃xff1a;

//在css里的写法

#fkbx-spch, #fkbx-hspch {

background: url(data:image/gif;base64,R0lGODlhHAAmAKIHAKqqqsvLy0hISObm5vf394uLiwAAAP///yH5B…EoqQqJKAIBaQOVKHAXr3t7txgBjboSvB8EpLoFZywOAo3LFE5lYs/QW9LT1TRk1V7S2xYJADs&＃61;) no-repeat center;

}

//在html代码img标签里的写法

为什么要使用 Base64 编码&＃xff1f;

那么为什么要使用 base64 传输图片文件&＃xff1f;上文也有提及&＃xff0c;因为这样可以节省一个 http 请求。图片的 base64 编码可以算是前端优化的一环。效益虽小&＃xff0c;但却缺能积少成多。

说到这里&＃xff0c;不得不提的是 CssSprites 技术&＃xff0c;后者也是为了减少 http 请求&＃xff0c;而将页面中许多细小的图片合并为一张大图。那么图片的 base64 编码和 CssSprites 有什么异同&＃xff0c;又该如何取舍呢&＃xff1f;

所以&＃xff0c;在这里要明确使用 base64 的一个前提&＃xff0c;那就是被 base64 编码的图片足够尺寸小。以博客园的 logo 为例&＃xff1a;

如图所示&＃xff0c;博客园的 Logo 只有 3.27KB&＃xff0c;已经很小了&＃xff0c;但是如果将其制作转化成 base64 编码&＃xff0c;生成的 base64 字符串编码足足有 4406 个,也就是说&＃xff0c;图片被编码之后&＃xff0c;生成的字符串编码大小一般而言都会比原文件稍大一些。即便 base64 编码能够被 gzip 压缩&＃xff0c;压缩率能达到 50% 以上&＃xff0c;想象一下&＃xff0c;一个元素的 css 样式编写居然超过了 2000个 字符&＃xff0c;那对 css 整体的可读性将会造成十分大的影响&＃xff0c;代码的冗余使得在此使用 base64 编码将得不偿失。

那么&＃xff0c;是不是表示 base64 编码无用武之地呢&＃xff1f;不然。当页面中的图片满足以下要求&＃xff0c;base64 就能大显生手。

如果图片足够小且因为用处的特殊性无法被制作成雪碧图(CssSprites)&＃xff0c;在整个网站的复用性很高且基本不会被更新。

那么此时使用 base64 编码传输图片就可谓好钢用在刀刃上&＃xff0c;思前想后&＃xff0c;符合这个规则的&＃xff0c;有一个是我们经常会遇到的&＃xff0c;就是页面的背景图 background-image 。在很多地方&＃xff0c;我们会制作一个很小的图片大概是几px*几px&＃xff0c;然后平铺它页面当背景图。因为是背景图的缘故&＃xff0c;所以无法将它放入雪碧图&＃xff0c;而它却存在网站的很多页面&＃xff0c;这种图片往往只有几十字节&＃xff0c;却需要一个 http 请求&＃xff0c;十分不值得。那么此时将它转化为 base64 编码&＃xff0c;何乐而不为&＃xff1f;

下面是一个只有 50 字节的2*2的的背景图。将其转化成 base64 编码&＃xff0c;只有 100 多个字符&＃xff0c;相比一个 http 请求&＃xff0c;这种转换无疑更值得推崇。

CssSprites与Base64编码

简单陈述一下我对何时这使用这两种优化方法的看法。

使用CssSprites合并为一张大图&＃xff1a;

• 页面具有多种风格&＃xff0c;需要换肤功能&＃xff0c;可使用CssSprites
• 网站已经趋于完美&＃xff0c;不会再三天两头的改动(例如button大小、颜色等)
• 使用时无需重复图形内容
• 没有 Base64 编码成本&＃xff0c;降低图片更新的维护难度。(但注意 Sprites 同时修改 css 和图片某些时候可能造成负担)
• 不会增加 CSS 文件体积

使用base64直接把图片编码成字符串写入CSS文件&＃xff1a;

• 无额外请求
• 对于极小或者极简单图片
• 可像单独图片一样使用&＃xff0c;比如背景图片重复使用等
• 没有跨域问题&＃xff0c;无需考虑缓存、文件头或者COOKIEs问题

更便捷的将图片转化为Base64编码

将图片转化为 base64 编码有许多工具&＃xff0c;例如本文中我所使用的 http://www.pjhome.net/web/html5/encodeDataUrl.htm &＃xff0c;但是很多这些网站是国外网站&＃xff0c;经常被墙登陆不了。这里介绍一个更为快捷的方法&＃xff0c;就是利用 Chrome 浏览器(我想 FEer 都应该有Chrome 浏览器吧&＃61;。&＃61;)。

在 chrome 下新建一个窗口&＃xff0c;然后把要转化的图片直接拖入浏览器&＃xff0c;打开控制台&＃xff0c;点 Source&＃xff0c;如下图所示&＃xff0c;点击图片&＃xff0c;右侧就会显示该图片的 base64 编码&＃xff0c;是不是很方便。

Base64 虽有优点&＃xff0c;但是缺点也很明显&＃xff0c;在使用上存在一些明显的缺陷。

1. 使用 Base64 不代表性能优化

是的&＃xff0c;使用 Base64 的好处是能够减少一个图片的 HTTP 请求&＃xff0c;然而&＃xff0c;与之同时付出的代价则是 CSS 文件体积的增大。

而 CSS 文件体积的增大意味着什么呢&＃xff1f;意味着 CRP 的阻塞。

CRP(Critical Rendering Path&＃xff0c;关键渲染路径)&＃xff1a;当浏览器从服务器接收到一个HTML页面的请求时&＃xff0c;到屏幕上渲染出来要经过很多个步骤。浏览器完成这一系列的运行&＃xff0c;或者说渲染出来我们常常称之为“关键渲染路径”。

通俗而言&＃xff0c;就是图片不会导致关键渲染路径的阻塞&＃xff0c;而转化为 Base64 的图片大大增加了 CSS 文件的体积&＃xff0c;CSS 文件的体积直接影响渲染&＃xff0c;导致用户会长时间注视空白屏幕。HTML 和 CSS 会阻塞渲染&＃xff0c;而图片不会。

2. 页面解析 CSS 生成的 CSSOM 时间增加

Base64 跟 CSS 混在一起&＃xff0c;大大增加了浏览器需要解析CSS树的耗时。其实解析CSS树的过程是很快的&＃xff0c;一般在几十微妙到几毫秒之间。

CSS 对象模型 (CSSOM)&＃xff1a;CSSOM是一个建立在web页面上的 CSS 样式的映射&＃xff0c;它和DOM类似&＃xff0c;但是只针对CSS而不是HTML。

CSSOM 生成过程&＃xff1a;

CSSOM 生成过程大致是&＃xff0c;解析 HTML &＃xff0c;在文档的 head 部分遇到了一个 link 标记&＃xff0c;该标记引用一个外部 CSS 样式表&＃xff0c;下载该样式表后根据上述过程生成 CSSOM 树。 这里我们要知道的是&＃xff0c;CSSOM 阻止任何东西渲染&＃xff0c;(意味着在CSS没处理好之前所有东西都不会展示)&＃xff0c;而如果CSS文件中混入了Base64&＃xff0c;那么(因为文件体积的大幅增长)解析时间会增长到十倍以上。

而且&＃xff0c;最重要的是&＃xff0c;增加的解析时间全部都在关键渲染路径上。

所以&＃xff0c;当我们需要使用到 Base64 技术的时候&＃xff0c;一定要意识到上述的问题&＃xff0c;有取舍的进行使用。