Android開發(fā)資料

昵稱Q99IG 2016-07-24

展開全文

      有些場合下，例如在要實現(xiàn)自動登錄時本地存儲用戶的賬號和密碼，不能用明碼來標識。這時候就首先需要對這些關鍵信息進行加密。對信息進行加密有許多種,下面將詳細介紹BASE 64編碼的實現(xiàn)，以及自定義BASE 64編碼表以提升解密難度。

      BASE 64編碼要求把3個8位字節(jié)（3*8=24）轉化為4個6位的字節(jié)（4*6=24），之后在6位的前面補兩個0，形成8位一個字節(jié)的形式。在標準BASE 64編碼表中，最后轉化的4個6位字節(jié)都可以用ASCII明碼顯示出來。以字符串“張3”為例：

      字符串：張3
      原byte數組：11010101 11000101 00110011
      編碼后的byte數組：00110101 00011100 00010100 00110011
      對應十進制數值：53 34 20 51
      標準編碼表對應字符：1 i U z

      可以這么考慮：把字符串的原始字節(jié)數組連成一串，然后順序依次選6個出來，之后再把這6二進制數前面再添加兩個0，就成了一個新的字節(jié)。之后再選出6個來，再添加0，依此類推，直到24個二進制數全部被選完，就得到了編碼后的字節(jié)數組。

      標準的BASE 64為了讓轉碼后所有的字符都可見，設計了如下標準編碼表：

QQ截圖20120803165358.png

2012-8-3 16:54:14 上傳

      依據此表中十進制數值與字符的映射關系，最后得到標準編碼表對應字符序列，即字符串最終編碼為“1iUz”。

      由此可見，Base64將3個字節(jié)轉變?yōu)?個字節(jié)，因此，編碼后的代碼量（以字節(jié)為單位，下同）約比編碼前的代碼量多了1/3。之所以說是“約”，是因為如果代碼量正好是3的整數倍，那么自然是多了1/3。

      但如果不是呢？請注意在編碼表中的最后一個有一個(pad) =字符。這個字符的目的就是用來處理這個問題的。

      當代碼量不是3的整數倍時，代碼量/3的余數自然就是2或者1。轉換的時候，結果不夠6位的用0來補上相應的位置，之后再在6位的前面補兩個0。轉換完空出的結果就用就用“=”來補位。譬如結果若最后余下的為2個字節(jié)的“張”：

      字符串：張
      原byte數組：11010101 11000101
      編碼后的byte數組：00110101 00011100 00010100
      對應十進制數值：53 34 20 pad
      標準編碼表對應字符： 1 i U =

      這樣，最后的2個字節(jié)被整理成了“1iU=”。

      同理，若原代碼只剩下一個字節(jié)，那么將會添加兩個“=”。只有這兩種情況，所以，Base64的編碼最多會在編碼結尾有兩個“=”。

      有人說BASE 64嚴格來講只能算是編碼算法，而不是加密算法。究其原因，是因為大部分BASE 64的應用使用的都是公開的標準編碼表，使得密文可以輕易地被解密。但如果該編碼表是開發(fā)者自定義的，即密鑰是開發(fā)者私有不共享的，則稱BASE 64為加密算法就名正言順了。

      在程序實現(xiàn)上，大概可以分為如下幾步：

      1.實現(xiàn)自定義編碼表。
      2.根據編碼表計算出解碼表。代碼如下：

view source

print ?

`1`	`static` `{`

`2`	`decodingTable =` `new` `byte[128];`

`3`	`for` `(int` `i =` `0; i < encodingtable.length;="" i++)="">`

`4`	`decodingTable[encodingTable] = (byte) i;`

5 }

6 }

      3.依據編碼表對明文進行加密，具體過程為：

      讀取明文3字節(jié)數據用&操作取前6位，放入新的變量中右移兩位，高兩位清0后與編碼表中相應值進行&操作；取第一個字節(jié)的后2位和第二個字節(jié)的前4位移位放入新變量中右移兩位，清0……依此類推。

      解碼為編碼的逆過程。具體代碼實現(xiàn)請參考本章Demo中的示例代碼。

      Demo運行效果如下：

QQ截圖20120803141248.png