Analizador/Constructor de Query String

El Query String Parser/Builder convierte entre query strings de URL y pares clave-valor estructurados, manejando URL encoding, objetos anidados, notación de arrays y claves duplicadas correctamente en ambas direcciones. Pega un query string como ?user[name]=alice&colors[]=red&colors[]=blue&q=hello+world y obtén una tabla limpia de parámetros decodificados, o ingresa pares clave-valor y obtén un query string correctamente codificado listo para agregar a cualquier URL.

Entendiendo los query strings de URL

Los query strings son la parte de una URL que viene después del carácter ?, y son una de las formas más comunes de pasar datos en aplicaciones web. Cada vez que filtras una lista de productos, envías un formulario de búsqueda o haces clic en un enlace paginado, los parámetros viajan como pares clave-valor en el query string. Se ven simples en la superficie -- solo pares key=value unidos por & -- pero las reglas de codificación, las convenciones de arrays y los casos límite los hacen sorprendentemente difíciles de manejar a mano.

El problema central es que las URLs tienen un conjunto de caracteres restringido. Los espacios, ampersands, signos de igual y la mayoría de los caracteres no ASCII no pueden aparecer literalmente en un query string porque tienen significado especial o no son válidos en URIs. El estándar de codificación application/x-www-form-urlencoded maneja esto reemplazando los caracteres no seguros con secuencias percent-encoded (%20 para un espacio) o la abreviatura + para espacios. Cuando ves q=hello+world o q=hello%20world en una URL, ambos significan que el término de búsqueda es "hello world" -- pero saber qué codificación esperar depende del contexto.

Además de la codificación básica, diferentes frameworks de servidor han inventado convenciones competidoras para pasar datos estructurados como arrays y objetos anidados. PHP y Rails usan notación de corchetes (colors[]=red&colors[]=blue), Java y Go usan claves repetidas (colors=red&colors=blue), y algunos frameworks soportan notación de punto (user.address.city=NYC). Esta herramienta reconoce todas estas convenciones y te muestra exactamente qué estructura recibiría el servidor, haciéndola invaluable para depurar llamadas API y payloads de webhooks donde los problemas de codificación de parámetros son una fuente frecuente de bugs.

Cómo analizar un query string

1. Pega el query string en el campo de entrada (con o sin el ? inicial).
2. Haz clic en Parse para extraer todos los parámetros en una tabla estructurada.
3. Revisa el valor decodificado de cada parámetro junto a su forma codificada original.
4. Edita valores individuales o copia la salida estructurada para usar en tu código.

Cómo construir un query string

1. Ingresa pares clave-valor como JSON, uno por línea (key=value), o formato de datos de formulario.
2. Selecciona opciones de codificación (ordenar parámetros, estándar de codificación).
3. Haz clic en Build para generar un query string correctamente codificado.
4. Copia el resultado y agrégalo a tu URL base.

Ejemplos de análisis de query strings

Cuándo usar el Query String Parser/Builder

• Depuración de flujos OAuth -- Extraer e inspeccionar parámetros state, code, redirect_uri y de token desde URLs de callback.
• Construcción de solicitudes API -- Construir query strings correctamente codificados para APIs REST con filtros, paginación y parámetros de ordenamiento.
• Análisis de enlaces de marketing -- Descomponer parámetros de tracking UTM e identificadores de campaña de URLs compartidas.
• Depuración de webhooks -- Analizar URLs de callback de webhooks entrantes para entender qué parámetros está enviando el servicio.
• Inspección de datos de formulario -- Decodificar datos de cuerpo POST en formato application/x-www-form-urlencoded que usan formato de query string.
• Pruebas de migración -- Verificar que las reescrituras de URL y reglas de redirección preserven los parámetros de query correctamente durante migraciones de sitio.

Cómo funciona la codificación de query strings de URL

Los query strings siguen el estándar de codificación application/x-www-form-urlencoded, que se basa en el percent-encoding del RFC 3986.

Reglas de percent-encoding

Los caracteres que no son seguros en URLs se reemplazan con % seguido de su código hexadecimal de dos dígitos:

Notación de arrays y objetos anidados

Diferentes frameworks usan diferentes convenciones para arrays y objetos en query strings:

• Notación de corchetes: colors[]=red&colors[]=blue (PHP, Rails)
• Notación indexada: colors[0]=red&colors[1]=blue (ordenamiento explícito)
• Claves repetidas: colors=red&colors=blue (Java, Go)
• Objetos anidados: user[address][city]=NYC (anidamiento profundo)
• Notación de punto: user.address.city=NYC (algunos frameworks Java)

Errores comunes de codificación

Un bug frecuente en query strings construidos a mano es la doble codificación. Si codificas un valor que ya está codificado, %20 se convierte en %2520 (el % en sí mismo se codifica), y el servidor recibe un string literal %20 en lugar de un espacio. El parser detecta y marca la posible doble codificación para que puedas identificar estos problemas inmediatamente.

Consejos prácticos para trabajar con query strings

Uno de los errores más comunes que cometen los desarrolladores es construir query strings mediante concatenación de strings en lugar de usar un constructor de URL apropiado. Parece rápido escribir url + "?key=" + value, pero en el momento en que value contiene un ampersand, un espacio o un carácter Unicode, la URL resultante está malformada. Cada lenguaje principal tiene un constructor de URL o query string incorporado -- URLSearchParams en JavaScript, urllib.parse.urlencode en Python, http_build_query en PHP -- y siempre deberías usarlos.

Al depurar llamadas API, presta atención a la diferencia entre + y %20 para espacios. Ambos son válidos en query strings bajo el estándar application/x-www-form-urlencoded, pero se comportan diferente en segmentos de ruta. Un + en la ruta de una URL es un signo de más literal, no un espacio. Si tu endpoint API recibe search/hello+world en la ruta en lugar del query string, no es un espacio -- es hello+world. Esta distinción causa bugs sutiles al mover parámetros entre la ruta y el query string.

Si estás trabajando con URLs de callback OAuth, siempre analiza el query string en lugar de usar regex o división de strings. Los callbacks OAuth pueden contener tokens codificados en base64 como valores de parámetros, y estos tokens pueden incluir caracteres como = y + que rompen el análisis ingenuo. Un parser de query strings apropiado maneja la codificación correctamente y te ahorra bugs de autenticación que solo aparecen con ciertos valores de token.

Preguntas frecuentes

¿Cuál es la diferencia entre %20 y + para espacios?

En la codificación application/x-www-form-urlencoded (formularios HTML), los espacios se codifican como +. En el percent-encoding estándar (RFC 3986), los espacios son %20. La mayoría de los servidores aceptan ambos en query strings, pero %20 es técnicamente correcto en segmentos de ruta donde + es un signo de más literal.

¿Cómo manejo claves duplicadas en un query string?

El comportamiento depende de tu framework de servidor. La mayoría de los frameworks (Express.js, Django, Rails) recopilan las claves duplicadas en un array. Algunos mantienen solo el primer o último valor. El parser muestra todas las ocurrencias para que puedas ver exactamente lo que se envió.

¿Importa el orden de los parámetros en los query strings?

Técnicamente, el orden del query string es significativo según la especificación HTTP. En la práctica, la mayoría de los servidores ignoran el orden. Si necesitas strings consistentes para caché o comparación, usa la opción de ordenamiento al construir.

¿Cuál es la longitud máxima de un query string?

No hay un límite estricto en la especificación HTTP, pero los navegadores y servidores imponen límites prácticos. La mayoría de los navegadores soportan URLs de hasta aproximadamente 2,000 caracteres en total. Los servidores web como Apache tienen un valor predeterminado de 8,190 bytes para toda la línea de solicitud (método + URL + versión HTTP). Si te estás acercando a estos límites, considera mover los parámetros al cuerpo de la solicitud usando POST en lugar de GET.

¿Cómo paso datos JSON en un query string?

Puedes codificar un string JSON completo como un solo valor de parámetro: ?data=%7B%22key%22%3A%22value%22%7D. Sin embargo, esto es frágil y difícil de depurar. Para datos complejos, es mejor usar una solicitud POST con un cuerpo JSON. Si debes usar GET, aplana el JSON en parámetros individuales (?key=value&nested.field=data).

¿Los nombres de parámetros de query string pueden contener caracteres especiales?

Sí, pero deben estar percent-encoded. Un parámetro llamado user[name] se envía como user%5Bname%5D=value en la URL sin procesar. La mayoría de los frameworks decodifican esto automáticamente. El parser muestra tanto las formas codificadas como las decodificadas.

Herramientas relacionadas

• URL Parser - Analizar URLs completas en componentes de esquema, host, puerto, ruta y query
• URL Normalizer - Normalizar URLs ordenando parámetros y eliminando valores predeterminados
• Bulk Add/Remove Query Params - Agregar o eliminar parámetros de query de múltiples URLs a la vez
• Cookie Header Parser - Analizar headers Cookie y Set-Cookie que frecuentemente acompañan solicitudes basadas en query
• curl Command Builder - Construir comandos curl con parámetros de query correctamente codificados