Analisador/Construtor de String de Consulta

O Query String Parser/Builder converte entre strings de query de URL e pares de chave-valor estruturados, manipulando URL encoding, objetos aninhados, notação de array, e chaves duplicadas corretamente em ambas direções. Cole uma string de query como ?user[name]=alice&colors[]=red&colors[]=blue&q=hello+world e obtenha uma tabela limpa de parâmetros decodificados, ou insira pares chave-valor e obtenha uma string de query adequadamente codificada pronta para anexar a qualquer URL.

Entendendo Strings de Query de URL

Strings de query são a parte de uma URL que vem depois do caractere ?, e são uma das formas mais comuns de passar dados em aplicações web. Toda vez que você filtra uma lista de produto, submete um formulário de busca, ou clica em um link paginado, os parâmetros viajam como pares chave-valor na string de query. Eles parecem simples na superfície -- apenas pares key=value juntados por & -- mas as regras de codificação, convenções de array, e casos extremos os tornam surpreendentemente complicados de trabalhar à mão.

O problema central é que URLs têm um conjunto de caracteres restrito. Espaços, ampersands, sinais de igual, e a maioria de caracteres não-ASCII não podem aparecer literalmente em uma string de query porque têm significado especial ou não são válidos em URIs. O padrão de codificação application/x-www-form-urlencoded manipula isto substituindo caracteres inseguros com sequências percent-encoded (%20 para um espaço) ou o atalho + para espaços. Quando você vê q=hello+world ou q=hello%20world em uma URL, ambos significam o termo de busca é "hello world" -- mas saber qual codificação esperar depende do contexto.

No topo da codificação básica, diferentes frameworks de servidor inventaram convenções concorrentes para passar dados estruturados como arrays e objetos aninhados. PHP e Rails usam notação de bracket (colors[]=red&colors[]=blue), Java e Go usam chaves repetidas (colors=red&colors=blue), e alguns frameworks suportam notação de ponto (user.address.city=NYC). Esta ferramenta reconhece todas essas convenções e te mostra exatamente que estrutura o servidor receberia, tornando-a inestimável para depuração de chamadas de API e payloads de webhook onde problemas de codificação de parâmetro são uma fonte frequente de bugs.

Como Parse uma String de Query

1. Cole a string de query no campo de entrada (com ou sem o ? líder).
2. Clique Parse para extrair todos os parâmetros em uma tabela estruturada.
3. Revise o valor decodificado de cada parâmetro junto com sua forma codificada original.
4. Edite valores individuais ou copie a saída estruturada para uso em seu código.

Como Construir uma String de Query

1. Insira pares chave-valor como JSON, um-por-linha (key=value), ou formato de dados de formulário.
2. Selecione opções de codificação (ordene parâmetros, padrão de codificação).
3. Clique Construir para gerar uma string de query adequadamente codificada.
4. Copie o resultado e anexe a sua URL base.

Exemplos de Parse de String de Query

Quando Usar o Query String Parser/Builder

• Depuração de fluxos OAuth -- Extrair e inspecionar state, code, redirect_uri, e parâmetros de token de URLs de callback.
• Construção de requisições de API -- Construir strings de query adequadamente codificadas para APIs REST com filtros, paginação, e parâmetros de ordenação.
• Análise de links de marketing -- Quebrar parâmetros de rastreamento UTM e identificadores de campanha de URLs compartilhadas.
• Depuração de webhook -- Parse URLs de callback de webhook recebidas para entender que parâmetros o serviço está enviando.
• Inspeção de dados de formulário -- Decodificar dados de corpo POST application/x-www-form-urlencoded que usa formato de string de query.
• Teste de migração -- Verificar que rewrites de URL e regras de redirect preservam parâmetros de query corretamente durante migrações de site.

Como Funciona URL Query String Encoding

Strings de query seguem o padrão de codificação application/x-www-form-urlencoded, que constrói em cima de percent-encoding da RFC 3986.

Regras de Percent-Encoding

Caracteres que não são seguros em URLs são substituídos com % seguido por seu código hex de dois dígitos:

Notação de Array e Objeto Aninhado

Diferentes frameworks usam diferentes convenções para arrays e objetos em strings de query:

• Notação de bracket: colors[]=red&colors[]=blue (PHP, Rails)
• Notação indexada: colors[0]=red&colors[1]=blue (ordenação explícita)
• Chaves repetidas: colors=red&colors=blue (Java, Go)
• Objetos aninhados: user[address][city]=NYC (aninhamento profundo)
• Notação de ponto: user.address.city=NYC (alguns frameworks Java)

Armadilhas Comuns de Codificação

Um bug frequente em strings de query feitas à mão é codificação dupla. Se você codifica um valor que já está codificado, %20 torna-se %2520 (o % em si fica codificado), e o servidor recebe uma string literal %20 em vez de um espaço. O parser detecta e sinaliza possível codificação dupla para que você possa notar esses problemas imediatamente.

Dicas Práticas para Trabalhar com Strings de Query

Um dos erros mais comuns que desenvolvedores cometem é construir strings de query através de concatenação de string em vez de usar um builder de URL adequado. Parece rápido escrever url + "?key=" + value, mas no momento que value contém um ampersand, um espaço, ou um caractere Unicode, a URL resultante é malformada. Toda linguagem maior tem um builder de URL ou string de query construído -- URLSearchParams em JavaScript, urllib.parse.urlencode em Python, http_build_query em PHP -- e você deve sempre usá-los.

Ao depurar chamadas de API, preste atenção à diferença entre + e %20 para espaços. Ambos são válidos em strings de query sob o padrão application/x-www-form-urlencoded, mas se comportam diferentemente em segmentos de caminho. Um + em um caminho de URL é um sinal de mais literal, não um espaço. Se seu endpoint de API recebe search/hello+world no caminho em vez da string de query, não é um espaço -- é hello+world. Esta distinção causa bugs sutis ao mover parâmetros entre o caminho e string de query.

Se você está trabalhando com URLs de callback OAuth, sempre parse a string de query em vez de usar regex ou divisão de string. Callbacks OAuth podem conter tokens codificados em base64 como valores de parâmetro, e esses tokens podem incluir caracteres como = e + que quebram parsing ingênuo. Um parser de string de query adequado manipula a codificação corretamente e te salva de bugs de autenticação que aparecem apenas com certos valores de token.

Perguntas Frequentes

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

Na codificação application/x-www-form-urlencoded (formulários HTML), espaços são codificados como +. Na percent-encoding padrão (RFC 3986), espaços são %20. A maioria dos servidores aceita ambos em strings de query, mas %20 é tecnicamente correto em segmentos de caminho onde + é um sinal de mais literal.

Como manipulo chaves duplicadas em uma string de query?

O comportamento depende do seu framework de servidor. A maioria dos frameworks (Express.js, Django, Rails) coleta chaves duplicadas em um array. Alguns mantêm apenas o primeiro ou último valor. O parser mostra todas as ocorrências para que você possa ver exatamente o que foi enviado.

A ordem de parâmetro importa em strings de query?

Tecnicamente, a ordem de string de query é significante per a spec HTTP. Na prática, a maioria dos servidores ignora ordem. Se você precisa strings consistentes para caching ou comparação, use a opção de ordenação ao construir.

Qual é o comprimento máximo de uma string de query?

Não há limite duro na especificação HTTP, mas browsers e servidores impõem limites práticos. A maioria dos browsers suporta URLs até cerca de 2.000 caracteres totais. Servidores web como Apache padrão para 8.190 bytes para a linha de requisição inteira (método + URL + versão HTTP). Se você está se aproximando desses limites, considere mover parâmetros para o corpo de requisição usando POST em vez de GET.

Como passo dados JSON em uma string de query?

Você pode codificar uma string JSON inteira como um valor de parâmetro único: ?data=%7B%22key%22%3A%22value%22%7D. No entanto, isto é frágil e difícil de depurar. Para dados complexos, é melhor usar uma requisição POST com um corpo JSON. Se você deve usar GET, achate o JSON em parâmetros individuais (?key=value&nested.field=data).

Nomes de parâmetro de string de query podem conter caracteres especiais?

Sim, mas eles devem ser percent-encoded. Um parâmetro nomeado user[name] é enviado como user%5Bname%5D=value na URL bruta. A maioria dos frameworks decodifica isto automaticamente. O parser mostra tanto as formas codificadas quando decodificadas.

Ferramentas Relacionadas

• URL Parser - Parse URLs completas em componentes scheme, host, porta, caminho e query
• URL Normalizer - Normalizar URLs ordenando parâmetros e removendo padrões
• Bulk Add/Remove Query Params - Adicionar ou remover parâmetros de query de múltiplas URLs de uma vez
• Cookie Header Parser - Parse headers Cookie e Set-Cookie que frequentemente acompanham requisições baseadas em query
• curl Command Builder - Construir comandos curl com parâmetros de query adequadamente codificados