webpack-loader 之 url-loader

url-loader vs file-loader

既生瑜，何生亮？

人家当然不是以卖萌为生的，卖萌不可耻，但是url-loader是有它的用处的。url-loader对未设置或者小于limit设置的图片进行转换，以base64的格式被img的src所使用；而对于大于limit byte的图片用file-loader进行解析。

over~~,稍微瞄一下代码，是不是很简单，自己都在偷偷笑了，哇咔咔

不过虽然寥寥几行，还是有不懂得腻：

• 模块入参content是个Buffer类型？

  • Buffer是啥？是node处理二进制数据的接口哦，toString()方法可以帮你把二进制转化成base64格式，Buffer可以吃么，看我
  • 为啥是Buffer类型？这个webpack处理有关系喽~，默认情况下，资源文件会被转换成utf-8字符串传给loader处理。这个代码里我们看到它设置了raw，翻译一下：loader这样就可以接受原始的Buffer了。如何写一个Loader?难道你不想知道么？

• file-loader最后一步干了啥？

  • emitFile(name: string, content: Buffer|String, sourceMap: {...}) 这是 webpack loader context提供的内部方法，根据路径和内容生成一个新的图片，供html以绝对路径的方式进行请求和使用。
  • 在file-loader的option配置中可以将emitFile设置为false，文件不再被重新创建，多用于在服务端模块的使用，图片直接使用服务端的即可。

url-loader 配置

工欲善其事,必先利其器。

看一下官网webpack给出的url-loader的配置参数吧。
戳我

配置名称	类型	默认值	含义
limit	{Number}	undefined	转化为data-url内联使用的文件带下阈值
mimetype	{String}	文件扩展名	文件的mimetype类型（默认使用文件扩展类型）
fallback	{String}	file-loader	在文件大于limit时，交于处理的加载器

在webpack中配置可如下：

编码base64的姿势是什么呢？

知其然之其所以然。

通过url-loader将小图片转换为base64后，面对一长串的它，你是否困惑了呢？它是谁？它又是怎么出现的？

带着这个问题，我们顺路看一下这个小东西的原理吧：

[名字的由来]：通过下面64个可打印的字符来表示二进制数据

[它的原理]：64=2的6次方，因此每6位都可以用一个base64字符表示。而每1个
字节是8位，那么3个字节 = 3 * 8 = 24bit = 6 * 4 = 4个base64字符(这样看来，用base64
表示二进制，比原来二进制表示多了1/3倍的字节)。

[它的步骤]

• 按照字符长度，每3个8bit的字符为一组（不过3的倍数的字符组，用“=”进行填充）
• 根据分组，将每个字符用ASCII进行编码，并将其转换为8bit的二进制，从而得到一组3*8=24bit的字节
  （如果不够24bit，用0进行填充）
• 将24bit划为4个6bit，转换成10进制值，在base64表中查找对应的符号，转换后的字符拼接起来就是最后的结果了.

看一下这个小例子，练练手吧~
“Girl” => “JGlybA==”

用了它，会变得美好一点么？

说了这么多原理，那用了它，对我们有什么实际的好处呢？这个分情况讨论呢。

首先我们要了解一下它的优缺点，这样就好判断使用场景了。

优点 vs 缺点

• 对于比较小的图片，使用base64编码，可以减少一次图片的网络请求；那么对于比较大的图片,使用base64就不适合了，编码会和html混在一起，一方面可读性差，另一方面加大了html页面的大小，反而加大了下载页面的大小，得不偿失了呢，因此设置一个合理的limit是非常有必要的；
• 另一方面，base64编码的图片不能像正常的图片可以进行缓存，因此写在css里面可以让浏览器对css文件进行缓存也不错哦；