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类型？这个webpack处理有关系喽~，默认情况下，资源文件会被转换成utf-8字符串传给loader处理。这个代码里我们看到它设置了raw，翻译一下：loader这样就可以接受原始的Buffer了。
-
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文件进行缓存也不错哦；