by zhangxinxu from http://www.zhangxinxu.com
本文地址：http://www.zhangxinxu.com/wordpress/?p=2341

一、base64百科

Base64是网络上最常见的用于传输8Bit字节代码的编码方式之一，可用于在HTTP环境下传递较长的标识信息。

某人： 唉，我彻底废柴了，为何上面明明是中文，洒家却看不懂嘞，为什么？~~

好吧，我也不喜欢专业术语的解释。你只要知道，base64编码就是长得像下面这样子的代码：
thunder://QUFodHRwOi8vd3d3LmJhaWR1LmNvbS9pbWcvc3NsbTFfbG9nby5naWZaWg==

上面代码大家都熟悉吧，迅雷下载链接哦（咳咳，该地址很纯洁），就是base64编码后的地址，所以以后看到这种：一堆连续字母，最后有1~2个"="的代码就是base64。

base64:URL就是URL地址是base64编码的。

例如下面这个：

<img src="data:image/gif;base64,R0lGODlhAwADAIABAL6+vv///yH5BAEAAAEALAAAAAADAAMAAAIDjA9WADs=" />

二、base64与文件数据编码

在网络中，通过HTTP传输的文件还可以通过base64对数据进行编码进行传输。就如上面的这个base64的gif格式图片。当然，可以base64编码的文件不仅仅是图片，也可以是字体文件，例如(中间有缺省)：

@font-face{
    font-family: forTest;
    src: url(data:font/woff;charset=utf-8;base64,d09GRgABAAAAAAh4 ... RFERuENEGADl7JlY=) format('woff');
}

自然，对于background-image图片，我们也可以使用base64编码进行传输，例如：

background-image:url(data:image/gif;base64,R0lGODlhBAABAIABAMLBwfLx8SH5BAEAAAEALAAAAAAEAAEAAAICRF4AOw==);

而使用base64编码作为background-image图片就是本文要着重阐述的。

三、如何获得图片的base64编码

其实在我之前“基于HTML5的可预览多图片Ajax上传”以及“zSlide-基于CSS3/HTML5演示文档jQuery插件”实际上就与图片的base64编码的获取打过交道了。如下本地图片转换成可预览的base64编码的核心脚本：

var reader = new FileReader(), htmlImage;
reader.onload = function(e) {
    htmlImage = '<img src="'+ e.target.result +'" />';    // 这里e.target.result就是base64编码
}
reader.readAsDataURL(file);

上面说的你只需要了解，实际上，目前base64编码工具不少，对于我们前端制作，下面这个本地图片 base64编码获取页面是值得推荐的：Encode Data URL By PuterJam

直接将桌面图片拖到条条里就有了响应的background-image url属性可用的base64地址了：

该转换页面的原理就是上面所说的HTML5 文件本地预览原理，具体可以自己查阅资料。

四、使用base64:URL的优缺点

个人觉得base64:URL传输图片文件的好处在于：

1. 减少了HTTP请求
2. 某些文件可以避免跨域的问题
3. 没有图片更新要重新上传，还要清理缓存的问题

不足在于：

1. 浏览器支持
   使用base64编码图片作为背景图片的这种技术IE6/IE7浏览器是不支持的（IE9浏览器IE7模式下支持，这里被@前端的那点破事鄙视了 ）。对于目前PC页面，兼容性问题使没有文件上传以及无需更新缓存的优点不存在了。
2. 增加了CSS文件的尺寸
   base64编码图片本质上是将图片的二进制大小以一些字母的形式展示，例如一个1024字节的图片，base64编码后至少1024个字符，这个大小会被完全嵌入到CSS文件中（不过幸运的是也可以被gzip了，而图片文件被gzip效果不明显）。
3. 编码成本
   图片完成后还需要base64编码，目前估计手工完成的多，因此，增加了一定的工作量，虽然不多。

五、优缺点权衡下的实际应用价值

权衡上面所展示的优缺点，貌似base64:URL图片没有什么用武之地啊，实际上非也，有一种情况时有base64编码作为background-image背景图片利要远大于弊的。何种情况呢？

在web页面制作的时候，由于某些现实原因，我们可以会用到下面这一类图片：

• 这类图片不能与其他图片以CSS Sprite的形式存在，只能独行
• 这类图片从诞生之日起，基本上很少被更新
• 这类图片的实际尺寸很小
• 这类图片在网站中大规模使用

想想看，你的网站中有没有同时满足上面四条的背景图片呢？

//zxx: 假设已经过去了今天朝鲜火箭勃起的时间

怎样，想到了没？提点下，例如下面这个企鹅微博中的loading gif图片(537字节，勉强算是)：

537字节的大小实际上还是偏大了点，让我们看个更better的例子，大家可以去豆瓣首页，可以看到下图所示的垂直线：

为background-image图片（for 等高布局）：

从bg_line.png这样的命名可以预知（不是：home_bg_line.png），该背景图片会在（可以在）网站中多处使用。

图示平铺图片地址为：http://img3.douban.com/pics/bg_line.png

大小1 * 1 像素，png格式，大小88字节。//zxx: 当图片颜色简单到一定程度的时候，gif格式图片大小要小于png8, 所以，这个点如果保存成gif格式，只需要43字节，为png一半大小

像这种图片大小极小，但又占据了一次HTTP请求，同时不能与其他背景图片Sprite，而网站很多地方都使用。因此，没有什么背景图片比这个更适合使用本文的“base64:URL图片”技术进行优化了！

为了比对优化的好处，我们来看个实际的demo.

六、base64:URL图片的实际应用

我博客首页的个人信息介绍处的虚点是使用背景图片实现的（考虑到IE6 dot边框跟dashed搞基，不同浏览器虚点间距差异等）。

现在，demo就要展示如何使用base64:URL图片实现该虚点效果。

您可以狠狠地点击这里：base64 URL虚点背景demo

相关CSS代码如下：

.dot {
    background-image: url(data:image/gif;base64,R0lGODlhBAABAIABAMLBwfLx8SH5BAEAAAEALAAAAAAEAAEAAAICRF4AOw==);
   *background-image: url(http://www.zhangxinxu.com/wordpress/wp-content/themes/default/images/zxx_dotted.gif);    // IE6~IE7
    background-repeat: repeat-x;
    background-position: left bottom;
}

可以看到，使用base64的CSS代码量基本上跟下面使用完整地址差不多，因此，对于一些级小尺寸图片，所谓增加CSS文件大小的不足可以忽略（再考虑到gzip），同时减少了1个HTTP请求，加上这个图片网站很多地方使用，因此，累积节约的HTTP请求就很惊人了。

当然，唯一美中不足的是，对于IE6~IE7浏览器不能享受到这种“百利仅一害”的优化技术，我们还需要专门为它们擦屁股。不过，权衡来看，还是很值得的，毕竟目前，在中国IE8浏览器是大头（就在最近），IE6, IE7 就乖乖地泻下去吧~~

最后，展示下demo页面YSLOW分析图吧，可以看到，没有任何CSS background-image请求~~

七、虽是一篇小短文，结尾也要干爹疼

IE6/IE7又一次暴露了自己的屌丝形象，对其，我已无力再次吐槽，不过，毕竟历史长河中的有功之人，就等其静静退出历史舞台吧。

再次提醒下，使用base64编码代替CSS背景图片是有局限性的，并不是所有图片都适合使用base64编码这种技术的。例如：
1. CSS Sprite图片后期维护会死人，只能是独立图片
2. 图片尺寸过大，CSS文件就会变成了臃肿的大棒子，反而不利于加载
3. CSS文件的优点就是重用，因此，如果背景图片就一个地方使用，减少的请求数有限，考虑到其他成本，还不如直接使用普通url图片地址
4. 如果图片经常改动，好吧，哥们，苦逼的前端加班仔中就多了一个你

因此，技术本身虽好，需天时地利人和方可使用。

在微博上，@朴灵提过MHTML这个东东，好像与base64编码相关的，对此我几乎一无所知，希望有相关了解的人可以补充下。

另外，周末时节，想着明早可以睡到自然醒，文笔过于仓促，出现错误在所难免，文中有表述不准确的地方欢迎指正，感谢阅读，祝大家周末快乐！

本文为原创文章，转载请注明来自张鑫旭-鑫空间-鑫生活[http://www.zhangxinxu.com]
本文地址：http://www.zhangxinxu.com/wordpress/?p=2341

（本篇完）