欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

C# URL短地址壓縮算法及短網(wǎng)址原理解析

 更新時(shí)間：2015年03月16日 10:48:10   投稿：junjie  
這篇文章主要介紹了C# URL短地址壓縮算法及短網(wǎng)址原理解析,本文重點(diǎn)給出了算法代碼,需要的朋友可以參考下

短網(wǎng)址應(yīng)用已經(jīng)在全國(guó)各大微博上開(kāi)始流行了起來(lái)。例如QQ微博的url.cn，新郎的sinaurl.cn等。

我們?cè)赒Q微博上發(fā)布網(wǎng)址的時(shí)候，微博會(huì)自動(dòng)判別網(wǎng)址，并將其轉(zhuǎn)換，例如：http://url.cn/2hytQx

為什么要這樣做的，原因我想有這樣幾點(diǎn)：

微博限制字?jǐn)?shù)為140字一條，那么如果我們需要發(fā)一些連接上去，但是這個(gè)連接非常的長(zhǎng)，以至于將近要占用我們內(nèi)容的一半篇幅，這肯定是不能被允許的，所以短網(wǎng)址應(yīng)運(yùn)而生了。

短網(wǎng)址可以在我們項(xiàng)目里可以很好的對(duì)開(kāi)放級(jí)URL進(jìn)行管理。有一部分網(wǎng)址可以會(huì)涵蓋暴力，廣告等信息，這樣我們可以通過(guò)用戶的舉報(bào)，完全管理這個(gè)連接將不出現(xiàn)在我們的應(yīng)用中，應(yīng)為同樣的URL通過(guò)加密算法之后，得到的地址是一樣的。

我們可以對(duì)一系列的網(wǎng)址進(jìn)行流量，點(diǎn)擊等統(tǒng)計(jì)，挖掘出大多數(shù)用戶的關(guān)注點(diǎn)，這樣有利于我們對(duì)項(xiàng)目的后續(xù)工作更好的作出決策。

其實(shí)以上三點(diǎn)純屬個(gè)人觀點(diǎn)，因?yàn)樵谖医酉聛?lái)的部分項(xiàng)目中會(huì)應(yīng)用到，所以就了解了一下，下面先來(lái)看看短網(wǎng)址映射算法的理論（網(wǎng)上找到的資料）：

將長(zhǎng)網(wǎng)址md5生成32位簽名串，分為4段，每段8個(gè)字節(jié)；
對(duì)這四段循環(huán)處理，取8個(gè)字節(jié)，將他看成16進(jìn)制串與0x3fffffff(30位1)與操作，即超過(guò)30位的忽略處理；
這30位分成6段，每5位的數(shù)字作為字母表的索引取得特定字符，依次進(jìn)行獲得6位字符串；
總的md5串可以獲得4個(gè)6位串；取里面的任意一個(gè)就可作為這個(gè)長(zhǎng)url的短url地址；
很簡(jiǎn)單的理論，我們并不一定說(shuō)得到的URL是唯一的，但是我們能夠取出4組URL，這樣幾乎不會(huì)出現(xiàn)太大的重復(fù)。

下面來(lái)看看程序部分：

復(fù)制代碼 代碼如下:

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(jiān)” , ”P” , ”Q” , ”R” , ”S” , ”T” ,
        ”U” , ”V” , ”W” , ”X” , ”Y” , ”Z”
    };
    //對(duì)傳入網(wǎng)址進(jìn)行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進(jìn)制與0x3FFFFFFF進(jìn)行位與運(yùn)算
        int  hexint = 0x3FFFFFFF & Convert.ToInt32( ”0x”  + hex.Substring(i * 8, 8), 16);
        string  outChars =  string .Empty;
        for  ( int  j = 0; j < 6; j++)
        {
            //把得到的值與0x0000003D進(jìn)行位與運(yùn)算，取得字符數(shù)組chars索引
            int  index = 0x0000003D & hexint;
            //把取得的字符相加
            outChars += chars[index];
            //每次循環(huán)按位右移5位
            hexint = hexint >> 5;
        }
        //把字符串存入對(duì)應(yīng)索引的輸出數(shù)組
        resUrl[i] = outChars;
    }
    return  resUrl;
}

現(xiàn)在可以直接使用該方法，可以等到下面四組值：

復(fù)制代碼 代碼如下:

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

 
在存放這個(gè)URL的數(shù)據(jù)方面，我個(gè)人推薦TTServer，有的朋友可以沒(méi)有聽(tīng)說(shuō)過(guò)，下面是這個(gè)數(shù)據(jù)庫(kù)的介紹：

Tokyo Cabinet 是日本人 Mikio Hirabayashi（平林幹雄）のページ 開(kāi)發(fā)的一款DBM數(shù)據(jù)庫(kù)(注：大名鼎鼎的DBM數(shù)據(jù)庫(kù)qdbm就是他開(kāi)發(fā)的)，該數(shù)據(jù)庫(kù)讀寫非?？?。insert:0.4sec/1000000 recordes(2500000qps)，寫入100萬(wàn)數(shù)據(jù)只需要0.4秒。search:0.33sec/1000000 recordes (3000000 qps)，讀取100萬(wàn)數(shù)據(jù)只需要0.33秒。

可以看到對(duì)于字典類型的數(shù)據(jù)Key/Value的查詢，這個(gè)數(shù)據(jù)庫(kù)可以說(shuō)是我目前見(jiàn)過(guò)效率非常高的，況且他如此的小巧，用來(lái)對(duì)short url/long url的配對(duì)再好不過(guò)。

該系統(tǒng)使用6個(gè)短碼字符來(lái)表示任何長(zhǎng)度的網(wǎng)址。 有效的字符代碼是ASCII ‘A'到'Z'和'0′的'5′，其中每個(gè)字符包含2 ^ 5（32）狀態(tài)。  6短碼字符可用于繪制32 ^ 6（1073741824）的網(wǎng)址

首先，你需要一個(gè)數(shù)據(jù)庫(kù)表來(lái)存儲(chǔ)和檢索你映射的網(wǎng)址。

復(fù)制代碼 代碼如下:

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

其次，你需要定義一個(gè)算法將長(zhǎng)的URL映射到短的URL。 算法上面已經(jīng)介紹過(guò)了。

第三，你需要?jiǎng)?chuàng)建一個(gè)網(wǎng)頁(yè)，從數(shù)據(jù)庫(kù)的短網(wǎng)址的映射找到原始的URL,并重定向之。

———————————————————

MD5 已經(jīng)被破解了，因此不排除攻擊者偽造相同 MD5 的 url 實(shí)現(xiàn)惡意目的的可能性。如果不考慮這種情況，md5 collision 的可能性應(yīng)該是及其低的，估計(jì)你我有生之年都看不到。

另外偶不明白“相同的URL每次算出來(lái)的鍵值必須都是一樣的”的實(shí)際用途會(huì)是什么。就算相同的 URL 對(duì)應(yīng)不同的鍵值，一般也不會(huì)造成太大的浪費(fèi)吧？只有 6 位的字母數(shù)字組合都可以容納幾十億種變化。

我正是有md5 collision的擔(dān)心才問(wèn)這個(gè)問(wèn)題的。相同的URL要對(duì)應(yīng)相同的鍵值是因?yàn)槊恳粋€(gè)URL地址都需要唯一的對(duì)應(yīng)到數(shù)據(jù)庫(kù)中的一條表數(shù)據(jù)，但直接用URL來(lái)查詢會(huì)比較慢，因?yàn)椋?/p>

將要存儲(chǔ)的URL和相關(guān)的記錄數(shù)據(jù)量非常大。
而且有些URL會(huì)很長(zhǎng)，所以要用text字段。
而如果哈希出唯一的鍵值用varchar來(lái)存儲(chǔ)，再根據(jù)這個(gè)鍵值去查詢就會(huì)非常方便快捷。

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

bit.ly等url shorter服務(wù)是怎么實(shí)現(xiàn)的？
需不需要從hash鍵值反向查找url？ 如果有這樣的要求， url肯定需要存一個(gè)地方， 這樣就可以在沖突的時(shí)候進(jìn)行再散列
MD5是128位hash碼（4個(gè)整數(shù)，每個(gè)整數(shù)4個(gè)字節(jié)）。因此，一個(gè)url的MD5碼，有2的128次方（即2e128）個(gè)可能。隨意找出來(lái)的兩個(gè)url的MD5碼相等的可能性，是2e128分之一，即r=2e-128

假如url經(jīng)MD5后插入數(shù)據(jù)庫(kù)，第一個(gè)url插入的不會(huì)發(fā)生重復(fù)，第二個(gè)MD5插入時(shí)，它跟第一條重復(fù)的概率是r。第三條url插入時(shí)，重復(fù)概率 是2×r，以此類推，第n條插入時(shí)發(fā)生重復(fù)的概率是(n-1)×r。n個(gè)MD5碼，其中有兩個(gè)重復(fù)的概率是這些概率加和。（1＋2＋3＋…+(n- 1))×r = (1/2)×n×(n-1)×r

對(duì)于n個(gè)MD5碼的集合，存在重復(fù)的概率是（1/2)*(n/2e64)e2

因此，只有n大到可以與2e64比擬，才需要考慮它的沖突問(wèn)題。而2的64次方還是很大的。

所以，只要不是惡意攻擊，一般應(yīng)用是不太會(huì)有collision的

相關(guān)文章

最新評(píng)論