引出

眾所周知, ASICC編碼共127個, 使用了7個bit進行編碼. 而檔案在儲存的時候是以 位元組為單位, 也就是8bit. 這就難免導致有一部分編碼是沒有定義在ASICC編碼中的.

而在網路中傳輸二進位制資料的時候(字串本質上也是二進位制資料嘛), 如果直接傳輸位元流, 倒也不是不可以, 只是肉眼難以識別造成不便. 比如你在除錯HTTP介面的時候, 對面傳輸的是一段字串, 你抓包看到的都是一堆方塊, 什麼心情. 而且一些特殊的編碼會影響對資料的解析, 造成解析錯誤.

而ASICC編碼是最通用的, 故而需要有一種機制, 能夠將二進位制資料轉換為可見的ASICC編碼字串進行傳輸, 等到需要的時候, 再通過解碼原封不動的轉回去. 而這, 就是base64

實施

如何做到將二進位制資料轉換為可見的ASICC編碼字串呢?

選出可見字元

首先, 要先選出使用的可見ASICC編碼, 從base64的名字也能看的出來, 一共選了64個, 分別是:
a-z A-Z 0-9 + /

好, 現在已經將使用的64個可見字元選出來了, 可以進行編碼轉換了.

64個字元一一對映後可編碼6bit, 其編碼對映表如下:

也就是說, 原內容的6bit, 編碼後為8bit. 沒錯, 會增加內容的大小.

編碼步驟

我們嘗試著對字串hjn進行編碼.

通過查詢ASICC 編碼表將其轉為二進位制:

01101000 01101010 01101110 共3個位元組.

然後將其拆分為每6bit 一組:

011010 000110 101001 101110

將上方的6bit 二進位制按照對映表進行轉換, 結果為: aGpu. 使用PHP進行驗證後, 結果與我們計算的一致.

<?php
// aGpu
echo base64_encode('hjn'), PHP_EOL;

補全碼

我們再嘗試對hj進行編碼. 其二進位制內容為: 01101000 01101010

按照6bit 分組後發現最後一組不足6bit, 就在後面補0: 011010 000110 101000

對映後, 其結果為: aGo. 但是, base64規定其必須是4位元組一組, 當不足4位元組時向後面新增補全碼進行對其. 這個補全碼就是=

因此, hj的base64編碼為aGo=. 同理, 若僅對h

那麼, 當對aGo=解碼的時候, 將後面的補全碼=去掉, 解碼後為: 011010 000110 101000. 如何能夠確定後面的兩個00需要去掉呢? 很簡單, 儲存的時候以位元組為單位, 當末尾剩餘00不足1位元組時, 說明是編碼時額外加上的, 可以去掉.

應用場景

齊了, base64編碼就這麼點東西. 它可以應用到下列場景(暫時想到):

• 網頁顯示圖片, 使用base64編碼圖片
• 資料中存在特殊符號, 影響解析, 使用base64將其編碼為普通符號
  • xml 中的 value 存在 </xml>結束符號, 影響內容解析
  • 傳輸過程中, 字串中存在\n換行符, 影響單行內容傳輸
  • 等等
• 等等吧

對了, 上面介紹了base64編碼. 相對應的base32 base16編碼原理均相同, 只是編碼時使用的位數不同而已.

原文地址: https://hujingnb.com/archives/760