Data URI 應用場景小結

時間 2019-12-10

標籤 data uri 應用場景小結简体版

原文原文鏈接

Data URI scheme 在前端開發中是個經常使用的技術，一般會在 CSS 設置背景圖中用到。好比在 Google 的首頁就有用到：php

Data URI scheme 簡稱 Data URI，常常會被錯誤地寫成 data URLs。筆者認爲一般用於將圖片 base64 編碼的 Data URI 能夠稱爲 data URLs，理由是這個地址（經過 base64 編碼的 URL）能夠在瀏覽器地址欄打開，並且 chrome 面板下也用了 "data URLs" 這個名稱，可是廣義的 Data URI 絕對不能夠用 data URLs 來代替，畢竟 URL 只是 URI 的子集。css

若是你是第一次接觸，可能會詫異於這一堆 "亂七八糟" 的編碼是如何生成，打開 http://www.pjhome.net/web/html5/encodeDataUrl.htm，將任意一張圖拖進去，便能自動幫你生成這串 "base64:URL"，接着即可以在任何須要用到圖片 src 屬性的地方，用這個字符串代替。html

Data URI 的格式十分簡單，以下所示：前端

data:[<mime type>][;charset=<charset>][;base64],<encoded data>

第一部分是 data: 協議頭，它標識這個內容爲一個 data URI 資源。
第二部分是 MIME 類型，表示這串內容的展示方式，好比：text/plain（默認），則以文本類型展現，image/jpeg，以 jpeg 圖片形式展現，一樣，客戶端也會以這個 MIME 類型來解析數據。
第三部分是編碼設置，默認編碼是 charset=US-ASCII, 即數據部分的每一個字符都會自動編碼爲 %xx
第四部分是 base64 編碼設定，這是一個可選項，base64 編碼中僅包含 0-9,a-z,A-Z,+,/,=，其中 = 是用來編碼補白的。
最後一部分爲這個 Data URI 承載的內容，它能夠是純文本編寫的內容，也能夠是通過 base64編碼的內容。

咱們先無論它的編碼過程，可能你要問了，這麼費盡周折是爲了啥？這裏就要說到 Data URI 最大的好處，減小 HTTP 請求。一般狀況下咱們在 HTML 頁面中表示一張圖片，會用一個 img 標籤，而後將其 src 屬性指向服務端的一個地址，每一個 img 標籤都會是一次請求；可是用了 Data URI 技術，將圖片編碼成字符串 "內嵌" 入 HTML 代碼中（inline），而後在客戶端完成解碼工做，就不用進行 HTTP 請求了。可是這樣作也有個明顯的缺點，Data URI 沒法進行緩存，因而聰明的工程師通常會把 Data URI 用在 CSS 中，由於 CSS 中的 URL 操做符是用來指定網頁元素的背景圖片的，而瀏覽器並不在乎 URL 裏寫的是什麼——只要能經過它獲取須要的數據。因此，咱們就有了能夠將 Data URL 形式的圖片存儲在 CSS 樣式表中的可能，而全部瀏覽器都會積極的緩存 CSS 文件來提升頁面加載效率。html5

在開發過程當中，其實咱們不經常使用到 Data URI 來表示圖片，在此我將其利弊進行了下彙總。web

利：chrome

減小 HTTP 請求
當訪問外部資源很麻煩或受限時（好比服務器 ip 被牆）
當圖片是在服務器端用程序動態生成，每一個訪問用戶顯示的都不一樣時
當圖片的體積過小，佔用一個 HTTP 會話不是很值得時
沒有圖片更新要從新上傳，還要清理緩存的問題

弊：瀏覽器

Base64 編碼的數據體積一般是原數據的體積 4/3，也就是 Data URL 形式的圖片會比二進制格式的圖片體積大 1/3（好在服務端有 gzip 壓縮，壓縮後和編碼前圖片大小差很少）
Data URL 形式的圖片不會被瀏覽器緩存，這意味着每次訪問頁面時都被下載一次。（這點能夠經過應用在 CSS 中，緩存 CSS 文件解決）
增長了 CSS 文件的尺寸
IE678兼容性，好比 Google 首頁的語音搜索提示圖在 IE8 下直接捨去了（http://www.phpied.com/mhtml-when-you-need-data-uris-in-ie7-and-under/>）
不適合 lazy loading
不利於維護
移動端不宜使用 Data URI 技術（解碼耗 CPU）

那麼，究竟何時該用 Data URI 技術呢？緩存