Analisador de URL
Decompõe qualquer URL no seu esquema, host, porta, caminho, parâmetros de consulta e hash, analisado localmente no teu navegador.
A carregar Analisador de URL… Se nada acontecer, ativa o JavaScript.
Um URL (Uniform Resource Locator) parece uma única cadeia, mas é na verdade um registo estruturado feito de vários componentes distintos, cada um com o seu próprio significado. Um URL completo como https://user:pass@example.com:8443/path/page?q=hello&lang=en#section reúne um esquema, credenciais opcionais, um host, uma porta opcional, um caminho, uma query string e um fragmento. Ler essas partes a olho é fácil de errar, sobretudo quando a query string é longa, contém caracteres codificados em percentagem ou repete a mesma chave mais do que uma vez. Um analisador divide o URL com precisão segundo as regras definidas no WHATWG URL Standard, as mesmas regras que todos os navegadores modernos seguem.
Perguntas frequentes
O URL que colo é enviado para um servidor?
Quais são as partes de um URL?
Porque é que a porta aparece como predefinida em alguns URL?
Qual é a diferença entre host e hostname?
Como são tratados os parâmetros de consulta repetidos?
Descodifica os caracteres codificados em percentagem nos valores de consulta?
Porque é que recebo um erro de URL inválido?
Consegue analisar esquemas não web como mailto ou ftp?
Sobre Analisador de URL
Esta ferramenta usa as API nativas URL e URLSearchParams integradas no teu navegador, por isso os resultados correspondem exatamente à forma como um navegador, uma chamada fetch ou uma framework de servidor interpretariam o endereço. Mostra o esquema e o protocolo completo, qualquer nome de utilizador e palavra-passe incorporados na autoridade, o host e o hostname, a porta (ou uma nota de que se aplica a predefinida do esquema), o pathname, o origin calculado e o fragmento hash. A query string é separada numa tabela limpa de pares de chave e valor, com cada valor copiável individualmente, o que é muito mais rápido do que procurar por entre um muro de ampersands e sinais de igual.
Tudo corre localmente no teu navegador. O URL que colas nunca é enviado, registado nem transmitido a nenhum servidor, por isso é seguro inspecionar ligações que contenham tokens de acesso, identificadores de sessão, parâmetros assinados ou outros valores de consulta sensíveis. Os programadores recorrem a um analisador de URL ao depurar redirecionamentos, URL de retorno de OAuth, a sopa de parâmetros de rastreio das campanhas de marketing, endpoints de API com muitas opções de consulta ou ligações profundas em apps móveis. Se a entrada não for um URL absoluto válido, a ferramenta mostra um erro claro em vez de adivinhar.
O padrão de URL com que ninguém concordou durante décadas
Os URL foram formalizados pela primeira vez por Tim Berners-Lee no RFC 1738 lá em 1994, mas durante anos depois cada navegador, biblioteca e linguagem analisava-os de forma ligeiramente diferente. Os casos limite como as barras invertidas, os espaços no início e no fim, os dois pontos colocados de forma estranha e a codificação em percentagem no host causavam verdadeiros bugs de segurança, porque um analisador no servidor e um analisador no navegador podiam discordar sobre para que host um URL apontava de facto. Os atacantes exploravam essas divergências para passar para lá das listas de permitidos de URL e desencadear falsificações de pedido do lado do servidor.
Para acabar com o caos, o WHATWG publicou o URL Standard, uma especificação viva que define a análise como uma máquina de estados precisa e não como uma gramática solta. É crucial que a especificação tenha sido escrita para descrever o que os navegadores realmente fazem, incluindo as suas peculiaridades, de modo a que o algoritmo seja interoperável por construção. As classes URL e URLSearchParams expostas ao JavaScript implementam este mesmo algoritmo, que é a razão pela qual a saída desta ferramenta corresponde ao que a barra de endereços do teu navegador e as chamadas fetch veem.
Um detalhe subtil que o padrão fixa com clareza é a diferença entre os esquemas especiais (http, https, ws, wss, ftp, file) e tudo o resto. Os esquemas especiais recebem uma normalização adicional, como pôr o host em minúsculas e resolver a porta predefinida, enquanto os esquemas não especiais são tratados de forma mais literal. Essa distinção explica por que razão um URL https e um URL personalizado myapp com o mesmo texto a seguir aos dois pontos podem ser analisados em valores de componentes bastante diferentes.