Base64編碼每天在互聯(lián)網(wǎng)上傳輸數(shù)十億次，卻極少有人停下來問：為什么偏偏是64個字符？為什么3字節(jié)非要拆成4個字符？這個1978年誕生的算法，至今仍在你的JWT令牌、郵件附件、CSS內(nèi)嵌圖片里默默運(yùn)轉(zhuǎn)。

本文用一組具體數(shù)字拆解它的工作原理，以及開發(fā)者最常踩的5個坑。

從24比特到4個字符：一個刻意的設(shè)計

Base64的核心操作極其機(jī)械：每3字節(jié)（24比特）輸入，切成4個6比特組，每組映射到64個可打印字符之一。64個字符剛好是A-Z、a-z、0-9，加上+和/，再用=做補(bǔ)位填充。

這個設(shè)計的代價很明確：編碼后體積膨脹33%。3字節(jié)變4字符，沒有壓縮，沒有加密，只是為了讓二進(jìn)制數(shù)據(jù)能安全穿過只認(rèn)文本的系統(tǒng)——1980年代的電子郵件、HTTP頭、URL參數(shù)、JSON字段。

輸入"Man"的完整過程：二進(jìn)制是01001101 01100001 01101110，切成010011、010110、000101、101110四組，對應(yīng)Base64字符T、W、F、u。沒有魔法，只有位運(yùn)算。

5個真實使用場景，以及它們的隱藏成本

場景一：HTML/CSS內(nèi)嵌圖片。把小圖標(biāo)轉(zhuǎn)成Data URL可以省掉一次HTTP請求，但Base64字符串會讓圖片體積膨脹約33%。Google的PageSpeed Insights明確建議：超過2KB的圖片就別內(nèi)嵌了，省下的請求時間抵不上傳輸膨脹。

場景二：HTTP Basic認(rèn)證。Authorization頭里的Basic dXNlcjpwYXNzd29yZA==看著像加密，實則是user:password的明文轉(zhuǎn)碼。RFC 7617文檔強(qiáng)調(diào)：沒有HTTPS時，這種編碼"不提供任何機(jī)密性保護(hù)"。

場景三：JWT令牌結(jié)構(gòu)。一個標(biāo)準(zhǔn)JWT是三段Base64url編碼用點號連接：頭部、載荷、簽名。中間那段payload解碼后就是JSON明文，包含用戶ID和權(quán)限。很多人誤以為JWT加密了數(shù)據(jù)，其實它只是簽名防篡改，內(nèi)容對任何能拿到令牌的人都是透明的。

場景四：JSON傳二進(jìn)制文件。API返回PDF或圖片時，常見這種結(jié)構(gòu)：

{ "filename": "invoice.pdf", "content": "JVBERi0xLjQKJeLjz9MKMSAwIG9iag..." }

content字段就是Base64編碼的文件內(nèi)容。這是MIME（多用途互聯(lián)網(wǎng)郵件擴(kuò)展）標(biāo)準(zhǔn)的遺產(chǎn)，從1992年的電子郵件附件延續(xù)至今。

場景五：數(shù)據(jù)庫存二進(jìn)制。Redis字符串類型、部分NoSQL系統(tǒng)用Base64存證書或密鑰。代價是存儲空間和讀寫時的編解碼CPU開銷，但換來了跨系統(tǒng)文本傳輸?shù)募嫒菪浴?/p>

開發(fā)者最常踩的3個坑

坑一：把編碼當(dāng)加密。Base64的解碼不需要密鑰，瀏覽器控制臺輸入atob("dGVzdA==")就能還原。見過把用戶密碼Base64存數(shù)據(jù)庫的案例，這等于明文存儲。

坑二：URL安全版本混淆。標(biāo)準(zhǔn)Base64含+和/，在URL里會被轉(zhuǎn)義成%2B和%2F，增加長度。JWT用的是Base64url變體，把+換成-、/換成_、去掉=填充?；煊脙烧邥?dǎo)致簽名驗證失敗。

坑三：忽略體積膨脹。把1MB圖片Base64編碼塞進(jìn)JSON，實際傳輸1.33MB。移動端弱網(wǎng)環(huán)境下，這33%的額外流量可能直接拖垮體驗。

JavaScript和Python的調(diào)用方式足夠簡單：前者用btoa()/atob()或Buffer.from(str).toString('base64')，后者用base64.b64encode()。但工具順手不代表理解到位——知道什么時候不該用，比知道怎么用更重要。

這個48年前的算法至今沒有退役跡象。當(dāng)你下次復(fù)制一段JWT令牌到解碼網(wǎng)站時，不妨想想：如果當(dāng)年電子郵件系統(tǒng)能直接傳二進(jìn)制，我們今天會用什么？