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文件進行緩存也不錯哦；