Quase todo mundo já deve ter esbarrado (e se perguntado sobre o que são) umas URLs estranhas com domínios mais estranhos ainda, como por exemplo: bit.ly/7XC3Lo, migre.me/ck3k, tinyurl.com/yge8jzg, j.mp/7XC3Lo e zapt.in/k. A maior parte do mistério é esclarecida quando clicamos num link destes e somos redirecionados para um outro site. Tratam-se de URLs encurtadas através de algum serviço de encurtamento de URLs (Wikipedia: URL shortening).
Bom, mas pra que precisamos disto. Afinal os browsers evoluíram para aceitar URLs de tamanhos gigantescos (não existe um consenso quanto ao tamanho máximo de uma URL, mas elas podem passar dos milhares de caracteres na maioria dos browsers e web servers). Na realidade existem várias utilidades para estes encurtadores de URL como facilitar a digitação e a verbalização de URLs (é melhor usar/ditar/digitar uma dezena de caracteres do que milhares de caracteres), permitir que URLs grandes fossem compartilhadas em mensagens SMS (imagine passar a URL toda deste post numa mensagem de texto) ou até mesmo fazer o tracking de clicks/visualizações de um determinado link. Mas a coisa decolou mesmo foi com a popularização do Twitter, que permite apenas mensagem com no máximo 140 caracteres. Ou seja, qualquer caractere é valioso ao se compartilhar um link em um tweet. Fica claro que na hora de compartilhar aquele link do torrent do Ubuntu 9.10 no Twitter é melhor usar a URL encurtada http://zapt.in/m com apenas 16 caracteres do que a original http://releases.ubuntu.com/9.10/ubuntu-9.10-alternate-i386.iso.torrent com 70 (e olha que esta é relativamente curta).
Bom, na prática (pelo que vi até o momento), nenhum “encurtador” de URL faz realmente a compressão da URL. Entendendo como compressão de dados a utilização de algoritmos como o Lempel-Ziv (LZW – utilizado no winzip, gzip, etc) ou o Run Length Encoding (RLE – utilizado em máquinas de fax).
O que eles fazem, em geral, é construir uma função bijetora que leva cada URL longa para uma URL ou chave menor (e vice-versa), tentando minimizar ao máximo o espaço necessário para esta nova URL ou chave. Existem variações quanto aos modelos de funções de mapeamento utilizadas (algumas não sendo de fato bijetoras) e também em como as URLs menores ou chaves são geradas.
Para a geração das chaves, muitas vezes se utiliza um hash único calculado aleatoriamente (para evitar que se possa prever as sequências) ou mesmo uma chave calculada através da transformação de um número sequêncial (cada URL encurtada incrementa a sequência) utilizando uma base de representação maior do que a decimal. A idéia é utilizar menos posições (caracteres) para representar o mesmo número (índice). Por exemplo:
Observe que para representar o mesmo número, podemos entre 17 e 3 caracteres (somente com os exemplos de representações utilizados no exemplo).
Me parece que o Migre.Me utiliza Base 62 e um índice sequencial de URLs, já o Bit.Ly parece usar Base 62, mas com algum esquema de sequenciamento estranho (talvez ele use algum particionamento do espaço a partir da URL original).
Bom, depois de mapear a URL original para uma encurtada, e armazenar isto num banco de dados, o que o “encurtador de URLs” faz é redirecionar um visitante que segue a URL encurtada para a URL original. De preferência os serviços utilizam o redirecionamento do tipo permanente (HTTP 301 – Permanent Redirect), já que este tipo de redirecionamento preserva as características da página destino para fins de web crawling, SEO, rankings, etc. Digamos que ele é o tipo de redirecionamento mais amigável com os motores de busca.
O interessante é que entre receber a requisição na URL encurtada e redirecionar o visitante para a URL original, o encurtador pode capturar vários tipos de estatísticas para aquele link. Ele pode contar quantas vezes o link foi clicado, qual o tipo de browser que foi utilizado, etc. Isto torna os serviços ainda mais úteis, podendo ser utilizados para medir taxas de conversão de clicks, eficiência de campanhas online, concursos e outros.
Bom, a idéia do Zapt.In nasceu há alguns meses quando este tipo de serviço começou a explodir pela rede: o Brasil ainda não tinha um encurtador de URL decentes – Leia-se: o Jonny Ken ainda não havia criado o Migre.Me
, eu trocava várias ideias sobre as possibilidades de um serviço destes associado ao BlogBlogs e o LiveStream com Manoel Netto e eu acabei me esbarrado em alguns domínios interessantes (bem curtos) como foi o caso do ZAPT.IN. Acontece que o tempo passou, muita coisa aconteceu e nunca rolou de fazermos o tal encurtado.
Mas como para tudo chega a sua hora, neste feriado (última semana) aconteceu o alinhamento planetário perfeito: a Isabella passou a semana em Uberaba, as coisas estavam mais tranquilas no trabalho e, no final de semana prolongado, minha mãe e irmã vieram para Sampa e passaram grande parte dos dias caminhando pelos shoppings e ruas do centro (com a Isa que já havia retornado), deixando o viciado em codar (eu mesmo) livre para criar, hehe. Amo muito tudo isto!!!
Bom, ai foi a hora de arregaçar as mangas, abrir o TextMate e começar a codar. Com algumas boas horas de coding e pesquisa consegui colocar a primeira versão (bem tabajara, mas lembrando que ‘shipping is a feature‘) para rodar na plataforma de Cloud Computing da Heroku. Na realidade passei mais tempo estudando algumas coisas (algoritmos, Heroku, Git, etc) do que codando, mas na hora de mandar brasa no “POG” e escrever o Zapt.In a coisa andou bem rapidamente.
É isto, agora o Zapt.In está no ar em versão nem-alpha-ainda. Claro, cheio de bugs, sem logo, sem layout, com poucas funcionalidades e sem a menor preocupação, ainda, com escalabilidade. Mas um dia ele chegará lá, para isto preciso da ajuda de vocês (para usarem, testarem e enviarem suas ideias).
Esta é uma boa pergunta. O Brasil já tem o Migre.Me e existe mais de uma centena de serviços parecidos por ai. Então por que?
Ué, porque é divertido!
Porque serviços como o BlogBlogs e vários outros nasceram assim. Porque não?
É isto, depois escreverei alguns posts sobre os desafios, os perrengues e as aventuras de colocar mais uma aplicação no ar. HeyHo!!!!
HugoVisitor
Pois é, essa opção de manter sequencial não é muito bom.
No zapt.in criei uma URL apontando para a propria URL:
http://zapt.in/r
eu acharia legal ter algum tipo de informacao na propria url, tipo: zapt.in/v/x e o v indica que é um video… por exemplo. Qualquer coisa q ajude o usuário a saber sobre o q é a url
Uma coisa legal do bit.ly é poder escolher sua própria url.
Helder RibeiroVisitor
Uai, fui lendo, lendo, o post acabou e você não falou que base (ou função de compressão) está usando no zapt.in! Na verdade acho que não existe nada mais comprimido do que usar um número sequencial com a url de verdade armazenada no BD né (comprimir o texto da URL não bate isso nem a pau). O máximo que se pode fazer é aumentar a base, mas aí esbarramos nos 62 caracteres. Se bem que dá pra arrancar um pouco de base usando ‘.’, ‘,’ e talvez outros caracteres especiais que dispensam encoding. Teria que consultar a especificação da URL. Já tentou isso?
mlemosAuthor
Olá Helder, valeu pelos comentários. Todos muito interessantes. No Zapt.In fui pragmático e sempre buscando a solução mais simples, usei uma sequência e Base62. Você já deu um look em nossa API? Já está disponível…
Helder RibeiroVisitor
Também não vejo problema em se poder prever a sequência. Detecção de loops não é difícil, aí é só remover a URL infratora e liberar o espaço pra próxima.
Helder RibeiroVisitor
Da Wikipedia (http://en.wikipedia.org/wiki/Percent-encoding#Types_of_URI_characters):
RFC 3986 section 2.3 Unreserved Characters (January 2005)
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 - _ . ~
Então teoricamente dá pra fazer base 66. Talvez um desses caracteres não possa vir direto depois do ‘/’ (parece que o ‘.’ é assim), mas aí dá pra usar depois da primeira letra. Ainda dá pra ganhar um espaço.
Esse é um problema interessante, pq dá pra ver que os links do bit.ly estão ficando cada vez maiores, e não te muito o que se fazer a respeito. Talvez o esquema é comprar _domínios_ com um prefixo mínimo + strings em base 62. Aí usa o domínio principal (só com o prefixo) pra hospedar a página que gera URLs, e alterna esse e os outros domínios no gerador. Rola uma diluição de marca, mas… There’s no free lunch.
Renato AlbanoVisitor
Lemos, nesse post do Simon Willison rolou uma discussão legal sobre encurtadores de url:
http://simonwillison.net/2009/Apr/11/revcanonical/
[...] no último post falei de um novo projeto que coloquei no ar, o Zapt.In, um encurtador de URLs brazuca (sim, mais um, hehe). E nos últimos dias liberei algumas novas funcionalidades no Zapt.In. A mais [...]
RicardoVisitor
um q utilizo e curto mto é o http://iref.ws
ele vai na contramão daqueles poluídos encurtadores q existem por aí.. além do nome sugestivo (lembra href), ele foi desenvolvido por brasileiros e possui traduções para o inglês e espanhol.. vale a pena conferir!
MatheusVisitor
Em qual linguagem foi feito o código do encurtador ? Eu sempre quis saber se era PHP ou algo parecido, mas não achei nada na internet.
Fabiano CruzVisitor
Concordo contigo que pelo fato de existir alguns não deixar de fazer o que gosta e acredita.
Gostaria de conversar mais contigo sobre Zapt.In. Se puder, seria muito bom. Abs
RaulVisitor
Muito interessante o seu trabalho com http://zapt.in, mas … Você acha que fazer algo com o abuso? Não se preocupado com a má reputação que está ganhando http://zapt.in devido ao abuso de ciber-criminosos?
Deve eliminar esses abusos e facilitar denúncias:
zapt.in/q3c <- link para baixar malware
zapt.in/q3e <- link para baixar malware
zapt.in/q3d <- link para baixar malware
Para aqueles de nós fora do Brasil, os criminosos parecem estar associados a esses serviços como zapt.in. Espero que não, e levar o assunto a sério.
adminAuthor
Olá Raul, acabei de responder seu comentário.
xzibitVisitor
http://nanourl.us/
O melhor
muito bom este mesmo
permite url personalizado
RaulVisitor
Manoel:
Os ladrões estão usando o seu encurtamento. Olha só:
http://zapt.in/qH8
http://zapt.in/qFd
Vai tolerar o abuso?
adminAuthor
Raul, implementamos vários mecanismos de proteção compra uso indevido e abuso. O problema é que não tem como ser 100% eficiente. Basicamente funcionamos assim:
1. ao encurtar uma nova URL ela é verificada contra vários serviços de “blacklist” – se for identificada como uma URL ruim ela não é encurtada.
2. porém estes serviços nem sempre estão atualizados, leva um tempo entre um “abuser” ser listado nos “blacklists” – ai rodamos um processo em background de hora em hora e depois diariamente na base toda verificando todas as URLs novamente e removendo as que foram identificadas como abuso.
Isto melhorou muito o serviço.