链接缩短，顾名思义，使用短链接技术，我们可以将长链接压缩成更短的链接。并且通过跳转的方式，将用户的请求从短链接重定向到一个长链接。短链接主要用于微博、BBS等对帖子字数有限制的网站。通过使用短链接，用户可以专注于帖子的内容，而不用担心链接过载。长问题。这里我们以百度的dwz.cn 短链接服务为例，我们用百度搜索“hello world”，链接是https://www.baidu.com/s?ie=utf-8&f=8&rsv_bp =0&rsv_idx=1&tn =baidu&wd=hello%20world&rsv_pq=8487bffe00068c60&rsv_t=a9e0f5b6haiMQwAi4N2y8PHDv37rM6sjjKrHJb6KdMGg2dQuUjAnmSEnXtE&rqlang=cn& rsv_enter=1&rsv_sug3=10&rsv_sug1=9&rsv_sug=

别说这么长的链接抢占了微博空间，也会影响微博的美观。这时候我们可以使用短链接工具来压缩上面的长链接。压爱短链接为：http://www.aifabu.com/5DDXhH。可以看出，压缩后的链接宽度明显短于原始链接。

短链接在线生成地址：https://www.aifabu.com/ (稳定  高速  安全 带绿标)

2. 短链接原理：常用短链接压缩算法

有两种常见的 短链接 压缩算法。首先是对URL进行hash运算，对得到的hash值进行逐级运算，得到更短的hash值。二是利用数据库自增ID或分布式key-value系统模拟发行者发号、压缩URL。这两种方法各有优缺点。哈希运算简单易实现，但存在一定的冲突率。随着 URL 压缩次数的减少，冲突次数也会减少，最终导致部分用户跳转到错误的地址，影响用户体验。数字发行者和压缩 URL 的优缺点与哈希压缩算法正好相反，而且好处是不存在冲突问题。缺点是实现有点复杂，需要协调发行人取初始号。本文对应的训练项目是基于第二种压缩算法的，下面将详细分析第二种算法。

3. 使用编号策略压缩 URL

编号策略是这样的，当有新链接进来时，编号设备会发送一个与之对应的编号。未来，只要有新的链接进来，编号设备就会继续发号。例如，第一个入链发送方发送数字0，对应的短链接为xx.xxx/0，第二个入链发送方发送1，对应的短链接为xx.xxx/1，很快。数字生成器发出的十进制数需要转换成62的补码，这样可以大大减少数字转换成字符串后数字的粗细。比如数字10,000,000,000是数字生成器发出的，如果不转换成62的补码，可以直接在域名前面条带化，得到这样的链接xx.xxx/10000000000。将上面的数转换成62的补码，结果是AOYKUa，长度只有6位，拼接得到的链接是xx.xxx/AOYKUa。可以看出，经过十六进制转换后得到的短链接的长度更短。6位62的补数，对应的数空间为626，约等于568亿。也就是说发号器可以发送568亿个号码，这个号码空间应该可以满足大部分项目的需求，所以基本不用怕发号器没有号发的情况. 以上就是编号策略压缩URL的原理。实际上，在编写代码的过程中需要考虑很多细节，比如缓存和存储。本文对应的项目使用的缓存是Guava工具包中提供的缓存模块，数据库使用的是MySQL。项目基于以上两个工具和一些第三方库，实现了URL压缩、还原、跳转三个基本功能。这就是短链接原理

4. 一些细节

Q：同一个长链接，短链接是不是每次都转换成一样的？

A：对于同一个长链接，转换后的短链接不一定每次都一样。短链接原理是如果查询缓存没有命中，发送方会向链接发送一个新号码。需要注意的是，缓存应该缓存经常转换的热门链接。假设缓存过期时间设置为一小时。如果一个链接非常活跃，缓存查询命中后，缓存会刷新链接的生命周期并重新计时。链接始终存储在缓存中。对于一些稀有的链接，从被存储在缓存中开始，很有可能在其生命周期内不再被访问，而缓存将在生命周期结束时删除该记录。下次你转换这个顽固的链接时，缓存未命中，号码生成器会再次发出号码。这会导致一个长链接对应多个短链接的情况，不仅消耗存储空间，还消耗发射端的资源。那么有没有办法解决这个问题呢？是否可以考虑建一个长链接-短链接键值表，把所有长链接和对应的短链接都存放在里面，实现长短链接一对一一致。但是景色很美，现实却不然，原因是这样一个表中存储所有长链接-短链接对本身就需要很大的存储空间，可能比不常见的链接对应的还要多。短链接 浪费的那一点空间似乎是值得的。那么有没有办法解决这个问题呢？是否可以考虑建一个长链接-短链接键值表，把所有长链接和对应的短链接都存放在里面，实现长短链接一对一一致。但是景色很美，现实却不然，原因是这样一个表中存储所有长链接-短链接对本身就需要很大的存储空间，可能比不常见的链接对应的还要多。短链接 浪费的那一点空间似乎是值得的。那么有没有办法解决这个问题呢？是否可以考虑建一个长链接-短链接键值表，把所有长链接和对应的短链接都存放在里面，实现长短链接一对一一致。但是景色很美，现实却不然，原因是这样一个表中存储所有长链接-短链接对本身就需要很大的存储空间，可能比不常见的链接对应的还要多。短链接 浪费的那一点空间似乎是值得的。原因是在这样的表中存储所有的长链接-短链接 对本身需要大量的存储空间，这可能比不常见的链接对应更多。短链接 浪费的那一点空间似乎是值得的。原因是在这样的表中存储所有的长链接-短链接 对本身需要大量的存储空间，这可能比不常见的链接对应更多。短链接 浪费的那一点空间似乎是值得的。

Q：短链接使用301跳转还是302跳转

A：说一下短链接的服务使用场景中301和302跳转的区别：用户第一次访问某个短链接后，如果服务器返回301状态码，用户会在后续多次访问同一个短链接时，浏览器会直接请求重定向地址而不是短链接地址，导致服务器很难接收到用户的请求. 如果服务器返回302状态码并告诉浏览器不要缓存短链接请求，那么用户每天访问短链接时都会去短链接服务器获取长链接地址@>，然后跳转到 . 从语法上来说，301重定向比较合适，因为是永久重定向，不会天天访问服务器，而且还可以减轻服务器的压力。这就是短链接原理。但是，如果使用301重定向，服务器很难准确收集到用户的访问行为。相反，302跳转会减轻服务器的压力，但是服务器可以准确的采集到用户此时的访问行为。根据用户的访问行为，可以做一些分析，得出一些有趣的推论。例如，可以根据用户的IP地址获取用户的区域分布情况，根据User-Agent消息头分析用户的操作系统和浏览器比例。302跳转会减轻服务器的压力，但是服务器可以准确的采集到用户此时的访问行为。根据用户的访问行为，可以做一些分析，得出一些有趣的推论。

以上就是关于《短链接原理是什么？短链接转换的方法》的全部内容了，感兴趣的话可以点击右侧直接使用哦！》》在线短链接生成器