¿Cómo reproduzco un bug de un ticket que incluye una URL larga?

Pega la URL completa del ticket en la pestaña «Analizar URL». La herramienta separa protocolo, host, puerto, ruta, cada parámetro de la query (ya decodificado) y el fragmento, así puedes comparar de un vistazo qué parámetro tiene un valor distinto al esperado, en vez de leer una cadena larga y codificada carácter por carácter.

¿Por qué un espacio se convierte en + en vez de %20?

Depende del contexto de codificación. encodeURIComponent() en JavaScript siempre produce %20 para un espacio. El formato application/x-www-form-urlencoded, que usan muchos formularios HTML al enviarse por POST/GET, usa + en su lugar. Si ves un + inesperado en un valor que no es un espacio (por ejemplo un email con un + real, como usuario+test@dominio.com), puede indicar que el valor pasó por una codificación de formulario en algún punto de la cadena de envío.

¿Cómo pruebo varios casos límite de codificación a la vez?

Usa la pestaña «Masa»: pega un valor de prueba por línea (por ejemplo una cadena vacía, un emoji, una letra con acento, un carácter & suelto, una ruta con barras) y ejecuta la misma operación sobre todas las líneas de golpe. Los resultados vuelven en el mismo orden que la entrada, lo que facilita anotar en una hoja de pruebas qué caso produjo qué salida sin repetir la operación una por una.

¿Cómo verifico que dos entornos (staging y producción) generan la misma query string?

Analiza la URL de cada entorno por separado en la pestaña «Analizar Query» y compara la tabla de parámetros decodificados de una con la otra, en lugar de comparar las cadenas codificadas en bruto — dos codificaciones distintas de los mismos datos pueden parecer diferentes carácter a carácter y aun así representar exactamente los mismos valores una vez decodificadas.

¿Qué debo revisar si una API devuelve un error 400 por una URL mal formada?

Primero analiza la URL exacta que se envió (desde los logs de red, no de memoria) en la pestaña «Analizar URL» para ver si algún carácter reservado —como &, ? o # dentro de un valor de parámetro, no como separador— quedó sin codificar y rompió la estructura. Si el problema persiste, prueba a reconstruir la query string desde cero con la pestaña «Construir Query», que codifica automáticamente cada valor por separado.

Depurar enlaces rotos en QA: codificación URL para desarrolladores

Cuando un ticket de bug dice «el enlace no abre bien» o «el filtro no se aplica», casi nunca hace falta releer la especificación de RFC 3986 de memoria: basta con analizar la URL exacta que falló, parámetro por parámetro, y comparar contra lo que el sistema debería haber generado. Esta guía repasa el flujo que usaría alguien de QA o de desarrollo para diagnosticar ese tipo de tickets.

Reproducir un bug a partir de una URL de un ticket

Respuesta rápidaPega la URL completa del ticket en la pestaña «Analizar URL». Verás protocolo, host, puerto, ruta, cada parámetro de la query ya decodificado y el fragmento, separados en filas — mucho más fácil de inspeccionar que la cadena original en una sola línea.

Un escenario habitual (ilustrativo, no un caso real): un ticket describe que al hacer clic en un enlace desde el correo de confirmación de un pedido, la página de destino muestra la talla equivocada. Si la URL adjunta en el ticket es larga y está codificada, leerla a simple vista para encontrar el parámetro talla es lento y propenso a error. Analizarla primero convierte ese trabajo en una tabla: cada clave con su valor ya legible, en vez de una cadena de %XX mezclados con letras.

Por qué analizar antes de depurar a mano Un valor decodificado incorrecto salta a la vista en una tabla («talla: 4» en vez de «talla: 42»); en la cadena en bruto ese mismo error puede quedar oculto entre otros códigos de porcentaje.

Además del listado de parámetros, la herramienta separa el fragmento (lo que va después de #), que en aplicaciones de una sola página (SPA) suele contener el estado de la vista — pestaña activa, paso de un asistente, etc. — y que a veces se pasa por alto al comparar dos URL que en apariencia son «la misma».

El error del + convertido en espacio (form-urlencoded)

Respuesta rápidaencodeURIComponent() de JavaScript siempre convierte un espacio en %20. El formato application/x-www-form-urlencoded, usado por formularios HTML clásicos, usa + para el espacio en su lugar. Si ambos convierten datos entre sí sin tenerlo en cuenta, un espacio puede acabar convertido en un + literal, o un + real del dato original puede confundirse con un espacio al decodificar.

Un ejemplo de dónde aparece este bug en la práctica (hipotético): un formulario de registro envía un correo con signo más, como usuario+test@dominio.com — un patrón común para crear alias de prueba en Gmail — usando codificación de formulario. Si en otro punto del sistema ese mismo valor se decodifica asumiendo %20 en vez de + para los espacios, el + del correo puede interpretarse mal y el registro fallar silenciosamente o guardar un valor distinto al que el usuario introdujo.

La pestaña «Codificar» de la herramienta incluye un interruptor específico de «codificación de formulario (+ para el espacio)» para poder generar y verificar ambas variantes por separado, en lugar de asumir que siempre se comportan igual.

Probar varios casos límite a la vez con el modo Masa

Respuesta rápidaEn la pestaña «Masa» puedes pegar varios valores de prueba, uno por línea (acentos, emoji, & suelto, barras, cadena vacía) y aplicar la misma operación a todos de una vez; los resultados vuelven en el mismo orden que la entrada.

Durante una ronda de pruebas de un formulario o de un endpoint que acepta parámetros en la URL, suele convenir comprobar varios casos límite seguidos en vez de uno a uno: un valor con letras acentuadas, uno con un emoji, uno que ya contenga un carácter & sin escapar, uno vacío. Escribir cada caso en una línea distinta del modo Masa y ejecutar la operación una sola vez produce todas las salidas juntas, listas para copiar a una hoja de casos de prueba o adjuntar a un reporte de QA.

Ejemplo de lote de entrada (ilustrativo): una línea con «café con leche», otra con un emoji suelto, otra con «nombre=Ana & apellido=Ruiz» (con & sin escapar a propósito) y una línea vacía.
El resultado permite ver de un vistazo si alguna línea produjo una salida inesperada — por ejemplo si la línea vacía no debería generar ningún carácter y en cambio genera algo.

Comparar la misma query string entre dos entornos

Respuesta rápidaAnaliza por separado la URL de staging y la de producción en la pestaña «Analizar Query», y compara los valores ya decodificados de cada parámetro — no las cadenas codificadas en bruto, que pueden diferir carácter a carácter aunque representen los mismos datos.

Es habitual, sobre todo con librerías distintas en front-end y back-end, que dos sistemas codifiquen el mismo valor de forma ligeramente distinta a nivel de caracteres (por ejemplo un espacio como %20 en uno y como + en otro) sin que eso sea en realidad un bug: una vez decodificados, ambos representan el mismo dato. Comparar las cadenas en bruto puede hacer saltar una alarma falsa; comparar la tabla de parámetros ya decodificada muestra si el dato real es idéntico o no.

Si tras analizar ambas URL los valores decodificados difieren de verdad, entonces sí hay un problema real que investigar — por ejemplo un parámetro que un entorno añade y el otro no, o un valor truncado en un lado.

Depurar enlaces rotos en QA: codificación URL para desarrolladores

Reproducir un bug a partir de una URL de un ticket

El error del + convertido en espacio (form-urlencoded)

Probar varios casos límite a la vez con el modo Masa

Comparar la misma query string entre dos entornos

Preguntas frecuentes

Guías relacionadas