今天我有个朋友问我关于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去执行的结果，跟他们俩比较，不一定会准确。
扫一扫
7341
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
