转载 URL短地址压缩算法 微博短地址原理解析

短网址应用已经在全国各大微博上开始流行了起来。例如QQ微博的url.cn，新郎的sinaurl.cn等。

我们在QQ微博上发布网址的时候，微博会自动判别网址，并将其转换，例如：http://url.cn/2hytQx

为什么要这样做的，原因我想有这样几点：

1. 微博限制字数为140字一条，那么如果我们需要发一些连接上去，但是这个连接非常的长，以至于将近要占用我们内容的一半篇幅，这肯定是不能被允许的，所以短网址应运而生了。
2. 短网址可以在我们项目里可以很好的对开放级URL进行管理。有一部分网址可以会涵盖暴力，广告等信息，这样我们可以通过用户的举报，完全管理这个连接将不出现在我们的应用中，应为同样的URL通过加密算法之后，得到的地址是一样的。
3. 我们可以对一系列的网址进行流量，点击等统计，挖掘出大多数用户的关注点，这样有利于我们对项目的后续工作更好的作出决策。

其实以上三点纯属个人观点，因为在我接下来的部分项目中会应用到，所以就了解了一下，下面先来看看短网址映射算法的理论（网上找到的资料）：

1. 将长网址md5生成32位签名串，分为4段，每段8个字节；
2. 对这四段循环处理，取8个字节，将他看成16进制串与0x3fffffff(30位1)与操作，即超过30位的忽略处理；
3. 这30位分成6段，每5位的数字作为字母表的索引取得特定字符，依次进行获得6位字符串；
4. 总的md5串可以获得4个6位串；取里面的任意一个就可作为这个长url的短url地址；

很简单的理论，我们并不一定说得到的URL是唯一的，但是我们能够取出4组URL，这样几乎不会出现太大的重复。

下面来看看程序部分：

public   static   string [] ShortUrl( string  url)  
{  
    //可以自定义生成MD5加密字符传前的混合KEY   
    string  key =  "Leejor" ;  
    //要使用生成URL的字符   
    string [] chars =  new   string []{  
        "a" , "b" , "c" , "d" , "e" , "f" , "g" , "h" ,  
        "i" , "j" , "k" , "l" , "m" , "n" , "o" , "p" ,  
        "q" , "r" , "s" , "t" , "u" , "v" , "w" , "x" ,  
        "y" , "z" , "0" , "1" , "2" , "3" , "4" , "5" ,  
        "6" , "7" , "8" , "9" , "A" , "B" , "C" , "D" ,  
        "E" , "F" , "G" , "H" , "I" , "J" , "K" , "L" ,  
        "M" , "N" , "O" , "P" , "Q" , "R" , "S" , "T" ,  
        "U" , "V" , "W" , "X" , "Y" , "Z"   
    };  
   
    //对传入网址进行MD5加密   
    string  hex = System.Web.Security.FormsAuthentication.HashPasswordForStoringInConfigFile(key + url,  "md5" );  
  
    string [] resUrl =  new   string [4];  
  
    for  ( int  i = 0; i < 4; i++)  
    {  
        //把加密字符按照8位一组16进制与0x3FFFFFFF进行位与运算   
        int  hexint = 0x3FFFFFFF & Convert.ToInt32( "0x"  + hex.Substring(i * 8, 8), 16);  
        string  outChars =  string .Empty;  
        for  ( int  j = 0; j < 6; j++)  
        {  
            //把得到的值与0x0000003D进行位与运算，取得字符数组chars索引   
            int  index = 0x0000003D & hexint;  
            //把取得的字符相加   
            outChars += chars[index];  
            //每次循环按位右移5位   
            hexint = hexint >> 5;  
        }  
        //把字符串存入对应索引的输出数组   
        resUrl[i] = outChars;  
    }  
    return  resUrl;  
}  

 现在可以直接使用该方法，可以等到下面四组值：

 

ShortUrl(http://www.me3.cn)[0];  //得到值fAVfui  
ShortUrl(http://www.me3.cn)[1];  //得到值3ayQry  
ShortUrl(http://www.me3.cn)[2];  //得到值UZzyUr  
ShortUrl(http://www.me3.cn)[3];  //得到值36rQZn

 

在存放这个URL的数据方面，我个人推荐TTServer，有的朋友可以没有听说过，下面是这个数据库的介绍：

Tokyo Cabinet 是日本人 Mikio Hirabayashi（平林幹雄）のページ 开发的一款DBM数据库(注：大名鼎鼎的DBM数据库qdbm就是他开发的)，该数据库读写非常快。insert:0.4sec/1000000 recordes(2500000qps)，写入100万数据只需要0.4秒。search:0.33sec/1000000 recordes (3000000 qps)，读取100万数据只需要0.33秒。

可以看到对于字典类型的数据Key/Value的查询，这个数据库可以说是我目前见过效率非常高的，况且他如此的小巧，用来对short url/long url的配对再好不过。

该系统使用6个短码字符来表示任何长度的网址。 有效的字符代码是ASCII 'A'到'Z'和'0'的'5'，其中每个字符包含2 ^ 5（32）状态。  6短码字符可用于绘制32 ^ 6（1073741824）的网址 

首先，你需要一个数据库表来存储和检索你映射的网址。 

CREATE TABLE mappedURL (的CREATE TABLE mappedURL（   
shortCode char (6) not  null ,   
lognURL  text not null ,   
PRIMARY KEY  shortCodeInd (shortCode),   
);   

 其次，你需要定义一个算法将长的URL映射到短的URL。 算法上面已经介绍过了。
第三，你需要创建一个网页，从数据库的短网址的映射找到原始的URL,并重定向之。

---------------------------------------------------------

MD5 已经被破解了，因此不排除攻击者伪造相同 MD5 的 url 实现恶意目的的可能性。如果不考虑这种情况，md5 collision 的可能性应该是及其低的，估计你我有生之年都看不到。

另外偶不明白“相同的URL每次算出来的键值必须都是一样的”的实际用途会是什么。就算相同的 URL 对应不同的键值，一般也不会造成太大的浪费吧？只有 6 位的字母数字组合都可以容纳几十亿种变化。

我正是有md5 collision的担心才问这个问题的。相同的URL要对应相同的键值是因为每一个URL地址都需要唯一的对应到数据库中的一条表数据，但直接用URL来查询会比较慢，因为：

1. 将要存储的URL和相关的记录数据量非常大。
2. 而且有些URL会很长，所以要用text字段。

而如果哈希出唯一的键值用varchar来存储，再根据这个键值去查询就会非常方便快捷。

就像git里面的object hash， 目前基本上不用考虑冲突吧。

• bit.ly等url shorter服务是怎么实现的？
• 需不需要从hash键值反向查找url？ 如果有这样的要求， url肯定需要存一个地方， 这样就可以在冲突的时候进行再散列

MD5是128位hash码（4个整数，每个整数4个字节）。因此，一个url的MD5码，有2的128次方（即2e128）个可能。随意找出来的两个url的MD5码相等的可能性，是2e128分之一，即r=2e-128

假如url经MD5后插入数据库，第一个url插入的不会发生重复，第二个MD5插入时，它跟第一条重复的概率是r。第三条url插入时，重复概率 是2×r，以此类推，第n条插入时发生重复的概率是(n-1)×r。n个MD5码，其中有两个重复的概率是这些概率加和。（1＋2＋3＋...+(n- 1))×r = (1/2)×n×(n-1)×r

对于n个MD5码的集合，存在重复的概率是（1/2)*(n/2e64)e2

因此，只有n大到可以与2e64比拟，才需要考虑它的冲突问题。而2的64次方还是很大的。

所以，只要不是恶意攻击，一般应用是不太会有collision的