许多大型网站都增加了短链接的功能。如果要使用url cn短链接，主要是因为微博只允许发送140个单词。如果链接地址太长，则发送的单词数量将大大减少。短链接的主要职责是将原始链接的长地址压缩有6个字母的短链接地址。当我们点击这6个字母的链接时，我们可以跳转到原始链接地址。

一开始，我以为url cn短链接是根据某种算法将原始链接压缩成短链接，然后根据算法将原始链接从短链接转换为原始链接。后来，我尝试了下一个压缩算法（如gzip压缩算法)url字符串越压缩，长度就越长。通过对压缩算法的一些了解，发现通过压缩算法来实现这个功能是不可靠的。

后来在网上找到了一个生成算法，主要使用MD5算法加密原始链接(这里使用的算法)MD5加密字符串长度为32位)，然后对加密字符串进行处理，以获得短链接地址。

原来的算法是C版的，这里我把算法修改成C版Java版本的.算法的具体代码如下：

代码

输出结果

执行上述代码的结果如下，将产生4组6位字符串，任何一组都可作为当前字符串的短链接地址。

跳转原理

当我们生成短链接时，我们只需要在表中(数据库或数据库或NoSql）存储原始链接和短链接之间的映射关系。当我们访问短链接时，我们只需要从映射关系中找到原始链接就可以跳转到原始链接。

参考1。调用第三方接口自动旋转2.springboot实现长链接转短链接转换原理：url cn短链接的转换原理：url通过一系列方法，转换为6位短码（只要不重复，任何方式）；将长度链接存储在数据库中，形成相应的关系；访问短链接时，在数据库中找到相应的长链接，并通过重定向实现原始链接url访问；（如果您的转换模式可以恢复，您也可以不使用数据库，但必须确保转换后的短码不能重复）（与文本部分相同的算法）缺点：此index取值范围只有32个，永远不可能是2.3.6.7.10.11…。所以再写一个算法。

3.改进2的算法算法步骤如下：

对Url进行md5编码对md5码进行base64编码，长度为22消除base64码中的‘+和‘/’，取前一段，如果位数不够，使用base64码加上url再进行一次md5、用此补齐，循环4直至位数满足短码的长度要求

网上有很多算法，比如自增长算法(这可能是增长锁的问题)和随机数算法。理论上是可行的，但是这些算法不能重复，也就是可能会有一个url对应表中有多个记录。使用上述基于上述。Md5的算法可以解决这个问题。在发现代码存在时，进一步核实原始代码url是否一致，如果一致就不是冲突。

最烂的回答

实现算法，将长地址转换为短地址。实现长短对应。然后实现其逆运算，将短地址转换为长地址。

这个答案看起来很完美，然后候选人会说时间相对较短。如果我给我时间，我会找到这个算法来解决这个问题。但对计算机或信息理论有一点常识的人可以发现，这个算法就像永动机一样，永远找不到。即使我们定义了100个短地址。然后它改变了62的100次。=10数字+26大写字母+26小写字母。不管这个数字有多大，他都不可能比世界上可能的长地址大。因此，不可能实现一一对应。

换句话说，如果有这样的算法和逆运算，那么基本上现在的压缩软件可以停止进食，世界上所有的信息都可以压缩到100个字符。这可能吗。

短URL系统是如何设计的？

另一个坏答案

和上面一样，我们也找了一个算法，把长地址变成短地址，但是没有逆运算。我们需要把短对长的关系存在DB中、通过短查长时间，需要检查DB。

怎么说呢，本质没有改变。如果有这样的算法，必然会发生碰撞，也就是说，多个长地址变成同一个短地址。因为我们无法预测我们会在这个系统中输入什么样的长地址，所以不可能实现这样一个绝对不碰撞的地址hash函数。

坏答案

然后我们用一个hash算法，我承认它会碰撞，碰撞后我会在后面加1、2、3。

ok，在这种情况下，当通过这种情况，当通过这种情况时，hash算法算出来后，我们可能需要做btree大于大于小于或like找到后面应该添加1、2或3，这也可能是由于输入的长地址集的不确定性。导致生成短地址时间的不确定性。同样糟糕的答案是随机生成一个短地址，找出是否使用，然后随机使用，所以往复，直到随机到一个无用的短地址。

正确的原理

以上是几个典型的错误答案，下面我们直接说正确的原理。

正确的url cn短链接生成原理是通过号码发送策略，给每个长地址，发送号码，小系统直接使用mysql自增索引完成。如果是大型应用，可以考虑各种分布式key-value系统做发号器。继续增加自己。第一个使用此服务的人得到的短地址是短地址。xx.xx/0第二个是xx.xx/1第11个是xx.xx/a第一次，相当于实现了一个62进制的自增字段。

几个子问题

1.如何使用数据库或62进制？KV存储来做？

事实上，我们不需要在存储中使用62进制和10进制。例如，在第1万个长地址中，我们给出的短地址对应的编号是9999。我们通过存储自增获得999，然后将10进制转换为62进制，转换为62进制。您可以自己实现这种10~62进制转换。

2.如何保证同一长地址，每次转出都是同一短地址

在上述发号原理中，不判断长地址是否已转移。也就是说，用百度主页地址转，我给一个xx.xx/abc过一段时间你再来回，我会给你一个xx.xx/xyz。这看起来很糟糕，但有什么不好呢？不幸的是，它不是一个接一个的对应，而是一个又长又短。这不符合我们的完美主义基因，那么还有什么错呢？

有些人说它浪费了空间，这是对的。同一长地址，产生多个短地址记录，这显然是浪费空间。所以我们如何避免浪费空间，有人很快回答我，建立一个长短KV存储即可。嗯，听起来很合理，但是。。。KV存储本身就是浪费了很多空间。所以我们用空间换空间，似乎用大空间换小空间。真的划算吗？我们应该考虑这个问题。当然，也不是没有办法解决。我们不能一一对应。我们能打折吗？

这个问题的答案太多了，每个问题都有自己的动作。这个方案最简单的方法就是建立一个长对短的方案。hashtable，这相当于用空间换取空间，同时换取优雅的设计(真正的一对一)。实际情况是有很多性价比高的折扣方案可以使用，因人而异。那我就来说说我的计划。

我的计划是：用key-value存储，保存“最近”长对短的对应关系。注意是长对短的对应关系。“最近”也就是说，我并没有保留全部的长短关系，而是只保留了最近的关系。例如，使用一小时过期机制来实现它。LRU淘汰。

这样，长到短的过程就变成了这样:

在这个“最近”在表中检查，看长地址是否有相应的短地址，有直接返回，并将这一点进行检查，看看长地址是否有相应的短地址，key-value正确的过期时间延长到一小时

如果没有，则通过发号器生成一个短地址，并将此“最近”表中，过期时间为1小时

所以当一个地址被频繁使用时，它将永远在这里key-value在表中，您总是可以返回原始生成的短地址，而不会出现重复问题。如果使用不频繁，那么长到短。key就会过期。

以上就是关于《长url cn短链接算法分析》的全部内容了，感兴趣的话可以点击右侧直接使用哦！》》在线短链接生成器