引自：http://blog.xiayf.cn/2016/01/24/base64-encoding/ > 1. 在計算機中任何數據都是按ascii碼存儲的，而ascii碼的128～255之間的值是不可見字符。而在網絡上交換數據時，比如說從A地傳到B地，往往要經過多個路由設備，由于不同的設備對字符的處理方式有一些不同，這樣那些不可見字符(例如中文)就有可能被處理錯誤，這是不利于傳輸的。所以就先把數據先做一個Base64編碼，統統變成可見字符，這樣出錯的可能性就大降低了。 > 2. 計算機最終存儲和執行的是01二進制序列，這個二進制序列的含義則由解碼程序/解釋程序決定 > 3. 很多場景下的數據傳輸要求數據只能由簡單通用的字符組成，比如HTTP協議要求請求的首行和請求頭都必須是ASCII編碼 > Base64編碼之所以稱為Base64，是因為其使用64個字符來對任意數據進行編碼，同理有Base32、Base16編碼。標準Base64編碼使用的64個字符為：  > 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值是額外補充的。（6的公倍數） > 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編碼的情況下，將其誤用于數據加密或數據校驗。 > 1. Base64是一種數據編碼方式，目的是讓數據符合傳輸協議的要求。標準Base64編碼解碼無需額外信息即完全可逆，即使你自己自定義字符集設計一種類Base64的編碼方式用于數據加密，在多數場景下也較容易破解。 > 2. 對于數據加密應該使用專門的目前還沒有有效方式快速破解的加密算法。比如：對稱加密算法AES-128-CBC，對稱加密需要密鑰，只要密鑰沒有泄露，通常難以破解；也可以使用非對稱加密算法，如 RSA，利用極大整數因數分解的計算量極大這一特點，使得使用公鑰加密的數據，只有使用私鑰才能快速解密。 > 3. 對于數據校驗，也應該使用專門的消息認證碼生成算法，如 HMAC - 一種使用單向散列函數構造消息認證碼的方法，其過程是不可逆的、唯一確定的，并且使用密鑰來生成認證碼，其目的是防止數據在傳輸過程中被篡改或偽造。將原始數據與認證碼一起傳輸，數據接收端將原始數據使用相同密鑰和相同算法再次生成認證碼，與原有認證碼進行比對，校驗數據的合法性。 那么針對各大網站被脫庫的問題，請問應該怎么存儲用戶的登錄密碼？ 答案是：在注冊時，根據用戶設置的登錄密碼，生成其消息認證碼，然后存儲用戶名和消息認證碼，不存儲原始密碼。每次用戶登錄時，根據登錄密碼，生成消息認證碼，與數據庫中存儲的消息認證碼進行比對，以確認是否為有效用戶，這樣即使網站被脫庫，用戶的原始密碼也不會泄露，不會為用戶使用的其他網站帶來賬號風險。 當然，使用的消息認證碼算法其哈希碰撞的概率應該極低才行，目前一般在HMAC算法中使用SHA256。對于這種方式需要注意一點：防止用戶使用弱密碼，否則也可能會被暴力破解。現在的網站一般要求用戶密碼6個字符以上，并且同時有數字和大小寫字母，甚至要求有特殊字符。 另外，也可以使用加入隨機salt的哈希算法來存儲校驗用戶密碼。這里暫不細述。 總結 Base64兼顧字符集大小和編碼后數據長度，并且可以靈活替換字符集的最后兩個字符，以應對多樣的需求，使其適用場景非常廣泛。 當然，很多場景下有多種編碼方式可選擇，并非Base64編碼不可，視需求，權衡利弊而定。 Comments