c#如何实现url短地址?c#短网址压缩算法与短网址原理入门

发布时间:2019-12-26编辑:脚本学堂
c# url短地址压缩算法与短网址原理的例子,详细介绍了短网址的映射算法,将长网址md5生成32位签名串,分为4段,每段8个字节,然后生成短网址,具体见文本实例。

短网址映射算法
将长网址md5生成32位签名串,分为4段,每段8个字节;
对这四段循环处理,取8个字节,将他看成16进制串与0x3fffffff(30位1)与操作,即超过30位的忽略处理;
这30位分成6段,每5位的数字作为字母表的索引取得特定字符,依次进行获得6位字符串;
总的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.dgjs123.com)[0];  //得到值fAVfui
ShortUrl(http://www.dgjs123.com)[1];  //得到值3ayQry
ShortUrl(http://www.dgjs123.com)[2];  //得到值UZzyUr
ShortUrl(http://www.dgjs123.com)[3];  //得到值36rQZn

在存放这个URL的数据方面,推荐TTServer。

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来查询会比较慢,因为:
将要存储的URL和相关的记录数据量非常大。
而且有些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的。