Analizador de URL

El URL Parser descompone cualquier URL en sus partes componentes según la especificación RFC 3986, mostrando exactamente cómo los navegadores y clientes HTTP interpretan cada segmento. Pega una URL como https://www.example.com:8443/api/v2/users?status=active&limit=50#results y ve cada componente extraído: scheme, host, port, path, parámetros de query y fragment.

Entendiendo la estructura de URLs

Las URLs son las direcciones de la web, pero su estructura es más compleja de lo que la mayoría de los desarrolladores perciben hasta que se encuentran con un caso límite de parsing. Una URL no es solo "lo que escribes en el navegador" -- es un formato definido con precisión especificado en RFC 3986, con reglas sobre qué caracteres están permitidos dónde, cómo los caracteres especiales deben codificarse y cómo cada componente se delimita del siguiente. Equivocarse en estos detalles causa errores reales: cadenas de redirección rotas, llamadas API mal enrutadas, vulnerabilidades de seguridad por confusión de URLs y fallos de tracking en analytics por parámetros de query perdidos.

La estructura básica de una URL es scheme://userinfo@host:port/path?query#fragment, pero la mayoría de las URLs omiten varios de estos componentes. El scheme le dice al cliente qué protocolo usar (http, https, ftp). El host identifica el servidor, ya sea como nombre de dominio o dirección IP. El port usualmente es implícito -- 443 para HTTPS, 80 para HTTP -- pero puede especificarse explícitamente cuando un servicio corre en un puerto no estándar. El path identifica el recurso específico en ese servidor. El query string transporta parámetros como pares clave-valor. Y el fragment apunta a una sección específica dentro del recurso, procesado completamente por el cliente y nunca enviado al servidor.

Lo que confunde a la gente son los casos límite. Una URL puede contener credenciales (user:password@host), aunque esto está deprecado para HTTP. Las direcciones IPv6 deben estar encerradas en corchetes ([2001:db8::1]). Los valores de parámetros de query pueden contener caracteres ? y = si están percent-encoded. El primer ? separa el path del query, pero los caracteres ? subsiguientes son partes literales del query. Este parser maneja todos estos casos y muestra cada componente por separado, haciendo la estructura de la URL inequívoca.

Cómo analizar una URL en sus componentes

1. Pega cualquier URL completa en el campo de entrada
2. El parser extrae cada componente: scheme, userinfo, host, port, path, query, fragment
3. Los query strings se descomponen además en pares individuales clave-valor
4. Los puertos por defecto se identifican basándose en el scheme (por ejemplo, 443 para https)
5. Se resaltan cualquier problema de codificación o construcción no estándar

Ejemplos de análisis de URLs

URL HTTPS estándar

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

Parámetros de query:

URL con autenticación

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

URL con host IPv6

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

Query string complejo

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

Parámetros de query:

Cuándo usar el URL Parser

• Depuración de cadenas de redirección para inspeccionar cada URL en la secuencia e identificar dónde se pierden o modifican los parámetros
• Análisis de URLs de callback OAuth para verificar URIs de redirección, parámetros de estado y códigos de autorización
• Extracción de parámetros de query de URLs largas en payloads de webhooks, enlaces de tracking de analytics o respuestas de APIs
• Inspección de deep links en aplicaciones móviles para entender el enrutamiento y el paso de parámetros
• Análisis de seguridad de URLs potencialmente maliciosas para identificar ofuscación en los componentes de host, path o query
• Comparación de URLs para determinar si dos URLs que se ven diferentes realmente apuntan al mismo recurso

Cómo funciona la estructura de URLs (RFC 3986)

La anatomía de una URL

Una URL sigue esta estructura general:

scheme://userinfo@host:port/path?query#fragment

Cada componente sirve un propósito específico:

• Scheme -- identifica el protocolo (http, https, ftp, ssh, mailto)
• Userinfo -- credenciales opcionales (user:password@), deprecado para HTTP/HTTPS
• Host -- nombre de dominio (example.com) o dirección IP (192.0.2.1 o [2001:db8::1])
• Port -- número de puerto TCP opcional; los valores por defecto dependen del scheme (80 para HTTP, 443 para HTTPS)
• Path -- identificador jerárquico del recurso (/api/v2/users)
• Query -- parámetros clave-valor después de ?, separados por & (status=active&limit=50)
• Fragment -- ancla del lado del cliente después de #, no se envía al servidor (#section-2)

Percent encoding

Los caracteres especiales en URLs deben ser percent-encoded usando % seguido de dos dígitos hexadecimales. Codificaciones comunes:

Puertos por defecto por scheme

Cuando se usa el puerto por defecto, típicamente se omite de la URL. El parser identifica tanto los puertos explícitos como los implícitos.

Análisis de URLs en la práctica

La razón más común por la que los desarrolladores recurren a un parser de URLs es la depuración. Estás mirando una cadena de redirección y la URL final no tiene un parámetro de query que estaba presente en la original. ¿El parámetro fue descartado por la redirección? ¿Fue renombrado? ¿Fue absorbido en el path? Analizar cada URL en la cadena lado a lado revela exactamente dónde desapareció el parámetro. Esto es especialmente común en flujos OAuth, donde las URIs de redirección transportan parámetros de estado, códigos de autorización y valores de scope que deben sobrevivir múltiples redirecciones intactos.

Otro caso de uso frecuente es el trabajo de integración de APIs. Cuando recibes un payload de webhook o una URL de callback de un servicio de terceros, necesitas extraer parámetros de query específicos para procesar el evento. La URL podría estar profundamente anidada en una respuesta JSON, URL-encoded dentro de otra URL, o truncada en un archivo de log. Analizarla en componentes te da acceso limpio a cada parámetro sin división manual de strings que se rompe en casos límite como caracteres & codificados dentro de valores de parámetros.

Para análisis de seguridad, el análisis de URLs revela técnicas de ofuscación que son invisibles al mirar la URL cruda. Un atacante podría usar un carácter @ codificado (%40) para hacer que una URL parezca apuntar a un dominio confiable cuando en realidad se autentica contra uno malicioso. O podrían usar separadores de path codificados para evadir controles de acceso basados en path. Analizar la URL con un parser compatible con los estándares muestra la estructura verdadera después de la decodificación, haciendo estas técnicas visibles.

Preguntas frecuentes

¿Por qué el fragment no se envía al servidor?

El identificador de fragment (todo después de #) es procesado completamente por el cliente (navegador). Se elimina de la URL antes de que se realice la solicitud HTTP. El servidor nunca ve el fragment. Esto está definido en RFC 3986 y se usa para navegación del lado del cliente dentro de una página, enrutamiento de aplicaciones de página única y enlaces de ancla.

¿Cómo maneja el parser URLs con múltiples caracteres ? o #?

Según RFC 3986, solo el primer ? separa el path del query, y solo el primer # (después del query) separa el query del fragment. Los caracteres ? adicionales dentro del query se tratan como caracteres literales. Los caracteres # adicionales dentro del fragment también son literales. El parser sigue este comportamiento estándar.

¿Puede el parser manejar nombres de dominio internacionalizados (IDN)?

Sí. Los nombres de dominio internacionalizados como beispiel.de (con diéresis u otros caracteres no ASCII) se muestran tal cual y el parser también muestra la codificación Punycode (por ejemplo, xn--bsp-jma.example.com) que se usa en la búsqueda DNS real.

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

Ambos representan un carácter de espacio, pero se usan en contextos diferentes. %20 es la codificación percent estándar para un espacio y es válido en cualquier parte de una URL. La codificación + para espacios es específica del formato application/x-www-form-urlencoded usado en envíos de formularios HTML y query strings. En el componente de path, + es un signo más literal, no un espacio. El parser maneja ambas codificaciones correctamente según su contexto.

¿Cómo determino si dos URLs diferentes apuntan al mismo recurso?

Analiza ambas URLs y compara sus componentes. URLs que difieren solo en el puerto por defecto (por ejemplo, http://example.com vs http://example.com:80), barras finales, orden de parámetros de query o diferencias de codificación pueden resolver al mismo recurso. Usa el URL Normalizer para canonicalizar URLs antes de la comparación.

¿Por qué mi URL se analiza diferente en diferentes lenguajes de programación?

Diferentes bibliotecas de parsing de URLs pueden manejar casos límite de manera diferente. urllib.parse de Python, el constructor URL de JavaScript y net/url de Go generalmente siguen RFC 3986 pero pueden divergir en URLs malformadas, referencias relativas o patrones de codificación inusuales. Este parser sigue la especificación RFC 3986 estrictamente y es útil como implementación de referencia para comparar contra el parser de tu lenguaje.

Herramientas relacionadas

• URL Normalizer - Normaliza URLs eliminando valores por defecto y ordenando parámetros
• Query String Parser/Builder - Analiza y construye query strings de URLs
• Port Validator - Valida números de puerto (0-65535)
• HTTP Header Formatter - Convierte entre formatos de headers raw y clave/valor
• Bulk Add/Remove Query Params - Agrega o elimina parámetros de query de múltiples URLs