短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，这样几乎不会出现太
大的重复。