blocks|key|1432382|text|不，他们不使用文件。当你点击这样的链接时，一个带有完整网址的超文本传输协议请求就会被发送到他们的服务器，比如http://bit.ly/duSk8wK+(指向这个问题的链接)。他们读取路径部分(这里是duSk8wK)，它映射到他们的数据库。在数据库中，他们会找到一个描述(有时)，你的名字(有时)和真实的URL。然后，它们发出一个重定向，即HTTP+302响应和报头中的目标URL。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1432383|这种直接重定向很重要。如果你要使用文件或者首先加载超文本标记语言，然后重定向，浏览器会将TinyUrl添加到历史记录中，这不是你想要的。此外，重定向到的站点将看到引用者(您最初来自的站点)是TinyUrl链接所在的站点(即，twitter.com，您自己的站点，无论链接在哪里)。这一点同样重要，这样网站所有者就可以看到人们来自哪里。如果加载了重定向的页面，这也不会起作用。|1432384|PS:还有更多类型的重定向。HTTP+301的意思是:永久重定向。如果发生这种情况，浏览器将不再请求bit.ly或TinyUrl站点，而这些站点希望统计命中率。这就是为什么使用HTTP302，它是一个临时重定向。浏览器会再次询问TinyUrl.com或bit.ly，这使得它可以为你计算点击次数(一些小型url服务提供了这一功能)。|1432385|entityMap|0|LINK|mutability|MUTABLE|url|http://bit.ly/duSk8wK^0|2S|7|1I|L|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]]|D|@$9|U|A|V|1|W]]|E|$]]|$1|F|3|G|5|6|7|X|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|Y|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|Z|8|@]|D|@]|E|$]]]|K|$L|$5|M|N|O|E|$P|Q]]]]

No, they don't use files. When you click on a link like that, an HTTP request is send to their server with the full URL, like <a href="http://bit.ly/duSk8wK" rel="noreferrer">http://bit.ly/duSk8wK</a> (links to this question). They read the path part (here <code>duSk8wK</code>), which maps to their database. In the database, they find a description (sometimes), your name (sometimes) and the real URL. Then they issue a redirect, which is a HTTP 302 response and the target URL in the header.

This direct redirect is important. If you were to use files or first load HTML and then redirect, the browser would add TinyUrl to the history, which is not what you want. Also, the site that is redirected to will see the referrer (the site that you originally come from) as being the site the TinyUrl link is on (i.e., twitter.com, your own site, wherever the link is). This is just as important, so that site owners can see where people are coming from. This too, would not work if a page gets loaded that redirects.

PS: there are more types of redirect. HTTP 301 means: redirect permanent. If that would happen, the browser will not request the bit.ly or TinyUrl site anymore and those sites want to count the hits. That's why HTTP 302 is used, which is a temporary redirect. The browser will ask TinyUrl.com or bit.ly each time again, which makes it possible to count the hits for you (some tiny url services offer this).

blocks|key|1432430|text|其他人已经回答了重定向是如何工作的，但您也应该知道它们是如何生成微型urls的。您会错误地听到他们创建URL的散列，以便为缩短的URL生成唯一的代码。这在大多数情况下是不正确的，他们没有使用散列算法(在这种情况下，您可能会有冲突)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1432431|大多数流行的网址缩短服务只是在网址数据库中获取ID，然后将其转换为Base36+a-z0-9或Base62(区分大小写)。|offset|length|1432432|TinyURL数据库表的简化示例：|1432433|ID+++++++URL+++++++++++++++++++++++++++VisitCount
+1+++++++www.google.com++++++++++++++++++++++++26
+2+++++++www.stackoverflow.com+++++++++++++++2048
+3+++++++www.reddit.com++++++++++++++++++++++++64
...
+20103+++www.digg.com+++++++++++++++++++++++++201
+20104+++www.4chan.com+++++++++++++++++++++++++20|code-block|syntax|javascript|1432434|允许灵活路由的Web框架使得处理传入的URL变得非常容易(Ruby、ASP.NET、MVC等)。|1432435|因此，在您的you服务器上，您可能有一个路由操作，如下所示(伪代码)：|1432436|Route:+www.mytinyurl.com/{UrlID}
Route+Action:+RouteURL(UrlID);|1432437|它将任何传入的请求路由到您的服务器，该服务器在您的域www.mytinyurl.com之后包含任何文本到您关联的方法RouteURL。它将URL中正斜杠后传入的文本提供给该方法。|1432438|因此，假设您请求:+www.mytinyurl.com/fif|1432439|然后将"fif“传递给您的方法RouteURL(String+Fif)。然后，RouteURL会将"fif“转换为它的等价物20103，并发出一个数据库请求，以重定向到存储在ID+20103下的任何base10+(在本例中为www.digg.com)。在重定向到正确的URL之前，您还可以将Digg的访问计数增加1。|1432440|这是一个非常简单的例子，但你应该能够得到大体的概念。|1432441|entityMap|0|LINK|mutability|MUTABLE|url|case+insensitive^0|0|14|6|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|19|8|@]|9|@$D|1A|E|1B|1|1C]]|A|$]]|$1|F|3|G|5|6|7|1D|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|1E|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|1F|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1G|8|@]|9|@]|A|$]]|$1|Q|3|R|5|J|7|1H|8|@]|9|@]|A|$K|L]]|$1|S|3|T|5|6|7|1I|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1J|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1K|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1L|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]]|11|$12|$5|13|14|15|A|$16|17]]]]

Others have answered how the redirects work but you should also know how they generate their tiny urls. You'll mistakenly hear that they create a hash of the URL in order to generate that unique code for the shortened URL. This is incorrect in most cases, they aren't using a hashing algorithm (where you could potentially have collisions).

Most of the popular URL shortening services simply take the ID in the database of the URL and then convert it to either Base 36 [a-z0-9] (case insensitive) or Base 62 (case sensitive). 

A simplified example of a TinyURL Database Table:

<pre><code>ID URL VisitCount
 1 www.google.com 26
 2 www.stackoverflow.com 2048
 3 www.reddit.com 64
...
 20103 www.digg.com 201
 20104 www.4chan.com 20
</code></pre>

Web Frameworks that allow flexible routing make handling the incoming URL's really easy (Ruby, ASP.NET MVC, etc).

So, on your webserver you might have a route action that looks like (pseudo code):

<pre><code>Route: www.mytinyurl.com/{UrlID}
Route Action: RouteURL(UrlID);
</code></pre>

Which routes any incoming request to your server that has any text after your domain www.mytinyurl.com to your associated method, RouteURL. It supplies the text that is passed in after the forward slash in your URL to that method.

So, lets say you requested: www.mytinyurl.com/fif

"fif" would then be passed to your method, RouteURL(String UrlID). RouteURL would then convert "fif" to its base10 equivalent, 20103, and a database request will be made to redirect to whatever URL is stored under the ID 20103 (in this case, www.digg.com). You would also increase the visit count for Digg by one before redirecting to the correct URL. 

This is a really simplified example but you should be able to get the general idea.

blocks|key|1432496|text|作为@A+Salcedo答案的扩展：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1432497|一些网址缩短服务(Tinyarro.ws)通过使用Unicode+(UTF-8)来对缩短网址中的字符进行编码，从而在必须添加额外符号之前允许更多的网站。因为大多数UTF-8+is+accepted+for+use+((IRI)+RFC+3987+handled+by+most+browsers)都是从62站点的每符号到~1,112,064。|offset|length|style|CODE|1432498|在透视图中，一个可以用2个符号(1,112,064*1,112,064)编码的1.2366863e%2B12站点-在2009年11月，bit.ly上的缩短链接被访问2.1十亿次(Around+that+time,+bit.ly+and+TinyURL+were+the+most+widely+used+URL-shortening+services.)，这比你只能容纳2个符号少~600倍，所以对于所有url缩短服务的存在，它应该至少再持续20年，直到添加第三个符号。|1432499|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/2742852/unicode-characters-in-urls#answer-2744184|1|https://en.wikipedia.org/wiki/Internationalized_Resource_Identifier|2|https://en.wikipedia.org/wiki/URL_shortening#History^0|0|47|2|4H|9|29|P|0|30|13|1|0|G|J|1T|6|28|3|2F|2F|2|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@$D|X|E|Y|F|G]|$D|Z|E|10|F|G]]|9|@$D|11|E|12|1|13]|$D|14|E|15|1|16]]|A|$]]|$1|H|3|I|5|6|7|17|8|@$D|18|E|19|F|G]|$D|1A|E|1B|F|G]|$D|1C|E|1D|F|G]]|9|@$D|1E|E|1F|1|1G]]|A|$]]|$1|J|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]|R|$5|M|N|O|A|$P|S]]|T|$5|M|N|O|A|$P|U]]]]

As an extension to @A Salcedo answer:

Some url shortening services (Tinyarro.ws) go to extreme by using Unicode (UTF-8) to encode characters in shortened url - which allows higher amount of websites before having to add additional symbol. Since most of <a href="https://stackoverflow.com/questions/2742852/unicode-characters-in-urls#answer-2744184">UTF-8 is accepted for use</a> (<a href="https://en.wikipedia.org/wiki/Internationalized_Resource_Identifier" rel="nofollow noreferrer">(IRI) RFC 3987 handled by most browsers</a>) that bumps from <code>62</code> sites per symbol to ~<code>1,112,064</code>. 

To put in perspective one can encode 1.2366863e+12 sites with 2 symbols (<code>1,112,064*1,112,064</code>) - in November 2009, shortened links on <code>bit.ly</code> were accessed <code>2.1</code> billion times (<a href="https://en.wikipedia.org/wiki/URL_shortening#History" rel="nofollow noreferrer">Around that time, bit.ly and TinyURL were the most widely used URL-shortening services.</a>) which is ~600 times less than you can fit in just 2 symbols, so for full duration of existence of all url shortening services it should last another 20 years minimum till adding third symbol.

blocks|key|1217672|text|简单地说，URL+shortener将任意长字符序列(原始的、长的、糟糕的url+)映射成短的、圆滑的字符序列。这只是散列，最常用于创建查找表、HashMap、用于加密目的的md5散列等。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1217673|为了理解网址缩短的过程，我在GitHub上创建了一个演示项目和一篇博客文章。一定要参考这篇文章，让我知道它是否有帮助。|1217674|博客帖子：URL+Shortening|offset|length|1217675|entityMap|0|LINK|mutability|MUTABLE|url|http://anandjoshi.me/articles/2016-10/URL-Shortening^0|0|0|5|E|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

In simple words, URL shortener maps an arbitrary long sequence of character ( original, long crappy url ) into a short and slick sequence of characters. This is nothing but Hashing, which is most commonly used to create lookup tables, HashMap, md5 Hash for cryptographic purposes etc.

To understand the URL-Shortening process I have created a demo project on GitHub and also a blog post. Do refer to this and let me know if it was helpful.

Blog Post : <a href="http://anandjoshi.me/articles/2016-10/URL-Shortening" rel="noreferrer">URL Shortening</a>

How do services like <a href="http://tinyurl.com/" rel="noreferrer">TinyURL</a> or <a href="http://metamark.net/" rel="noreferrer">Metamark</a> work? 
Do they simply associate the tiny URL key with a [virtual?] web page which merely provide an "HTTP redirect" to the original URL? or is there more "magic" to it ?

[original wording]
I often use URL shortening services like TinyURL, Metamark, and others, but every time I do, I wonder how these services work. Do they create a new file that will redirect to another page or do they use subdomains?

How do short URLs services work?

数据库

服务器

路由

GitHub

像或这样的服务是如何工作的？它们只是简单地将微小的URL键与一个虚拟的URL键关联起来吗？只提供"HTTP重定向“到原始URL的网页？或者它还有更多的“魔力”？我经常使用网址缩短服务，如TinyURL，Metamark和其他服务，但每次我这样做时，我都想知道这些服务是如何工作的。他们是创建一个重定向到另一个页面的新文件...

问短URL服务是如何工作的？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问短URL服务是如何工作的？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问短URL服务是如何工作的？
EN