1. 首頁 > 生活百科 > >

還在用 URL 傳小圖片？Base64 才是 API 設計的性能利器

瀏覽器

text":"1 咋在文本世界傳輸二進制數據？HTTP協議、JSON、HTML、CSS這些都是基于文本 。 設計初衷是傳輸字符如 'A' 'B' 'C' '1' '2' '3' 。 而一張圖片（JPG、PNG or GIF）本質是二進制數據 ， 它包含大量在標準文本協議中無法直接表示的字節 ， 如 0x89 0x50 0x4E 0x47 (PNG文件頭) 。 直接將這些二進制數據塞進一個 JSON 字符串 ， 很可能因遇到非法的控制字符導致解析失敗 。 好比你想把一瓶水（二進制數據）裝進一個只能放信件（文本數據）的信封里 ， 直接倒是倒不進去的 。 需\"轉換\"步驟 。 Base64 編碼就是這\"轉換器\" 。 2 啥是Base64？一種編碼方式 ， 而非加密算法 。 核心作用將任意二進制數據轉換成一串由64個常見、可打印的 ASCII 字符組成的文本字符串 。 這64個字符通常是 A-Z a-z 0-9 + / 。 工作原理它將每 3 個字節的二進制數據（3 * 8 = 24位）拆分成 4 組 ， 每組 6 位 。 由于 2^6 = 64 ， 所以每一組 6 位的數據都可以用一個預定義的 ASCII 字符來表示 。 這樣 ， 3 個字節的二進制數據就變成 4 個字符的文本數據 。 這個過程保證轉換后的字符串是\"純文本\" ， 可安全在任何文本協議或格式中傳輸 ， 不引起任何歧義 。 3 為啥后端要用 Base64 編碼圖片？Captcha.java 中 ， getBase64ByteStr() 方法就是這個過程的核心 。 將內存中生成的驗證碼圖片（二進制數據）轉換成了 Base64 字符串 。 這么做的關鍵優勢：3.1 減少 HTTP 請求 ， 提升性能通常 ， 瀏覽器顯示一張圖片需要發起一次獨立的 HTTP 請求：每次 HTTP 請求都有其開銷（TCP 握手、HTTP 頭部等） ， 像驗證碼、小圖標這類體積很小的圖片 ， 請求的開銷甚至可能比圖片本身的數據量還大 。 若一個頁面有幾十個這樣小圖標 ， 就產生幾十次額外 HTTP 請求 ， 嚴重影響加載速度 。 而用 Base64 ， 圖片數據可直接嵌入（Embed）到 HTML 或 JSON 響應中 ， 瀏覽器無需再為這張圖片發起新的請求 。 3.2 簡化數據傳輸 ， 實現數據原子性很多場景下 ， API需一次性返回結構化數據和圖片 。 如一個獲取驗證碼的接口：不僅要返回圖片可能還要返回一個用于后續驗證的唯一ID若不用 Base64 ， API設計會很復雜：方案A（兩次請求）：前端先請求一個接口獲取 captchaId ， 再用這 ID 去請求另一個接口獲取圖片 。 增加前端邏輯復雜度和請求次數方案B（復雜響應）：后端用 multipart/form-data 格式 ， 在一個響應里同時返回 JSON 部分和圖片二進制部分 。 服務端和客戶端處理起來都麻煩而用 Base64 ， 一切都變得簡單 。 后端直接返回一個 JSON 對象 ， 圖片數據作為其中的一個字符串字段：{\"success\": true\"data\": {\"captchaId\": \"a1b2-c3d4-e5f6-g7h8\"\"captchaImage\": \"data:image/jpg;base64iVBORw0KGgoAAAANSUhEUgAAAHgAAAAyCAY...\" // Base64 字符串前端一次請求就能拿到所有需要的數據 ， 實現數據傳輸的原子性 ， 極大簡化前后端交互 。 3.3 數據封裝與可移植性圖片以 Base64 形式嵌入后 ， 數據是自包含的 。 如可將一個包含 Base64 圖片的 HTML 文件保存到本地 ， 斷網后打開 ， 圖片依然能夠正常顯示 ， 因為它就是文件的一部分 。 4 前端咋解碼并顯示圖片？前端神奇之處 ， 也最易讓人誤解 。 前端開發者幾乎無需手動進行任何\"解碼\"操作 。 這個工作由瀏覽器自動完成 ， 關鍵在 Data URI Scheme 技術 。 4.1 Data URI Scheme 規范Captcha#getBase64ByteStr()方法中：return \"data:image/jpg;base64\" + s;這正是 Data URI 的標準格式：data:[
[;base64
**data:**：協議頭 ， 告訴瀏覽器這是一個 Data URIimage/jpg：MIME 類型 (Media Type) 。 這部分至關重要 ， 它告訴瀏覽器這段數據應該被解釋成一張 JPG 格式的圖片 。 如果是 PNG ， 就是 image/png;base64：一個標志 ， 明確告訴瀏覽器后面的數據是經過 Base64 編碼的****：分隔符：真正的 Base64 編碼字符串4.2 前端實踐當瀏覽器在標簽的 src 屬性或 CSS 的 url() 中看到 data: 開頭的字符串時 ， 它會自動執行以下操作：識別出這是一個 Data URI 。 讀取 MIME 類型（如 image/jpg）看到 ;base64 標志 ， 自動對后面的數據進行 Base64 解碼 ， 將其還原成原始的二進制數據根據 MIME 類型 ， 將解碼后的二進制數據渲染成一張圖片前端代碼示例假設前端通過 fetch 調用后端的驗證碼接口：// 1. 獲取 DOM 元素const captchaImgElement = document.getElementById('captchaImage');const captchaIdInput = document.getElementById('captchaId');// 2. 發起 API 請求fetch('/api/captcha').then(response => response.json()).then(result => {if (result.success) {// 3. 將返回的 Base64 字符串直接賦值給的 src 屬性// 瀏覽器會自動完成解碼和渲染！captchaImgElement.src = https://mparticle.uc.cn/api/result.data.captchaImage;// 保存 captchaId 用于后續提交captchaIdInput.value = result.data.captchaId;).catch(error => console.error('Error fetching captcha:' error));HTML 部分可能長這樣：前端代碼非常直觀 ， 完全不涉及復雜解碼邏輯 。 5 總結特性 Base64 編碼 傳統 URL 鏈接 HTTP請求 無額外請求 ， 嵌入在主文檔中 需要一次獨立的 HTTP 請求 數據大小 編碼后體積增大 約33% 原始二進制大小 瀏覽器緩存 無法獨立緩存 ， 隨主文檔緩存 可被瀏覽器獨立、高效地緩存 適用場景 小體積、不常變動、需要原子性傳輸的圖片（驗證碼、圖標） 大體積、需要被緩存、被多處引用的圖片（文章配圖、背景圖）Captcha.java 中使用 Base64 是一種非常明智和高效的設計 。 對于驗證碼這種\"一次性\"、體積小、且需要和 captchaId 捆綁返回的場景 ， Base64 的優勢（減少請求、簡化交互）遠大于其劣勢（體積增大） 。 而對于網站的大背景圖、用戶上傳的相冊等 ， 則應該使用傳統的 URL 鏈接方式 ， 以充分利用瀏覽器緩存 ， 并避免傳輸大量冗余的 Base64 文本 。 本文已收錄在Github ， 關注我 ， 緊跟本系列專欄文章 ， 咱們下篇再續！ 魔都架構師 | 全網30W技術追隨者 大廠分布式系統/數據中臺實戰專家 主導交易系統百萬級流量調優 & 車聯網平臺架構 AIGC應用開發先行者 | 區塊鏈落地實踐者 以技術驅動創新 ， 我們的征途是改變世界！ 實戰干貨：編程嚴選網"

    推薦閱讀