Pular para o conteúdo principal
ToolsByUs

JSON para string de consulta

Este conversor codifica um objeto JSON como uma string de query URL no seu navegador. Objetos aninhados usam a convenção de colchetes a[b]=c, arrays repetem a chave, valores são codificados porcentualmente conforme RFC 3986 com espaços como %20, e null se torna uma chave com valor vazio. Nada é enviado.

Só local

JSON para string de consulta: explicação

Todo objeto JSON que já viajou como parâmetros de requisição GET foi achatado em uma única linha de pares chave=valor, e o achatamento envolveu escolhas: como aninhamento é escrito, como arrays repetem, o que acontece com null. Este conversor torna essas escolhas explícitas e convencionais — objetos aninham como a[b]=c, arrays repetem a chave, e o resultado é uma linha codificada porcentualmente, pronta para ser colada após um ?.

Nenhuma dessas convenções foi inventada aqui. O estilo de colchetes é o emitido pelo http_build_query do PHP e pelo Ruby on Rails por duas décadas, e todo analisador sério de query-string lê de volta para a estrutura. A codificação segue RFC 3986: caracteres não reservados permanecem legíveis, espaços se tornam %20, e um sinal de mais literal se torna %2B para sobreviver tanto a analisadores em modo de formulário quanto a analisadores estritos.

Como em todo este site, o trabalho acontece na aba que abriu a página: seu JSON é analisado e codificado pelo código da página, e nada cruza a rede. O Content-Security-Policy proíbe conexões de saída completamente, então o painel Network do DevTools permanecendo vazio enquanto você converte é toda a garantia de privacidade, demonstrada em vez de apenas afirmada.

A string que esta página constrói é exatamente o que o conversor irmão do site pode decodificar de volta para JSON então uma ida e volta é uma boa verificação de sanidade antes de enviar a URL.

Se você só precisa escapar um único valor em vez de estruturar um objeto inteiro, o codificador e decodificador de URL lida com uma string de cada vez sob as mesmas regras RFC 3986.

Como a codificação na verdade funciona

O conversor percorre o objeto analisado em ordem de chaves e emite um par por elemento, unidos com &. Cada valor é transformado em string antes da codificação — números como dígitos simples, booleanos como true ou false, null como um valor vazio — e depois codificado porcentualmente como UTF-8. As regras de estrutura são:

  • Objetos: um objeto aninhado estende o caminho da chave com colchetes. {"user": {"name": "Ada"}} se torna user[name]=Ada, e um nível mais profundo anexa outro grupo de colchetes: user[address][city]=London.
  • Arrays: um array de escalares repete a chave uma vez por elemento — tag=navy&tag=math — o estilo que o Rack e o analisador qs do Node leem de volta para arrays.
  • null: se torna uma chave com valor vazio (token=), o que mantém a chave presente na URL em vez de descartá-la.
  • Objetos e arrays vazios: não emitem nada para aquela chave, pois não há par para escrever; a ausência da chave é reportada na visualização para que seja uma decisão, não uma surpresa.

Codificação percentual, estilo RFC 3986

A RFC 3986 mantém o conjunto não reservado — A–Z, a–z, 0–9, hífen, ponto, underscore e tilde — exatamente como escrito e exige que tudo o mais seja codificado porcentualmente byte a byte como UTF-8. Um espaço é %20, não +. O hábito de usar sinal de mais para espaço pertence a application/x-www-form-urlencoded, uma convenção de formulário mais antiga que ainda causa bugs reais: um leitor estrito RFC 3986 decodifica um + literal como um sinal de mais. Emitir %20 para espaços e %2B para sinais de mais significa que a saída significa a mesma coisa para ambos os tipos de leitores.

Uma exceção deliberada: os colchetes nas chaves são emitidos literalmente, porque essa é a aparência da convenção a[b]=c na natureza — PHP e Rails também não os escapam. Colchetes são estrutura, não conteúdo. Valores são codificados estritamente, e o decodificador reverso neste site aceita tanto colchetes literais quanto escapados como %5B/%5D.

Como a saída se parece

O exemplo abaixo é o par exato que o botão “Carregar exemplo” produz: parâmetros de pesquisa com um objeto user aninhado, uma chave tag repetida e um token null. A ordem das chaves segue o documento JSON, então re-codificar uma string re-analisada é estável — o mesmo objeto sempre produz a mesma URL, o que importa quando você está comparando links, fazendo cache ou escrevendo testes com eles.

Casos extremos que este conversor recusa em vez de distorcer

Dois formatos não têm codificação honesta sob essas convenções, e ambos são rejeitados com um erro nomeado em vez de um palpite:

  • Um array de nível superior — uma string de query não tem espaço sem chave. Envolver o array em um objeto sob uma chave, e a convenção de repetição faz o resto.
  • Arrays de objetos — tag[name]=a&tag[name]=b colapsaria dois registros em um caminho de chave, e inventar índices como tag[0][name] adiciona estrutura que você nunca pediu. O conversor recusa e nomeia a chave ofensora.

Perguntas frequentes

Converter JSON para uma string de query envia meus dados para algum lugar?

Não. O JSON é analisado e codificado inteiramente dentro desta aba do navegador; a página não tem endpoint de envio, e seu Content-Security-Policy proíbe conexões para qualquer outro lugar, então a exfiltração é estruturalmente impossível em vez de apenas prometida. Verifique em trinta segundos: abra o DevTools, mude para o painel Network, converta e veja nenhuma requisição aparecer.

Por que um espaço é codificado como %20 e não como +?

Porque o sinal-de-mais-para-espaço é a convenção application/x-www-form-urlencoded, enquanto a RFC 3986 — a gramática URI em si — requer %20 e trata um + literal como um sinal de mais. Codificar %20 e %2B significa de forma inequívoca que analisadores em modo de formulário e estritos decodificam seu valor identicamente. Navegadores são tolerantes de qualquer forma; o risco está no leitor estrito em uma URL assinada ou uma camada de cache, que é exatamente onde a ambiguidade é cara.

Por que o aninhamento usa a notação a[b]=c?

É o padrão de fato de colchetes, emitido pelo http_build_query do PHP e pelo Ruby on Rails por duas décadas e analisado de volta para estrutura aninhada por bibliotecas como qs (Node) e Rack (Ruby). Alternativas existem — pontos, dois-pontos, chaves profundas repetidas — mas nenhuma tem suporte de leitores sequer próximo, e um formato de intercâmbio deve otimizar para a maior audiência.

Como arrays são codificados, e por que não há a notação tag[]?

Arrays de escalares repetem a chave: tag=navy&tag=math. Servidores como o Rack e o qs do Node coletam chaves repetidas em arrays na análise, então a ida e volta é limpa. A exceção é o PHP, que precisa de tag[] para construir um array — uma notação que este conversor nunca emite, porque colchetes são reservados para aninhamento de objetos aqui. Se o PHP for o destino, anexe os colchetes vazios na chave após converter.

O que null, booleanos e números se tornam?

null se torna uma chave com valor vazio — token= — o que mantém a chave presente na URL. Booleanos se tornam o texto literal true ou false, e números se tornam dígitos decimais simples sem formatação de locale e sem separadores de milhares. A string vazia também se torna um valor vazio; uma string de query não pode distinguir de null, e o decodificador reverso lê um valor vazio de volta como null por design.

Quais caracteres são deixados sem codificação?

Exatamente o conjunto não reservado da RFC 3986: A–Z, a–z, 0–9, hífen, ponto, underscore e tilde. Tudo o mais — espaços, e-comerciais, barras, letras acentuadas, emoji — é codificado byte a byte como UTF-8. Os colchetes nas chaves são a única exceção visível, emitidos literalmente porque são a própria convenção de aninhamento; valores nunca recebem esse tratamento.

Equipe ToolsByUs · Como verificamos nossas ferramentas