Analisador de URL

O URL Parser reconstrói qualquer URL em seus componentes parte de acordo com a especificação RFC 3986, mostrando exatamente como navegadores e clientes HTTP interpretam cada segmento. Cole uma URL como https://www.example.com:8443/api/v2/users?status=active&limit=50#results e veja cada componente extraído: esquema, host, porta, caminho, parâmetros de query e fragmento.

Entendendo Estrutura de URL

URLs são os endereços da web, mas sua estrutura é mais nuançada do que a maioria dos desenvolvedores percebem até que eles enfrentem um caso extremo de análise. Uma URL não é apenas "a coisa que você digita no navegador" -- é um formato precisamente definido especificado em RFC 3986, com regras sobre quais caracteres são permitidos onde, como caracteres especiais devem ser codificados e como cada componente é delimitado do próximo. Acertar esses detalhes errado causa bugs reais: cadeias de redirecionamento quebradas, chamadas de API desviadas para rotas erradas, vulnerabilidades de segurança por confusão de URL e falhas de rastreamento de analytics por perda de parâmetros de query.

A estrutura básica de uma URL é esquema://userinfo@host:porta/caminho?query#fragmento, mas a maioria de URLs omite vários desses componentes. O esquema diz ao cliente qual protocolo usar (http, https, ftp). O host identifica o servidor, como um nome de domínio ou um endereço IP. A porta é geralmente implícita -- 443 para HTTPS, 80 para HTTP -- mas pode ser especificada explicitamente quando um serviço roda em uma porta não-padrão. O caminho identifica o recurso específico naquele servidor. A string de query carrega parâmetros como pares chave-valor. E o fragmento aponta para uma seção específica dentro do recurso, processado inteiramente pelo cliente e nunca enviado ao servidor.

O que confunde as pessoas são os casos extremos. Uma URL pode conter credenciais (user:password@host), embora isso seja deprecado para HTTP. Endereços IPv6 devem estar entre colchetes ([2001:db8::1]). Valores de parâmetro de query podem eles mesmos conter ? e = caracteres se eles forem percent-encoded. O primeiro ? separa caminho de query, mas ? caracteres subsequentes são partes literais da query. Este parser manipula todos esses casos e exibe cada componente separadamente, tornando a estrutura da URL inequívoca.

Como Analisar uma URL em Componentes

1. Cole qualquer URL completa no campo de entrada
2. O parser extrai cada componente: esquema, userinfo, host, porta, caminho, query, fragmento
3. Strings de query são adicionalmente desfeitas em pares de parâmetro individuais de chave-valor
4. Portas padrão são identificadas com base no esquema (ex: 443 para https)
5. Qualquer problema de codificação ou construções não-padrão são destacados

Exemplos de Análise de URL

URL HTTPS Padrão

Entrada: https://www.example.com:8443/api/v2/users?status=active&limit=50#results

Parâmetros de Query:

URL com Autenticação

Entrada: ftp://admin:[email protected]/pub/reports/2024/

URL com Host IPv6

Entrada: http://[2001:db8::1]:8080/index.html

String de Query Complexa

Entrada: https://search.example.com/results?q=url+encoding&lang=en&page=3&sort=relevance

Parâmetros de Query:

Quando Usar o URL Parser

• Depuração de cadeias de redirecionamento para inspecionar cada URL na sequência e identificar onde os parâmetros são perdidos ou modificados
• Análise de URLs de callback OAuth para verificar URIs de redirecionamento, parâmetros de estado e códigos de autorização
• Extração de parâmetros de query de URLs longas em payloads de webhook, links de rastreamento de analytics ou respostas de API
• Inspeção de deep links em aplicações móveis para entender roteamento e passagem de parâmetro
• Análise de segurança de URLs potencialmente maliciosas para identificar ofuscação no host, caminho ou componentes de query
• Comparação de URLs para determinar se duas URLs que parecem diferentes realmente apontam para o mesmo recurso

Como Funciona a Estrutura de URL (RFC 3986)

A Anatomia de URL

Uma URL segue essa estrutura geral:

esquema://userinfo@host:porta/caminho?query#fragmento

Cada componente serve um propósito específico:

• Esquema -- identifica o protocolo (http, https, ftp, ssh, mailto)
• Userinfo -- credenciais opcionais (user:password@), deprecado para HTTP/HTTPS
• Host -- nome de domínio (example.com) ou endereço IP (192.0.2.1 ou [2001:db8::1])
• Porta -- número de porta TCP opcional; padrões dependem do esquema (80 para HTTP, 443 para HTTPS)
• Caminho -- identificador de recurso hierárquico (/api/v2/users)
• Query -- parâmetros de chave-valor depois de ?, separados por & (status=active&limit=50)
• Fragmento -- âncora do lado do cliente depois de #, não enviada para o servidor (#section-2)

Percent Encoding

Caracteres especiais em URLs devem ser percent-encoded usando % seguido de dois dígitos hexadecimais. Codificações comuns:

Portas Padrão por Esquema

Quando a porta padrão é usada, ela é tipicamente omitida da URL. O parser identifica ambas as portas explícitas e implícitas.

Análise de URL na Prática

A razão mais comum para desenvolvedores recorrerem a um parser de URL é depuração. Você está olhando para uma cadeia de redirecionamento e a URL final está faltando um parâmetro de query que estava presente no original. O parâmetro foi deixado por um redirecionamento? Foi renomeado? Foi absorvido no caminho? Analisar cada URL na cadeia lado a lado revela exatamente aonde o parâmetro desapareceu. Isso é especialmente comum em fluxos OAuth, onde URIs de redirecionamento carregam parâmetros de estado, códigos de autorização e valores de scope que devem sobreviver múltiplos redirecionamentos intactos.

Outro caso de uso frequente é trabalho de integração de API. Quando você recebe um payload de webhook ou uma URL de callback de um serviço de terceiros, você precisa extrair parâmetros de query específicos para processar o evento. A URL pode estar profundamente aninhada em uma resposta JSON, URL-encoded dentro de outra URL, ou truncada em um arquivo de log. Analisá-la em componentes fornece acesso limpo a cada parâmetro sem divisão manual de string que quebra em casos extremos como caracteres & codificados dentro de valores de parâmetro.

Para análise de segurança, análise de URL revela técnicas de ofuscação que são invisíveis quando olhando para a URL bruta. Um atacante pode usar um caractere @ codificado (%40) para fazer uma URL parecer apontar para um domínio confiável quando ela realmente se autentica em um malicioso. Ou eles podem usar separadores de caminho codificados para contornar controles de acesso baseados em caminho. Analisar a URL com um parser compatível com padrões mostra a estrutura verdadeira depois de decodificação, tornando essas técnicas visíveis.

Perguntas Frequentes

Por que o fragmento não é enviado para o servidor?

O identificador de fragmento (tudo depois de #) é processado inteiramente pelo cliente (navegador). Ele é removido da URL antes da requisição HTTP ser feita. O servidor nunca vê o fragmento. Isso é definido em RFC 3986 e é usado para navegação do lado do cliente dentro de uma página, roteamento de aplicação de página única e links de âncora.

Como o parser manipula URLs com múltiplos ? ou # caracteres?

Per RFC 3986, apenas o primeiro ? separa o caminho da query, e apenas o primeiro # (depois da query) separa a query do fragmento. Caracteres ? adicionais dentro da query são tratados como caracteres literais. Caracteres # adicionais dentro do fragmento são também literais. O parser segue esse comportamento padrão.

O parser pode manipular nomes de domínio internacionalizados (IDN)?

Sim. Nomes de domínio internacionalizados como beispiel.de (com umlauts ou caracteres não-ASCII) são exibidos como-está e o parser também mostra a codificação Punycode (ex: xn--bsp-jma.example.com) que é usada na busca de DNS real.

Qual é a diferença entre %20 e + para espaços?

Ambos representam um caractere de espaço, mas são usados em contextos diferentes. %20 é a percent-encoding padrão para um espaço e é válido em qualquer lugar em uma URL. A codificação + para espaços é específica para o formato application/x-www-form-urlencoded usado em submissões de formulário HTML e strings de query. No componente de caminho, + é um sinal de mais literal, não um espaço. O parser manipula ambas as codificações corretamente com base em seu contexto.

Como digo se duas URLs diferentes apontam para o mesmo recurso?

Analise ambas as URLs e compare seus componentes. URLs que diferem apenas em porta padrão (ex: http://example.com vs http://example.com:80), slashes à direita, ordem de parâmetro de query ou diferenças de codificação podem se resolver para o mesmo recurso. Use o URL Normalizer para canonicalizar URLs antes da comparação.

Por que minha URL se analisa diferentemente em diferentes linguagens de programação?

Diferentes bibliotecas de análise de URL podem manipular casos extremos diferentemente. urllib.parse de Python, o construtor URL de JavaScript e net/url de Go geralmente seguem RFC 3986 mas podem divergir em URLs malformadas, referências relativas ou padrões de codificação inusitados. Este parser segue a especificação RFC 3986 estritamente e é útil como implementação de referência para comparar contra o parser da sua linguagem.

Ferramentas Relacionadas

• URL Normalizer - Normalize URLs removendo padrões e ordenando params
• Query String Parser/Builder - Analise e construa strings de query de URL
• Port Validator - Valide números de porta (0-65535)
• HTTP Header Formatter - Converta entre formatos bruto e chave/valor de header
• Bulk Add/Remove Query Params - Adicione ou remova parâmetros de query de múltiplas URLs