做爲前端工程師 de 咱們,平常少不了會跟圖片打交道。在各大電商平臺工做的前端工程師們,感覺可能會更加的明顯。javascript
如下是我以前跟圖片打交道踩到的坑,跟你們分享一下經驗。html
用postman請求接口的時候,返回的是這個圖片(二進制)前端
在chrome的network查看的時候,返回的也是這個圖片(二進制)java
但是,在debug打印的時候,返回的倒是亂碼ios
很明顯,數據的類型已經被改動了。思考緣由,惟一有可能改變數據類型的地方是在axios。git
我去翻看了一下axios的文檔,裏面是這樣描述的github
// `responseType` indicates the type of data that the server will respond with // options are 'arraybuffer', 'blob', 'document', 'json', 'text', 'stream' responseType: 'json', // default
所以,亂碼出現的緣由是由於:axios默認返回的是json文本形式,二進制圖片數據被強制轉換成了json文本形式。chrome
找到了緣由,解決方案就好辦了。咱們在axios裏面,responseType默認返回數據類型是json,將其改成返回數據類型blob。數據庫
export function miniprogramQrcode (params) { return axios.post( env.MI_URL + '/XXXX/XXX/XXXX', params, // 將responseType的默認json改成blob { responseType: 'blob', emulateJSON: true }).then(res => { if (res.data) { return Promise.resolve(res.data) } else { throw res } }).catch(err => { return Promise.reject(err) }) }
接下來的問題是,如何處理blob對象,將其顯示在前端頁面呢?json
代碼以下:
createMiniQrcode (blob) { let img = document.createElement('img') img.onload = function (e) { // 元素的onload 事件觸發後將銷燬URL對象, 釋放內存。 window.URL.revokeObjectURL(img.src) } // 瀏覽器容許使用URL.createObjectURL()方法,針對 Blob 對象生成一個臨時 URL。 // 這個 URL 以blob://開頭,代表對應一個 Blob 對象。 img.src = window.URL.createObjectURL(blob) document.querySelector('.imgQrCode').appendChild(img) }
是否是覺得就這樣結束了? No, No, No. 瞭解如何解決問題還不夠,還須要透過表象進行發散思考。
通常來講,圖片在後端的存儲方式分爲兩種:
其一:能夠將圖片以獨立文件的形式存儲在服務器的指定文件夾中,再將路徑存入數據庫字段中; 其二:將圖片轉換成二進制流,直接存儲到數據庫的 Image 類型字段中.
對於第一種存儲方式,咱們前端直接將存儲路徑賦值給src屬性便可輕鬆顯示。
對於第二種存儲方式,咱們前端須要將其二進制流交由blob對象處理,而後經過blob的API生成臨時URL賦值給src屬性來顯示。
兩種存儲方式都有對應的解決方案,彷佛已經完美解決了關於圖片顯示的問題。可是,咱們的業務場景是多樣且多變的。有時候咱們也會遇到這樣的場景,好比圖片拖拽上傳插件後,自動返回給你了Blob對象,但不幸的是,你發現你又用了一個第三方的服務接口只接收 base64 格式的數據,是否有點欲哭無淚?
那麼,圖片的三種表現形式url、base6四、blob,三者之間是否能夠轉化以知足需求呢?
url to base64 的方法封裝
// 原理: 利用canvas.toDataURL的API轉化成base64 urlToBase64(url) { return new Promise ((resolve,reject) => { let image = new Image(); image.onload = function() { let canvas = document.createElement('canvas'); canvas.width = this.naturalWidth; canvas.height = this.naturalHeight; // 將圖片插入畫布並開始繪製 canvas.getContext('2d').drawImage(image, 0, 0); // result let result = canvas.toDataURL('image/png') resolve(result); }; // CORS 策略,會存在跨域問題https://stackoverflow.com/questions/20424279/canvas-todataurl-securityerror image.setAttribute("crossOrigin",'Anonymous'); image.src = url; // 圖片加載失敗的錯誤處理 image.onerror = () => { reject(new Error('圖片流異常')); }; }
你能夠這樣調用:
let imgUrL = `http://XXX.jpg` this.getDataUri(imgUrL).then(res => { // 轉化後的base64圖片地址 console.log('base64', res) })
base64 to blob 的方法封裝
// 原理:利用URL.createObjectURL爲blob對象建立臨時的URL base64ToBlob ({b64data = '', contentType = '', sliceSize = 512} = {}) { return new Promise((resolve, reject) => { // 使用 atob() 方法將數據解碼 let byteCharacters = atob(b64data); let byteArrays = []; for (let offset = 0; offset < byteCharacters.length; offset += sliceSize) { let slice = byteCharacters.slice(offset, offset + sliceSize); let byteNumbers = []; for (let i = 0; i < slice.length; i++) { byteNumbers.push(slice.charCodeAt(i)); } // 8 位無符號整數值的類型化數組。內容將初始化爲 0。 // 若是沒法分配請求數目的字節,則將引起異常。 byteArrays.push(new Uint8Array(byteNumbers)); } let result = new Blob(byteArrays, { type: contentType }) result = Object.assign(result,{ // jartto: 這裏必定要處理一下 URL.createObjectURL preview: URL.createObjectURL(result), name: `圖片示例.png` }); resolve(result) }) }
你能夠這樣調用:
let base64 = base64.split(',')[1] this.base64ToBlob({b64data: base64, contentType: 'image/png'}).then(res => { // 轉後後的blob對象 console.log('blob', res) })
blob to base64 的方法封裝
// 原理:利用fileReader的readAsDataURL,將blob轉爲base64 blobToBase64(blob) { return new Promise((resolve, reject) => { const fileReader = new FileReader(); fileReader.onload = (e) => { resolve(e.target.result); }; // readAsDataURL fileReader.readAsDataURL(blob); fileReader.onerror = () => { reject(new Error('文件流異常')); }; }); }
你能夠這樣調用:
this.blobToBase64(blob).then(res => { // 轉化後的base64 console.log('base64', res) })
ps: 以上方法是針對玩轉圖片流的優化,感謝原做者。
在這裏貼出url轉base64, base64與blob的相互轉化的demo,其它的會更新在這裏,有興趣能夠戳一下這裏
在前面咱們提到過,圖片在後端的存儲有兩種方式,咱們回顧一下:其一:能夠將圖片以獨立文件的形式存儲在服務器的指定文件夾中,再將路徑存入數據庫字段中;其二:將圖片轉換成二進制流,直接存儲到數據庫的 Image 類型字段中;
那麼這兩種存儲方式,哪一種更優呢?
據我瞭解,在互聯網環境中,大訪問量,數據庫速度和性能方面很重要。通常在數據庫存儲圖片的作法比較少,更多的是將圖片路徑存儲在數據庫中,展現圖片的時候只須要鏈接磁盤路徑把圖片載入進來便可。由於圖片是屬於大字段。一張圖片可能1m到幾m。這樣的大字段數據會加劇數據庫的負擔,拖慢數據庫。在大併發訪問的狀況下很重要。這是一個經驗。去看看dba對數據庫性能調優方面的分析都能獲得這個答案的:就是圖片不要存儲在數據庫中。
所以,若是你司的後端小哥哥常常將圖片以二進制的形式存儲到數據庫而後返回給你對接,你應該知道如何去dui他了吧(滑稽臉)。
更多關於圖片或者文件在數據庫的存儲方式的概括請戳這裏
對於前端來講:
圖片在前端顯示有三種方式:url、base6四、blob
三種顯示方式,哪一種更優雅呢?
url: 通常來講,圖片的顯示仍是建議使用url的方式比較好。若是後端傳過來的字段是圖片路徑的話。
base64:若是圖片較大,圖片的色彩層次比較豐富,則不適合使用這種方式,由於其Base64編碼後的字符串很是大,會明顯增大HTML頁面,影響加載速度。
若是圖片像loading或者表格線這樣的,大小極小,但又佔據了一次HTTP請求,而不少地方都會使用。則很是適用「base64:URL圖片」技術進行優化了!詳細的張鑫旭的Demo演示,請戳這裏一下。
blob: 當後端返回特定的圖片二進制流的時候,就像我第一part裏的情景再現說的,前端用blob容器接收。圖片用blob展現會比較好。
付出,記錄,總結。在項目中遇到的問題我都會一點一滴的記錄整理下來。我相信,這些都是一片一片散落的枝葉,隨着項目經驗的增多,這些枝葉最終必定可以成長爲一棵參天大樹。
文中的觀點受限於本人當前的技術水平,不免會有講錯的地方,歡迎評論區留言交流指正。
隨着技術水平的提高,文章會不按期的迭代而優化~你能夠經過下面的方式聯繫到我。
文章回顧:
參考資料: