今天我有個朋友問我關於url加密的問題，這個問題之前就研究過，通俗的說法url加密就是按照一種編碼規則把url中的某些字符串替換成其他的不規則的字符串。
後來我就上網找url加密相關的資料，結果發現2篇帖子，在此貼出來跟大家共享：
例子1：http://www.iteye.com/topic/286240 作者：gembler
例子2：http://www.iteye.com/topic/286810 作者：gembler
--------------------------------------------------------------------------例子1 分割線--------------------------------------------------------------------------
在淘寶網上用關鍵字“gembler”搜索一下商品，得出以下URL：
- http://search1.taobao.com/browse/0/n-0-----------------g,m5sw2ytmmvza----------------40--commend-0-all-0.htm?at_topsearch=1
（留意上面這裏：“m5sw2ytmmvza”）
經過一輪 天昏地暗、沙塵滾滾 的分析、研究之後，得出以下結論：
在Base64中，碼錶是由 [A-Z,a-z,0-9,+,/,=(pad)] 組成的。
然後自己也弄個碼錶，由 [a-z,2-7（這個2-7是在淘寶網上搜索了n次而得出的結論）] 組成的：
| a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p | q | r |
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 |
-------------------------------------------------------愚蠢分割線---------------------------------------------
| s | t | u | v | w | x | y | z | 2 | 3 | 4 | 5 | 6 | 7 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
在Base64中，是將二進制連成一串，然後再按6位來分割，分割完後在前面補0，這個地球人都知道，不多說了。
而我呢，哈哈，搗蛋一下，按5位來分割，如果剛好夠分，那就爽了，
但是，世事往往不如人意，位數不夠，那咋辦呢？看下面 ：）
在Base64中，是用"="來解決的吧。
現在呢，就是在前面補0，然後在後面再補0，其實就是前後補0，
但是，按5位來分割，前面3個0是補定的了，後面的0就看上帝怎麼安排了。
舉個小例子：字符串 "aaa"，(編碼/加密)後是 "mfqwc"
| 二進制： | 01100001 | 01100001 | 01100001 | ||
| 轉換後： | (000)01100 | (000)00101 | (000)10000 | (000)10110 | (000)0001(0) |
| 十進制： | 12 | 5 | 16 | 22 | 2 |
| 碼錶對應： | m | f | q | w | c |
反過來，(解碼/解密)：
| 碼錶對應： | m | f | q | w | c |
| 十進制： | 12 | 5 | 16 | 22 | 2 |
| 二進制： | 00001100 | 00000101 | 00010000 | 00010110 | 00000010 |
| 去掉前3個0後： | 01100 | 00101 | 10000 | 10110 | 00010 |
| 合併後： | 0110000101100001011000010 | ||||
然後把合併後的串的長度除一下8，發現多了個0：
| 合併後的二進制碼： | 01100001 | 01100001 | 01100001 | 0 |
多了就算了，不要了（其實是在{編碼/加密}的分割時候，在分剩的餘數的後面補的0）。
然後再將 byte[] 轉回字符串
OK！又見回"aaa"了。 ：）
*有一點值得注意的是：UTF-8、GBK、GB18030 一般都沒什麼問題，但是 GB2312 可能字符集不夠豐富，繁體字在decode的時候成問號了。
搞了半天，“可視化編輯器”的 Java Code不好使，骨幹代碼在回帖裏貼出................（完整的代碼，有興趣的同志們請見附件！）
-------------------------------------------------------------------例子2 分割線------------------------------------------------------------------------------
繼“淘寶網的搜索關鍵字的編碼與解碼”之後，忽然間，腦袋一閃：“好像拍拍網對於搜索關鍵字的編碼與解碼的規則都是差不多的”。
然後馬上跑去拍拍網，敲入：“gembler”，得出如下URL：
- http://sse.paipai.com/s-p7vz42wppy3a--1-40-13---3-4-3----2-2--128-0.html
（看上面的：p7vz42wppy3a）
是不是與淘寶網的長的差不多阿？答案是：“確實長的很像”。
既然長得像，那麼遊戲規則應該也是大同小異。。。
分析、研究，有結論了：
其實，就只有碼錶不一樣，其他的，全都跟“淘寶網的搜索關鍵字的編碼與解碼”一樣，OK！我們來看看碼錶的變化。
在上文中用的碼錶是由： [a-z , 2-7] 組成的。
而現在，是由： [a-c , g-z , 1-9] 組成的。
oh! gee ··· 就多了 [1 , 8 , 9 ] ，然後幹掉了 [ d-f ]。
上文的碼錶：
- private final static String CODEC_TABLE = "abcdefghijklmnopqrstuvwxyz234567";
| a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p | q | r |
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 |
-------------------------------愚蠢分割線---------------------------------
| s | t | u | v | w | x | y | z | 2 | 3 | 4 | 5 | 6 | 7 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
現在的碼錶：
- private final static String CODEC_TABLE = "abcghijklmnopqrstuvwxyz123456789";
| a |
b |
c |
g |
h |
i |
j |
k |
l |
m |
n |
o |
p |
q |
r |
s |
t |
u |
| 0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
-------------------------------愚蠢分割線---------------------------------
| v |
w |
x |
y |
z |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
| 18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
31 |
OK！測試一下，這裏使用上文提供的 Source Code 中的 main(String[] args) 來測試：
測試結果：
輸入：JavaEye論壇頻道
輸出：
original: JavaEye論壇頻道
encode: mmt1p2nisiv6iz8pzsgooqra
decode: JavaEye論壇頻道
然後跑去拍拍網敲入"JavaEye論壇頻道"搜索。
得出：
http://sse.paipai.com/s-mmt1p2nisiv6iz8pzsgooqra--1-40-13---3-4-3----2-2--128-0.html
比較一下：
mmt1p2nisiv6iz8pzsgooqra - console輸出
mmt1p2nisiv6iz8pzsgooqra - 拍拍網URL
說明兩點：
1.其實這種規則只是在Base64上進行改造，不是原始的Base64。
2.可能這兩個貼子出了以後，淘寶網和拍拍網的那個規則可能會有所變動，
所以以後拿着我上文提供的Source Code去執行的結果，跟他們倆比較，不一定會準確。