Data URL真的适合你吗?

偶尔转载微信公众号文章的诸位，一定对下面的这段代码非常熟悉。腾讯为了控制域外的外链流量，不仅设置了referrer防盗链机制、还把图片的链接做了base64转码加密，可谓“用心良苦”。

![](https://mmbiz.qpic.cn/mmbiz_jpg/m5HKPtbKaBztAyias8s4ibypibJhmC9EEs6QTTSHtk16VlkIYEib5PFfzE8uAIlcIsO5fd1nZ5SVdj14XwGXIRCHYg/640?wx_fmt=jpeg&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1 "公司.jpg")

事实上，不仅把图片的URL Link转码，那自然可以利用Data URL技术把图片本身images转成一段base64字符串存储在URL中，并冠以mime-type的媒体资源类型。

标准格式：

![avatar](data:image/png;base64,iVBORw0......)

例如下面这幅漫画是大島司 -《Attack!!》的开场白：

如果转换为bash64码，那就是

data:image/jpeg;base64,/9j/4QCpRXhpZgAATU0AKgAAAAgABgEaAAQAAAABAAABLAEbAAQAAAABAAABLAEoAAMAAAABAAIAAAESAAMAAAABAAEAAAExAAIAAAATAAAAVIdpAAQAAAABAAAAawAAUG9sYXJyIFBob3RvIEVkaXRvcgAAAAAABKACAAQAAAABAAADhKADAAQAAAABAAACiqABAAMAAAABAAEAAJAAAAcAAAAEMDIzMQAAAAD/2wCEAAIBAQEBAQIBAQECAgICAgQDAgICAgUEBAMEBgUGBgYFBgYGBwkIBgcJBwYGCAsICQoKCgoKBggLDAsKDAkKCgoBAgICAgICBQMDBQoHBgcKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCv/AABEIAooDhAMBEQACEQEDEQH/……（此处省略一万字）

如所见，一张300kb图片经base64加密，会产生401.03 KB的长字符，上百行的代码会把整篇流畅的文章割割离得支零破碎，如果图片数目多，非常影响编写文章时的体验。

缓解的思路之一就是把大段的base64字符串后置。放在文章末尾，然后在文章中通过一个id来调用，就像论文页脚的注释和参考文档一样。

这也是之前在《markdown插图的另一种写法 》提到markdown两种链接写法之一reference link，它可以使得markdown文件更加易读。
具体写法如下：

![avatar][ID1]
……
……
[ID1]: data:image/png;base64,iVBORw0......

使用 Data Url 的不足：

Markdown文档体积会增大，具体视文章附图的数量、大小而定。

使用 Data Url 的优点：

减少markdown文件的外部链接数，但与此同时，又增加了一个标记ID的内链，实则这是一种掩耳盗铃的做法。

因此，在把Data URL嵌入你的markdown文件前，必须想清楚下列问题：

• 下载一张图片的速度快，还是下载一堆编码快？

提示：Base64编码的数据体积通常是原数据的体积4/3，也就是Data URL形式的图片会比二进制格式的图片体积大1/3。

• 浏览器对图片的显示，处理效率哪个更快？

提示：当图片是在服务器端用程序动态生成，每个访问用户显示的都不同时。
当图片的体积太小，占用一个HTTP会话不是很值得时。

• 图片是否需要缓存或者cdn化？

提示：Data URL形式的图片不会被浏览器缓存，这意味着每次访问这样页面时都被下载一次。这是一个使用效率方面的问题——尤其当这个图片被整个网站大量使用的时候。

测试数据显示，使用Data URL方式的Demo在渲染时会比不使用多消耗53%左右的CPU资源，内存多出4倍左右，耗时平均高出24.6倍。