有同学了解短网址还原的原理吗？

https://www.zhihu.com/question/19852154/answer/72452255 勤用搜索……

现在推特就用的这种技术吧

现在还只用度娘，停留在五年前了吧？

不是数据库插一个对应的还原链接吗...

就是服务端请求一下这个短网址，然后当 http status code 是 301 / 302 的时候，输出最终跳转地址吧。

你说的是 301 吧？

@evil4 点醒了。。。谢谢

talk is cheap

https://gist.github.com/KIDJourney/5970a75b1ca01c7c10547864e3d61010

一个 request 请求得到返回值输出。。。没啥技术含量了。。。

跳转后复制

用发号策略， 别用 hash https://www.zhihu.com/question/29270034

kv,key=原网址 hash 后 url,value=原网址，然后重定向，搞定

还原？都是跳转好么

@mooo 要思考下 如果只是自己公司用 网址数量一般不会很多 hash 策略好多了 再加上网址过期策略 基本 hash 是比较好的策略

1，短网址实现：预先生成 100*100*100 个 key，新的 URL 依次去填 value，不要使用 HASH
2，短网址查找：查找 Key 即可
3，短网址还原：curl + http 200/301

我认为的短网址原理：
插入到数据库（先查重），对自增 ID 进行进制转换（ 16/62/64 等进制）
转换的结果作为后缀使用。

至于短网址还原，直接请求短网址地址，然后获取 header 的 location 字段即可。

其实就是 key-value 键对，key 唯一（也就短域名后面的那些短字符串）对应这 value （就是你原先的长网址）。然后存储进数据库，主要就是数据库存储和查询操作。
相关项目你去看看 https://github.com/YOURLS/YOURLS
磕下源码就大概了解了。

楼主要做的是还原任意一个短网址，不是仅仅还原自己家的
楼上一堆介绍短网址原理，怎么存数据库的都是不审题的
楼主的需求 bitly.co 已经做得很好了

这....就...非常尴尬了
18 楼之前的

php 短网址还原
python 短网址还原

加个语言就有大把结果了。
之所以造成我们用的不是一个百度，那是因为姿势不正确啊。

一路 301 302 回去就是了，
不过有见过一种所谓的短地址，是会给你另外一个页面，然后在里面点按钮跳转的，这个要多一个步骤了

@imdong 其实好像都不查重的，同样一个原链接生成两次，就发两个号。

一一对应存在数据库里。。。。

服务端不就保存一个 map 嘛，根据 key 拿 value 的事情呀~

很简单，你请求一个短连接过来，我给你返回个网址，301 重定向，根本就没有还原短网址这一说法

你输入一个短网址 a，后端访问这个短网址后根据返回的头信息可以获取原网址 b，将 b 输出到前端就可以了。应该就是这么简单粗暴
至于你说的“分步解析出短网址还原过程中每个 url ”，不清楚是什么意思

如果用算法生成短网址，那么可能用算法还原。
但是如果用字典或者说数据库生成，那么外部人员是无法还原的

key-value 或者算法 md5 那种方式类似缩略图

谁告诉你能还原的？

你给的这个网站还原的方式就是 get 一次，把 302 地址给你，这就叫还原了？

负载均衡+kv 数据库。。。

每一家公司的短地址生成方式都不太一样，想直接还原是不可能的。直接访问一下查看历史跳转记录就行。

nginx+lua+redis。。了解一下。

生成方式不一样, 还原方式就不一样, 我说一个基于文件的短网址吧
一个文件, 原本 size 是 x, 网址长度 y, 写入文件后, 文件大小变成 z, 那么把 x,y 记录下来, 下次可以以 fseek 的方式还原 url
这里有几个问题
1. x,y 可能比较大或者说是长度比较长, 那么可以转为高进制, 比如 64 进制, 进制越高, 长度越短, 但是稀奇古怪的字符越多
2. url 越来越多, 文件越来越大, 那么可以占用 1 位长度来做散列, 能保证很长的一段时间 url 足够短

不建议用任意一种数据库来存储这个对应关系