這么說吧：在對計算機底層有一定了解的人眼里，計算機內(nèi)部其實分表里兩層世界。

“里世界”是更本質(zhì)的，也是CPU以及偏中底層的各種編程語言直接打交道的那個世界。

正因其本質(zhì)，因此絕大多數(shù)的編程語言、大多數(shù)的通訊協(xié)議，全程運行于里世界；只有需要向用戶展示什么時，才會臨時做個轉(zhuǎn)換——這就是為什么如果你學(xué)C，可能很久很久都沉浸在黑框框里出不來的原因：表世界太表面了，不值得花太多精力在它上面。

在“里世界”，一切數(shù)據(jù)都是一串串的二進制字節(jié)流。比如你敲個大寫字母'A'，它在里世界其實是數(shù)字65；敲個小寫字母'a'，里世界對應(yīng)的數(shù)字是97……

這個對應(yīng)關(guān)系是ASCII碼表規(guī)定的：

事實上，里世界也沒有什么65、97之類，它只有二進制。你敲6，它在里世界其實是十進制數(shù)字54或者十六進制數(shù)字0x36對應(yīng)的那個二進制數(shù)字。

甚至，你敲11001011，這下總是二進制了吧？

并不是。'1'在里世界是49，'0'在里世界是48。所以你敲的其實是4949484849484949！

哦，里世界，一組數(shù)字的最小單位是字節(jié)。所以49其實在里世界的表示是"00110001"——在電路上，就是一組8根導(dǎo)線，電壓分別是“低低高高低低低高”。

總之，里世界只有高高低低的電壓；我們把一組八個電壓稱為一個字節(jié)；它的內(nèi)容究竟是什么，需要通過ASCII碼表轉(zhuǎn)換，然后才能正確解釋。

實際上，我們的轉(zhuǎn)換表有無數(shù)種。只有通過ASCII編碼輸入的數(shù)據(jù)，才可以通過ASCII表轉(zhuǎn)換回表世界表示。

比如說，我們熟悉的、C/C++以及Java等諸多語言，它們都有個對初學(xué)者來說非?！翱膳隆钡臇|西，就是變量類型——使用一個變量之前，你需要先聲明它的類型；后續(xù)引用這個變量時，你還得保證它和初始聲明的變量類型一致。

這個變量類型，實質(zhì)上就是“轉(zhuǎn)換表類型”。

比如，我聲明變量A是short int，意思是我在表世界寫出來的雖然是一串ASCII碼表示的數(shù)字，但實際存儲到里世界時，我希望把它當(dāng)成二進制數(shù)字解釋，存到兩個字節(jié)（16位二進制）里面！

同樣的，聲明變量B是string，意思是把我寫的一串字母按ASCII碼規(guī)則翻譯，每個字母翻譯到一個字節(jié)的ASCII碼機內(nèi)二進制表示上去。

更可怕的，C/C++允許你以一種類型聲明變量A，然后，卻通過“強制類型轉(zhuǎn)換”，把它按另一種變量類型解釋——這就繞的有些遠(yuǎn)了，不再深入。

總之，通過“變量類型聲明”，我就為自己在“表世界”敲入的一串字符指定了一個“里世界”存儲、運算規(guī)則，從而確保計算機按我的意圖處理信息。

較新的很多腳本語言可以自動分析程序員在表世界敲入的東西“更可能是什么”，從而為它自動選擇一個合適的表示——如果這個分析不正確，那么接下來的某個運算規(guī)則可能就無法成立；此時又要自動轉(zhuǎn)換內(nèi)部表示，使得規(guī)則成立。

舉例來說，我在python里面聲明了一個變量x，指定初始值為“13512342234”；解釋器很聰明，覺得這應(yīng)該是一個數(shù)字，于是自動替我轉(zhuǎn)換成二進制表示，存儲到8個字節(jié)里面。

沒想到我其實是存了一串電話號碼。所以后面我就做了個字符串加法：

“我是流落在外的尼日利亞王子，如果你能給我100塊錢，讓我買張車票回家，繼承王位后必有厚報。有意者請撥打電話：”+ x

字符串參與的+實際上是字符串拼接；結(jié)果x存成二進制數(shù)字了，沒法拼接。所以python手忙腳亂的又把8個字節(jié)的二進制數(shù)字轉(zhuǎn)換回來，轉(zhuǎn)成了11個字節(jié)的ASCII字符串“13512342234”，然后才能正確拼接。

類似的，一副圖片，也可以按像素的順序，在里世界以每個像素RGB三個字節(jié)的格式存儲。這就是BMP圖像——再給它加個文件頭，知道一行多少個像素，就可以在“里世界表示”和“表世界表示”之間來回轉(zhuǎn)換了。

同樣的，一首歌曲，采樣率48KHZ，雙聲道，也可以按采樣順序把每次采樣的電壓值兩個兩個字節(jié)的順序存儲在里世界。將來重放時，把這個數(shù)字序列按采樣間隔送到DAC轉(zhuǎn)換回模擬波形、再驅(qū)動音箱/耳機發(fā)聲，你在表世界就聽到優(yōu)美的旋律了。

總之，你在“表世界”看到的、聽到的一切一切，在里世界都是一串?dāng)?shù)字。

為了讓你在不知道“里世界”存在的前提下，仍然能操控電腦、工作學(xué)習(xí)和娛樂，程序需要時刻準(zhǔn)備著，幫你把里世界的數(shù)字表示轉(zhuǎn)換成表世界的文本、圖片、音樂，甚至3D打印機噴頭的移動、車床夾具/刀具的精確定位……

有了這個基礎(chǔ)，我們終于可以談?wù)刡ase64了。

談base64之前，我們得先談?wù)凥TTP。

在程序員眼中，HTTP是一個“奇葩”。

它在本質(zhì)上，其實是一個“完全用表世界表示”傳輸各種信息的協(xié)議，也就是所謂的“文本協(xié)議”；但與之同時，它的功能越發(fā)強大、涉及領(lǐng)域越來越廣，也就越來越需要“沉”進里世界才能完成任務(wù)——但它偏偏是一個完全的表世界協(xié)議。

比如，如前所述，對計算機來說，文本數(shù)字需要先轉(zhuǎn)換“里世界表示”才能解讀其意義——123456只是ASCII碼49 50 51 52 53 54而已，要正確讀出它的含義“十二萬三千四百五十六”，就要先把49轉(zhuǎn)換成里世界的1，然后1X10，加上50對應(yīng)的里世界2，整體再乘以10……

也就是：1X10^5+2X10^4+3X10^3+4X10^2+5X10+6

通過這么一串復(fù)雜的轉(zhuǎn)換和計算，ASCII字符串123456的含義才能正確解讀。

更可怕的，比如圖片、音樂等信息，它們本應(yīng)是里世界的一大堆數(shù)字；現(xiàn)在卻不得不表示成表世界的ASCII文本——然后，文本再翻譯回里世界的數(shù)字表示，這才能正確解釋其含義；最后，再把里世界的二進制表示轉(zhuǎn)換成表世界的圖片、音樂……

換句話說，HTTP是一個完全在表世界運行的文本協(xié)議；但它卻又無時無刻不在和里世界打交道！

這就帶來了海量的反復(fù)轉(zhuǎn)換，效率很低。

這沒辦法改變，為了方便人閱讀排錯嘛，自然不可能不付出代價。

但是，把圖片、音樂等信息轉(zhuǎn)換成十進制、十六進制，這實在是太蠢了。

這是因為，每位十進制/十六進制數(shù)字，編碼成ASCII碼后都要占據(jù)8個二進制位；而8個二進制位要編碼成十進制/十六進制數(shù)字呢，起碼要三個十進制數(shù)字或者兩個十六進制數(shù)字！

換句話說，數(shù)據(jù)量膨脹了兩三倍！

如果說“在表世界表示和里世界表示之間反復(fù)轉(zhuǎn)換”只是累了用戶的電腦/手機，沒什么大不了的——反正它們性能膨脹，閑著也是閑著——那么，一幅圖片通過HTTP協(xié)議傳輸，10M的數(shù)據(jù)成了30M、10G的數(shù)據(jù)成了30G……這就不好玩了：無論是網(wǎng)站運營商的服務(wù)器還是死貴死貴的商業(yè)線路，這都是個太大的壓力。

此外，很多數(shù)據(jù)，不僅僅是圖片、視頻和音樂，它們同樣是二進制的，不能直接當(dāng)文本數(shù)據(jù)傳輸——否則會被當(dāng)做ASCII碼控制字符解釋的，一不小心就把http協(xié)議本身干擾了。

比如，http用“回車”來分割不同字段（于是一行就是一個數(shù)據(jù)）；而如果你的AutoCAD文檔里面恰好有個13，這個13就會被解釋為“回車”——于是，瀏覽器覺得，AutoCADFile: XXXX\n CADFileContent: XXXXXXX 這幾個字段的設(shè)置已經(jīng)結(jié)束了，剩下是另一回事……哎呀，格式怎么亂成這樣了？

總之，為了避免干擾http協(xié)議、同時盡可能提高“里世界表示”到“表世界表示”的編碼效率，我們需要設(shè)計一套新的編碼方案。這就是base64編碼。

base64編碼不使用ASCII控制字符以及經(jīng)常在http/html協(xié)議里使用的<、>等字符，這就避免了干擾各種文本協(xié)議；同時，它的每位符號盡可能的多，顧名思義，base64嘛，以64個可打印字符弄出的64進制字符串，于是每個ASCII碼字符攜帶的信息量就盡可能的增加了，編碼后的數(shù)據(jù)量膨脹就不會太過可怕了。

當(dāng)然，諸如URL、正則表達式等東西還是可能和通用的base64編碼沖突；base64_百度百科 (baidu.com)

總之，經(jīng)過種種努力，在“表世界文本”中攜帶“里世界數(shù)據(jù)”終于不再成為難題。

事實上，有些數(shù)據(jù)，比如URL，它雖然不是“里世界數(shù)據(jù)”；但因為格式太過隨意，也可能破壞頁面內(nèi)容。怎么辦呢？簡單，也用base64把它“裝箱”，就不怕它像里世界數(shù)據(jù)那樣污染表世界了。

反正瀏覽器能自動識別URL中的base64編碼，可以自動把它從base64箱子里取出來，不耽誤使用。

但是，請注意，base64和加密無關(guān)。它僅僅是“以表世界文本表示里世界數(shù)據(jù)”的一套編碼協(xié)議而已；雖然編碼后的東西你看不懂，但本質(zhì)上仍然是明文，任何人都可以通過一個逆變換輕易還原它。