Base64編碼原理與應用
Base64編碼原理
Base64編碼之所以稱為Base64，是因為其使用64個字符來對任意數據進行編碼，同理有Base32、Base16編碼。標準Base64編碼使用的64個字符為：
這64個字符是各種字符編碼（比如ASCII編碼）所使用字符的子集，基本，並且可打印。唯一有點特殊的是最後兩個字符，因對最後兩個字符的選擇不同，Base64編碼又有很多變種，比如Base64 URL編碼。
Base64編碼本質上是一種將二進制數據轉成文本數據的方案。對於非二進制數據，是先將其轉換成二進制形式，然後每連續6比特（2的6次方=64）計算其十進制值，根據該值在上面的索引表中找到對應的字符，最終得到一個文本字符串。
假設我們要對 Hello! 進行Base64編碼，按照ASCII表，其轉換過程如下圖所示：
這64個字符是各種字符編碼（比如ASCII編碼）所使用字符的子集，基本，並且可打印。唯一有點特殊的是最後兩個字符，因對最後兩個字符的選擇不同，Base64編碼又有很多變種，比如Base64 URL編碼。
Base64編碼本質上是一種將二進制數據轉成文本數據的方案。對於非二進制數據，是先將其轉換成二進制形式，然後每連續6比特（2的6次方=64）計算其十進制值，根據該值在上面的索引表中找到對應的字符，最終得到一個文本字符串。
假設我們要對 Hello! 進行Base64編碼，按照ASCII表，其轉換過程如下圖所示：
可知 Hello! 的Base64編碼結果為 SGVsbG8h ，原始字符串長度為6個字符，編碼後長度為8個字符，每3個原始字符經Base64編碼成4個字符，編碼前後長度比4/3，這個長度比很重要 - 比原始字符串長度短，則需要使用更大的編碼字符集，這並不我們想要的；長度比越大，則需要傳輸越多的字符，傳輸時間越長。Base64應用廣泛的原因是在字符集大小與長度比之間取得一個較好的平衡，適用於各種場景。
是不是覺得Base64編碼原理很簡單？
但這裏需要註意一個點：Base64編碼是每3個原始字符編碼成4個字符，如果原始字符串長度不能被3整除，那怎麽辦？使用0值來補充原始字符串。
以 Hello!!
註：圖表中藍色背景的二進制0值是額外補充的。
Hello!! Base64編碼的結果為 SGVsbG8hIQAA 。最後2個零值只是為了Base64編碼而補充的，在原始字符中並沒有對應的字符，那麽Base64編碼結果中的最後兩個字符 AA 實際不帶有效信息，所以需要特殊處理，以免解碼錯誤。
標準Base64編碼通常用 = 字符來替換最後的 A，即編碼結果為 SGVsbG8hIQ==。因為 = 字符並不在Base64編碼索引表中，其意義在於結束符號，在Base64解碼時遇到 = 時即可知道一個Base64編碼字符串結束。
如果Base64編碼字符串不會相互拼接再傳輸，那麽最後的 = 也可以省略，解碼時如果發現Base64編碼字符串長度不能被4整除，則先補充 = 字符，再解碼即可。
解碼是對編碼的逆向操作，但註意一點：對於最後的兩個 = 字符，轉換成兩個 A 字符，再轉成對應的兩個6比特二進制0值，接著轉成原始字符之前，需要將最後的兩個6比特二進制0值丟棄，因為它們實際上不攜帶有效信息。
為了理解Base64編碼解碼過程，個人實現了一個非常簡陋的Base64編碼解碼程序，見：youngsterxyf/xiaBase64。
由於Base64應用廣泛，所以很多編程語言的標準庫都內置Base64編碼解碼包，如：
- PHP：base64_encode、base64_decode
- Python：base64包
- Go：encoding/base64
- ...
Base64編碼應用
本文開始提到的青雲應用例子只是Base64編碼的應用場景之一。由於Base64編碼在字符集大小與編碼後數據長度之間做了較好的平衡，以及Base64編碼變種形式的多樣，使得Base64編碼的應用場景非常廣泛。下面舉2個常用常見的例子。
HTML內嵌Base64編碼圖片
前端在實現頁面時，對於一些簡單圖片，通常會選擇將圖片內容直接內嵌在頁面中，避免不必要的外部資源加載，增大頁面加載時間，但是圖片數據是二進制數據，該怎麽嵌入呢？絕大多數現代瀏覽器都支持一種名為 Data URLs 的特性，允許使用Base64對圖片或其他文件的二進制數據進行編碼，將其作為文本字符串嵌入網頁中。以百度搜索首頁為例，其中語音搜索的圖標是個背景圖片，其內容以 Data URLs 形式直接寫在css中，這個css內容又直接嵌在HTML頁面中，如下圖所示：
Data URLs 格式為：url(data:文件類型;編碼方式,編碼後的文件內容)。
當然，也可以直接基於image標簽嵌入圖片，如下所示：
<img alt="Embedded Image" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADIA..." />
但請註意：如果圖片較大，圖片的色彩層次比較豐富，則不適合使用這種方式，因為其Base64編碼後的字符串非常大，會明顯增大HTML頁面，影響加載速度。
MIME（多用途互聯網郵件擴展）
我們的電子郵件系統，一般是使用SMTP（簡單郵件傳輸協議）將郵件從客戶端發往服務器端，郵件客戶端使用POP3（郵局協議，第3版本）或IMAP（交互郵件訪問協議）從服務器端獲取郵件。
SMTP協議一開始是基於純ASCII文本的，對於二進制文件（比如郵件附件中的圖像、聲音等）的處理並不好，所以後來新增MIME標準來編碼二進制文件，使其能夠通過SMTP協議傳輸。
舉例來說，我給自己發封郵件，正文為空，帶一個名為hello.txt的附件，內容為 您好！世界！。導出郵件源碼，其關鍵部分如下圖所示：
MIME-Version: 1.0：表示當前使用MIME標準1.0版本。
Content-Type: text/plain; name="hello.txt"：表示附件文件名為 hello.txt ，格式為純文本。
Content-Transfer-Encoding: base64：表示附件文件內容使用base64編碼後傳輸。
5oKo5aW977yM5LiW55WM77yB：則是文件內容 您好，世界！ Base64編碼後的結果。
不過，MIME使用的不是標準Base64編碼。
切忌誤用
可能會有人在不理解Base64編碼的情況下，將其誤用於數據加密或數據校驗。
Base64是一種數據編碼方式，目的是讓數據符合傳輸協議的要求。標準Base64編碼解碼無需額外信息即完全可逆，即使你自己自定義字符集設計一種類Base64的編碼方式用於數據加密，在多數場景下也較容易破解。
對於數據加密應該使用專門的目前還沒有有效方式快速破解的加密算法。比如：對稱加密算法AES-128-CBC，對稱加密需要密鑰，只要密鑰沒有泄露，通常難以破解；也可以使用非對稱加密算法，如 RSA，利用極大整數因數分解的計算量極大這一特點，使得使用公鑰加密的數據，只有使用私鑰才能快速解密。
對於數據校驗，也應該使用專門的消息認證碼生成算法，如 HMAC - 一種使用單向散列函數構造消息認證碼的方法，其過程是不可逆的、唯一確定的，並且使用密鑰來生成認證碼，其目的是防止數據在傳輸過程中被篡改或偽造。將原始數據與認證碼一起傳輸，數據接收端將原始數據使用相同密鑰和相同算法再次生成認證碼，與原有認證碼進行比對，校驗數據的合法性。
那麽針對各大網站被脫庫的問題，請問應該怎麽存儲用戶的登錄密碼？
答案是：在註冊時，根據用戶設置的登錄密碼，生成其消息認證碼，然後存儲用戶名和消息認證碼，不存儲原始密碼。每次用戶登錄時，根據登錄密碼，生成消息認證碼，與數據庫中存儲的消息認證碼進行比對，以確認是否為有效用戶，這樣即使網站被脫庫，用戶的原始密碼也不會泄露，不會為用戶使用的其他網站帶來賬號風險。
當然，使用的消息認證碼算法其哈希碰撞的概率應該極低才行，目前一般在HMAC算法中使用SHA256。對於這種方式需要註意一點：防止用戶使用弱密碼，否則也可能會被暴力破解。現在的網站一般要求用戶密碼6個字符以上，並且同時有數字和大小寫字母，甚至要求有特殊字符。
另外，也可以使用加入隨機salt的哈希算法來存儲校驗用戶密碼。這裏暫不細述。
總結
Base64兼顧字符集大小和編碼後數據長度，並且可以靈活替換字符集的最後兩個字符，以應對多樣的需求，使其適用場景非常廣泛。
當然，很多場景下有多種編碼方式可選擇，並非Base64編碼不可，視需求，權衡利弊而定。
來源：http://blog.xiayf.cn/2016/01/24/base64-encoding/
Base64編碼原理與應用