谷歌把3字節(jié)變成4字符的算法，程序員用了30年還沒換

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

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

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

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

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

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

5個(gè)真實(shí)使用場(chǎng)景，以及它們的隱藏成本

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

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

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

場(chǎng)景四：JSON傳二進(jìn)制文件。API返回PDF或圖片時(shí)，常見這種結(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ù)至今。

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

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

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

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

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

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

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