短url演算法
這個不是md5加密 應該是自定義的一種加密方式
url用加密 主要是防止在傳參的時候遇到中文 而出現亂碼問題
url傳參一般都是自定義的加密演算法 因為這種加密可以破解 這樣就知道
url所傳的參數是什麼 如果用md5的話 估計很難破解 基本上不可行
① 將長網址用md5演算法生成32位簽名串，分為4段,，每段8個字元；
② 對這4段循環處理，取每段的8個字元, 將他看成16進制字元串與0x3fffffff(30位1)的位與操作，超過30位的忽略處理；
③ 將每段得到的這30位又分成6段，每5位的數字作為字母表的索引取得特定字元，依次進行獲得6位字元串；
④ 這樣一個md5字元串可以獲得4個6位串，取裡面的任意一個就可作為這個長url的短url地址。
很簡單的理論，我們並不一定說得到的URL是唯一的，但是我們能夠取出4組URL，這樣幾乎不會出現太大的重復。
⑶ 怎麼做一個短網址縮短網站，網址縮短後要以自己的頂級域名顯示的，不是顯示現在網上流行的url、t等。
現在網址縮短網站有很多了，就分析一下做得比較好的六度短網址6.in短網址生成服務平台：
（1）將長網址md5生成32位簽名串，分為4段，每段4個位元組
對這4段循環處理，取4個位元組（32位），將它看成16進制串與0x3fffffff（30位1）（2）與操作，即超過30位的忽略處理
（3）這30位分成6段，每5位的數字作為字母表的索引取得特定字元，依次進行獲得6位字元串
（4）總的md5串可以獲得4個6位串，取裡面的任意一個就可作為這個長url地址
（5）把數字和字元組合做一定的映射，就可以產生唯一的字元串，如第62個組合就是sssss9，第63個組合就是ssssba，再利用洗牌的演算法，把原字元打亂後保存，那麼對應位置的組合字元串就會是無序的組合。
（6）把長網址存入資料庫，取返回的id，找出對應的字元串，例如返回id為1，那麼對應上面的字元串組合就是aaa,同理id為2時，字元串組合為aaa，依次類推，直至到達62種組合後才會出現重復的可能，所以如果用上面的62個字元，任意取6個字元組合成字元串的話，你的數據存量達到500多億後才會出現重復的可能。
⑷ 微博中形成的鏈接URL規則是什麼有什麼機制在其中嗎
通過演算法壓縮的,主要是使用了MD5。搜「shorturl演算法」有詳解
希望採納
⑸ 求一個不會生成重復值的短網址演算法
這個應該是先生成一個隨機字元串，然後查詢資料庫中是否已經存在，不存在就入庫，存在就再換一個再查，短址本來就只有五位左右的長度，我覺得不管用什麼演算法都不可能保證不重復，所以只能通過對以前生成的來對比。
⑹ 新浪微博中為什麼把url轉換成短地址，這樣有什麼好處
1：無論多長的微博，都能夠轉成固定長短的短鏈，防止某些連接太長影響用戶輸入其他內容。
2：所有短鏈在演算法上無法直接解鏈，必須經過新浪的伺服器，把鏈接系統控制到自己的手上。這對網路內容審察來說作用極其大，如果有人發的微博包含敏感內容，新浪就不予中轉。
3：重新組織鏈接網頁的內容，方便用戶在手機端查看。
4：由於長鏈中可能會包含#或者@這些特殊字元，給客戶端的字元串處理帶來壓力，編碼可以消除這些特殊符號。
5：由於所有鏈接都要經新浪的伺服器，因此伺服器保存有所有的鏈接，方便進行數據挖掘和統計分析。
⑺ 縮我短鏈接的縮短演算法是什麼這些短網址的演算法都是統一的嗎
短鏈接的核心演算法一般採用：自增序列演算法或者自減序列演算法。伺服器接收到一個網址時，給這個網址分發一個id，這個id是redis緩存中的一個自增序列，保證了每一個存儲的網址的id都是唯一的。比如當一個鏈接提交時，給這個鏈接分配一個唯一標識id：0，再提交一個鏈接過來時，給後面這個鏈接分配一個唯一標識id：1，以此類推。市面上短網址演算法都差不多出自於此。
⑻ 短地址的演算法原理
現在的短地址網站基本都是通過ASP或者PHP轉向來實現網址縮短。 1)將長網址md5生成32位簽名串,分為4段, 每段8個位元組;
2)對這四段循環處理, 取8個位元組, 將他看成16進制串與0x3fffffff(30位1)與操作, 即超過30位的忽略處理;
3)這30位分成6段, 每5位的數字作為字母表的索引取得特定字元, 依次進行獲得6位字元串;
4)總的md5串可以獲得4個6位串; 取裡面的任意一個就可作為這個長url的短url地址; a-z，A-Z，0-9，這62位取6位組合，可產生500多億個組合數量。把數字和字元組合做一定的映射，就可以產生唯一的字元串，如第62個組合就是aaaaa9，第63個組合就是aaaaba，再利用洗牌演算法，把原字元串打亂後保存，那麼對應位置的組合字元串就會是無序的組合。
把長網址存入資料庫,取返回的id,找出對應的字元串,例如返回ID為1，那麼對應上面的字元串組合就是bbb,同理 ID為2時，字元串組合為bba,依次類推,直至到達64種組合後才會出現重復的可能，所以如果用上面的62個字元，任意取6個字元組合成字元串的話，你的數據存量達到500多億後才會出現重復的可能。
⑼ java url參數去重
言歸正傳。
所謂的Url去重（我一直沒找到對應的英文，URL Filtering ?），就是爬蟲將重復抓取的URL去除，避免多次抓取同一網頁。爬蟲一般會將待抓取的URL放在一個隊列中，從抓取後的網頁中提取到新的URL，在他們被放入隊列之前，首先要確定這些新的URL沒有被抓取過，如果之前已經抓取過了，就不再放入隊列。
最直觀的做法 – hash表
為了盡快把整個爬蟲搭建起來，最開始的URL去重採用方案是一個內存中的HashSet，這是最直觀的方法，所有人都能想得到。HashSet中放置的就是URL的字元串，任何一個新的URL首先在HashSet中進行查找，如果HashSet中沒有，就將新的URL插入HashSet，並將URL放入待抓取隊列。
這個方案的好處是它的去重效果精確，不會漏過一個重復的URL。它的缺點是，我的爬蟲第二天早上就掛了，Out Of Memory。因為隨著抓取網頁的增加，HashSet會一直無限制的增長。另外，網路中的很多URL其實是很長的，有大量的URL長度達到上百個字元。當然，因為我的爬蟲是跑在一個小伺服器上，JVM的內存本來就不多，否則它應該能再多撐1-2天。
簡單估算一下，假設單個URL的平均長度是100 byte（我覺著這已經非常保守了），那麼抓取1000萬的URL就需要：
100 byte * 10 000 000 = 1 GB
而1000萬URL在整個互聯網中實在是滄海一粟。可以了解，需要多大的內存才能裝下所有URL的HashSet。
壓縮URL
為了我的爬蟲能再多撐幾天，同時不想改動太多的代碼，第二個版本增加了一個小功能，就是HashSet中不存儲原始的URL，而是將URL壓縮後再放進去。貌似有不少paper中討論過如何對URL進行壓縮，包括新浪微博中的短URL其實也是個不錯的方案，可惜這些方法我都不會。為了偷懶，我直接用MD5對URL做編碼。
MD5的結果是128 bit也就是16 byte的長度。相比於之間估計的URL平均長度100byte已經縮小了好幾倍，可以多撐好多天了。
當然，哪怕找個一個可以壓縮到極致的演算法，隨著URL越來越多，終有一天會Out Of Memory。所以，這個方案不解決本質問題。
MD5另外一個問題是，有可能兩個相同的URL被映射成同一個MD5值，這樣的話，它們中有一個就永遠不會被抓取了。我不太確定的是，這個概率會有多大。如果非常小的話，這微小的誤差倒也不會有太大影響。
Bloom Filter
基於內存的HashSet的方法存在一個本質的問題，就是它消耗的內存是隨著URL的增長而不斷增長的。除非能夠保證內存的大小能夠容納下所有需要抓取的URL，否則這個方案終有一天會到達瓶頸。
這時候就會想，要找一個類似於HashSet的但所消耗的內存相對固定而不會不斷增長的方案，於是自然想到了Bloom Filter。關於Bloom Filter的概念這里就不多談了，網上隨處可以找到。我簡單嘗試了一下Bloom Filter，但是很快就放棄了。基於Bloom Filter的方案有幾個問題：
第一個是理論上的。Bloom Filter會將一些正常的樣本（在我這就是沒有抓取過的URL）過濾掉，即所謂的False Positive。當然，這概率有多大，取決於Bloom Filter的參數設置。但這引出了下一個問題；
第二個是實踐中的，即Bloom Filter的那幾個參數應該如何設置？m，k，n應該設置成多少才合適，這個我沒有經驗，而且可能需要反復的實驗和測試才能夠比較好的確定下來；
以上兩個問題還不是我放棄Bloom Filter的根本原因，真實的原因是我在做的是一個爬蟲框架，上面可以會啟動很多的爬蟲任務，每個任務可能抓取自己特定的URL，而且任務之間是獨立的。這樣，對於每個任務都需要有一個Bloom Filter，雖然對於單一任務它使用Bloom Filter所消耗的內存是固定的，但是任務的增多會導致更多的Bloom Filter，從而導致更多的內存消耗。仍然存在內存溢出的可能。
但如果只是一個抓取任務，那麼採用Bloom Filter應該是一個非常不錯的選擇。
BerkeleyDB
我終於明白我所需要的其實是一個可以放在disk上的去重方案，這樣，內存溢出將永遠成不了可能。很早就知道有BerkeleyDB這么一個東西，但第一次真正了解還是在Amazon的Dynamo那篇論文中提到過採用了BerkeleyDB作為單機上的底層存儲。當時覺著這東西真另類，原來還有叫做「DB」的東西卻不支持SQL。那時候還沒有NOSQL這詞，把這樣的東西叫做non-relational database。
BerkeleyDB是一個key-value database，簡單的說，就是一個在disk上的hash表，這也是為什麼它可以被用來做URL去重的原因。它另外一個另類的地方是，它是和程序運行在同一個進程空間中的，而不像一般的db，是做為單獨的程序運行。
這里附上Heritrix中使用BerkeleyDB做URL去重的代碼，一探究竟：（代碼位於Heritrix源代碼的org.archive.crawler.util.BdbUriUniqFilter）
有一堆做初始化和配置的函數就直接忽略了，真正相關的函數就只有兩個：
[java] view plain
/**
* Create fingerprint.
* Pubic access so test code can access createKey.
* @param uri URI to fingerprint.
* @return Fingerprint of passed <code>url</code>.
*/
public static long createKey(CharSequence uri) {
String url = uri.toString();
int index = url.indexOf(COLON_SLASH_SLASH);
if (index > 0) {
index = url.indexOf('/', index + COLON_SLASH_SLASH.length());
}
CharSequence hostPlusScheme = (index == -1)? url: url.subSequence(0, index);
long tmp = FPGenerator.std24.fp(hostPlusScheme);
return tmp | (FPGenerator.std40.fp(url) >>> 24);
}
[java] view plain
/**
* value: only 1 byte
*/
private static DatabaseEntry ZERO_LENGTH_ENTRY = new DatabaseEntry(
new byte[0]);
protected boolean setAdd(CharSequence uri) {
DatabaseEntry key = new DatabaseEntry();
LongBinding.longToEntry(createKey(uri), key);
long started = 0;
OperationStatus status = null;
try {
if (logger.isLoggable(Level.INFO)) {
started = System.currentTimeMillis();
}
status = alreadySeen.putNoOverwrite(null, key, ZERO_LENGTH_ENTRY);
if (logger.isLoggable(Level.INFO)) {
aggregatedLookupTime +=
(System.currentTimeMillis() - started);
}
} catch (DatabaseException e) {
logger.severe(e.getMessage());
}
if (status == OperationStatus.SUCCESS) {
count++;
if (logger.isLoggable(Level.INFO)) {
final int logAt = 10000;
if (count > 0 && ((count % logAt) == 0)) {
logger.info("Average lookup " +
(aggregatedLookupTime / logAt) + "ms.");
aggregatedLookupTime = 0;
}
}
}
if(status == OperationStatus.KEYEXIST) {
return false; // not added
} else {
return true;
}
}
簡單解釋一下：
第一個函數createKey是在做URL的壓縮，它將任意長度的URL轉換成一個long型的值。long型的取值范圍有2^64，因此兩個URL映射成同一個long型值的概率應該挺低的。但我也沒太細看這個函數，所以它的效果到底如何不確定。
第二個函數setAdd就是將被壓縮的URL寫入到BerkeleyDB。之前說過，BerkeleyDB是一個key-value database，它的每條記錄都包括了一個key和一個value。但是在URL去重中，value不重要（比如我們之前內存中用的也是HashSet而不是HashMap），因此這里統一用一個byte長度的值來表示value，就是這個static變數ZERO_LENGTH_ENTRY。
別看setAdd有這么多行，真正有用的就這一行：
[java] view plain
status = alreadySeen.putNoOverwrite(null, key, ZERO_LENGTH_ENTRY);
將壓縮後得到的long型值作為key，ZERO_LENGTH_ENTRY作為value插入到BerkeleyDB中，如果db中已經有了這個long型值，就會返回OperationStatus.KEYEXIST，表示對應的URL之前已經抓取到了，那麼這個URL就不會放入待抓取隊列中。
最後
比較遺憾的是，我還沒抽出空對BerkeleyDB這個方案做性能測試，不確定它每秒能執行多少次setAdd操作，是否足夠滿足我們性能的要求。以後補上。
另外，雖然我不了解，但我認為像網路這樣專業的搜索引擎，它的爬蟲的URL去重方案可能比這里列舉的要復雜的多，畢竟那個的各方面的要求也要更高。
⑽ 微博上是如何把一個長URL變成一個短小的URL的這是一種加密方式嗎
那是新浪針對新浪微博推出的一種功能。不用用戶自己轉換，這個步驟由新浪來代勞。
他不是加密方式，簡單的說就是換了一種表現形式
為什麼要這樣做的，原因我想有這
樣幾點：
1、微博限制字數為140字一條，那
么如果我們需要發一些連接上去，
但是這個連接非常的長，以至於將
近要佔用我們內容的一半篇幅，這
肯定是不能被允許的，所以短網址
應運而生了。
2、短網址可以在我們項目里可以
很好的對開放級URL進行管理。有
一部分網址可以會涵蓋XX，暴力，
廣告等信息，這樣我們可以通過用
戶的舉報，完全管理這個連接將不
出現在我們的應用中，應為同樣的
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，這樣幾乎不會出現太
大的重復。