Una vez perdí una tarde ante una URL que se veía bien. Una devolución de llamada de OAuth seguía fallando, el URI de redirección "coincidió" con el que se registró con el proveedor, y no pude ver por qué se rompió el apretón de manos. La respuesta, cuando finalmente pegué la cosa en un analizador, fue una barra al final en el camino en un lugar y ninguna en el otro, además de un state Parámetro que había sido codificado doblemente %20 se había convertido %2520. Para el ojo humano, las dos URL eran idénticas. Para el servidor de OAuth eran cadenas diferentes, y era correcto rechazar la falta de coincidencia.
Ese es el problema con las URL: son densas, son fáciles de leer mal y los detalles que rompen las cosas (una barra codificada, un puerto perdido, una clave de consulta repetida, un fragmento donde esperabas una ruta) son exactamente los que esconderse en una pared de caracteres. Construyo [Toolz.dev](/, y paso suficiente tiempo mirando cadenas de consulta mientras depuro que construí una Analizador de URL para hacer la mirada por mí. Pegue un enlace, obtenga todos los componentes etiquetados y cada parámetro de consulta decodifica en una tabla. Esta guía explica qué son esos componentes, por qué son importantes las distinciones y cómo usarlas.
TL;Dr: Una URL está hecha de un esquema (
https), credenciales opcionales (user:pass@), un anfitrión (example.com) con un puerto opcional, una ruta (/blog/post), una cadena de consulta (?id=42), y un fragmento (#section). los Analizador de URL Divide cualquier enlace en esas partes usando el propio motor de URL WhatWG de navegador, decodifica la consulta en una tabla de valor-clave ordenada (claves repetidas mantenidas separadas), muestra el puerto efectivo para el esquema y asumehttps://Si pega un dominio desnudo. Se ejecuta completamente en su navegador, por lo que los enlaces con tokens permanecen privados.
¿Cuáles son las partes de una URL?
Cada URL sigue la misma gramática, definida por el estándar de URL WHATWG, la especificación que los navegadores realmente implementan. Una vez que puedes nombrar las partes, la mayoría de los errores de URL se vuelven obvios. Aquí está la anatomía completa, usando un ejemplo deliberadamente ocupado:
https://john:[email protected]:8443/catalog/shoes?color=red&size=42#reviews
└─┬─┘ └──┬──┘└─┬──┘└──────┬────────┘└─┬─┘└──────┬──────┘└──────┬──────┘ └──┬──┘
scheme user pass hostname port path query fragment
Rompiendo eso:
| parte | Valor de ejemplo | que es |
|---|---|---|
| enjuague | https |
El protocolo. Decide el puerto predeterminado y cómo se realiza la solicitud. |
| nombre de usuario | john |
credencial opcional, antes de la @. |
| contraseña | s3cret |
credencial opcional, después de la : en la información de usuario. |
| nombre de host | shop.example.co.uk |
El dominio o la dirección IP, sin puerto. |
| porta | 8443 |
opcional. Recae en el valor predeterminado del esquema cuando se omite. |
| huésped | shop.example.co.uk:8443 |
Hostname Plus puerto, cuando hay un puerto. |
| raíz | https://shop.example.co.uk:8443 |
Scheme plus host: los navegadores de la unidad se utilizan por motivos de seguridad. |
| vialidad | /catalog/shoes |
La ubicación de los recursos en el host. |
| poner en duda | ?color=red&size=42 |
Parámetros de valor clave después de la ?. |
| trozo | #reviews |
Anclaje del lado del cliente después de la #, nunca enviado al servidor. |
El analizador establece cada uno de estos como su propia fila con un botón de copia, por lo que nunca más tendrá que extraer un nombre de host de una URL de monstruo. También marca un par de cosas que oculta la cadena sin procesar: si el puerto que se muestra es explícito o si el esquema es predeterminado, y si el host es un dominio con nombre o una IP sin procesar.
¿Cuál es la diferencia entre el nombre de host, el host y el origen?
Estas tres personas hacen tropezar constantemente y la confusión causa errores reales: fallas de CORS, errores de alcance de cookies, desajustes de redireccionamiento. No son sinónimos. El Whatwg estándar de URL es la definición que realmente implementan los navegadores y es el lugar para resolver una discusión sobre lo que se considera un origen.
nombre de host es solo el dominio o IP: shop.example.co.uk. Sin puerto, sin esquema. Es lo que pondrías en una búsqueda de DNS.
huésped es el nombre de host más el puerto, Pero solo cuando un puerto está presente en la URL. en shop.example.co.uk:8443 El anfitrión es shop.example.co.uk:8443. por una llanura https://shop.example.co.uk/ El host y el nombre de host son idénticos, porque el puerto 443 predeterminado está implícito en lugar de escrito. Esa regla "sólo cuando está presente" es sutil y es por eso que el mismo sitio puede parecer que tiene dos hosts diferentes.
raíz Es esquema más anfitrión: https://shop.example.co.uk:8443. Este es el que más preocupa a los navegadores, porque la política del mismo origen -la base de la seguridad web- compara los orígenes, no los nombres de host. Dos URL comparten un origen sólo si su esquema, nombre de host, y puerto todo coincidencia. http://example.com y https://example.com son orígenes diferentes porque el esquema difiere. https://example.com y https://example.com:8443 son orígenes diferentes porque el puerto difiere, aunque el nombre de host sea el mismo. Si una búsqueda falla con un error de CORS, la comparación de los dos orígenes uno al lado del otro en el analizador suele ser la forma más rápida de detectar la falta de coincidencia.
¿Cómo analizo una cadena de consulta?
La cadena de consulta es donde vive la mayor parte del dolor diario, porque es una mancha plana y de aspecto sin escapar que está realmente estructurada y codificada porcentual. El parser lo divide para usted: todo después de la ?, roto en &, con cada key=value Par decodificado y enumerado en una tabla en su orden original.
Dos comportamientos importan aquí. primero, desciframiento. un parámetro escrito como q=trail%20runner en el cable se muestra como trail runner En la columna Valor, porque %20 es un espacio codificado porcentual. el crudo search la cadena todavía se muestra intacta en la lista de componentes, por lo que puedes comparar las formas codificadas y decodificadas, algo invaluable cuando sospechas de codificación doble, como mi %2520 Error de OAuth.
segundo, teclas repetidas. Una URL puede llevar legítimamente la misma clave más de una vez: ?tag=react&tag=typescript&tag=node. Muchos analizadores ingenuos los colapsan, manteniendo sólo el primer o último valor y perdiendo datos silenciosamente. Eso está mal: las claves repetidas son la forma en que los formularios HTML envían campos de selección múltiple y cómo muchas API expresan matrices. El analizador mantiene cada aparición como su propia fila, en orden, para que vea las tres etiquetas. Cuando copia la consulta como JSON, las claves repetidas se convierten en una matriz, que es la forma que la mayoría del código espera.
Ni siquiera necesitas una URL completa para usar esto. Pegue solo una cadena de consulta - color=red&size=42 - y la herramienta lo analiza por sí sola. Es la forma más rápida que conozco de dar sentido a una carga útil de webhook o un enlace de seguimiento que alguien le reenvió.
¿Cómo uso el analizador de URL?
La herramienta está diseñada para apartarse de su camino. Pegue una URL en la entrada única y la analizará en vivo mientras escribe; no hay ningún botón para presionar. Un enlace de muestra está precargado para que pueda ver el desglose completo inmediatamente y un botón Borrar vacía el campo.
No es necesario que escriba el esquema. Pegar un host como desnudo example.com/pricing Y el parser antepone https:// automáticamente, luego te dice que lo hizo con una pequeña nota, por lo que nunca estás confundido acerca de de dónde vino el esquema. Pegue un esquema explícito - http://, ftp://, ssh:// - y en cambio lo respeta.
La salida tiene cuatro zonas. En la parte superior, el URL normalizada - la forma canónica que produjo el motor del navegador 's, con un botón de copia, que es útil para detectar diferencias sutiles de normalización. Debajo de eso, el componentes Tabla, una fila etiquetada por pieza, cada una de forma independiente. de entonces Segmentos de ruta, dividido en fichas indexadas por lo que un camino profundo como /api/v2/users/42/orders es legible de un vistazo. Finalmente el Parámetros de tabla, decodificada y ordenada, con una acción "Copiar como JSON" que convierte toda la consulta en un objeto limpio.
Todo se ejecuta en su navegador usando su motor de URL nativo. Esa es una elección deliberada: las URL contienen habitualmente tokens de acceso, ID de sesión, parámetros firmados y nombres de host internos, y nada de eso debe enviarse a un servidor solo para leerlo. Nada de lo que pegas deja tu dispositivo y la herramienta sigue funcionando sin conexión. Es el mismo enfoque de privacidad, detrás de todo el conjunto de herramientas, al que meto en el Guía del kit de herramientas para desarrolladores web.
¿Cuándo busco un analizador de URL?
Algunas situaciones surgen una y otra vez en mi propio trabajo. Depuración de redirecciones y devoluciones de llamada es el más importante: flujos de OAuth, URL de devolución de pagos, apretones de manos SSO, todos los cuales fallan en pequeñas discrepancias que solo se vuelven visibles cuando descompone ambas URL. Enlaces de seguimiento de auditoría es otra: las URL de marketing son a menudo una página base más una docena de parámetros de UTM y de plataforma publicitaria, y leyendo como una tabla supera entre los ojos en una cadena de 300 caracteres. Si está construyendo esos enlaces en lugar de leerlos, el constructor de um es la otra mitad del mismo flujo de trabajo.
entonces hay Trabajo de API - inspeccionar los parámetros de consulta que realmente envió un cliente, o realizar ingeniería inversa en cómo espera un punto final sus filtros. Y Revisión de seguridad: Un enlace desconocido en un correo electrónico o un registro es mucho más seguro de entender al analizar sus partes (qué host hace esto en realidad ¿Es ese nombre de host una IP?) que haciendo clic en él. El analizador expone el verdadero nombre de host y marca los hosts literales IP, que es exactamente la información que desea antes de confiar en un enlace. Escribí más sobre el ensamblaje de este tipo de kit de inspección en el Guía de herramientas de depuración de API.
¿cómo se relaciona el análisis con la codificación y slugs?
Un analizador de URL es una esquina de una pequeña familia de herramientas de enlace y saber cuál necesita ahorra tiempo. patinador lecturas una URL existente y la separa. codificación hace la dirección opuesta a nivel de carácter: convertir espacios y caracteres especiales en sus formas codificadas por porcentaje para que sobrevivan dentro de una URL y regresen. Cuando necesita incrustar de forma segura un valor en una cadena de consulta o decodificar una que está destrozada, ese es el Codificador de URL/decodificador, y se empareja naturalmente con el analizador: analiza la estructura, codifica para arreglar un valor roto.
Slug generație es un tercer trabajo relacionado: tomar un título humano como " 10 consejos para construcciones más rápidas " y convertirlo en limpio 10-tips-for-faster-builds segmento de ruta. eso es lo que el Slug Generator maneja, y es lo que produce el ordenado path componente que el analizador lee más tarde. Piense en ello como una canalización: compílelo para crear buenas rutas, codifique para que los valores sean seguros para URL, analice para inspeccionar el enlace terminado. Cada herramienta realiza una parte del ciclo de vida de la URL y lo hace en el navegador.
¿Qué pasa con las direcciones IP y los dominios internacionalizados?
No todos los anfitriones son un orden example.com. Algunas URL apuntan a las direcciones IP sin procesar y el analizador reconoce ambos formularios. Un literal IPv4 http://192.168.1.10:3000/ tiene un nombre de host de 192.168.1.10, y la herramienta lo marca como una IP en lugar de un dominio, lo cual es útil cuando audita un enlace y desea saber instantáneamente si se dirige a un sitio con nombre o a una dirección simple, que es una señal común en enlaces sospechosos. Los literales IPv6 están entre corchetes en una URL, como en http://[2001:db8::1]:8080/, y los corchetes son parte de la sintaxis del host, no de la decoración; el parser maneja que se forman correctamente en lugar de ahogarse en los dos puntos, que de otro modo se verían como separadores de puerto.
Los nombres de dominio internacionalizados son el otro caso marginal. Un host escrito en caracteres que no son ASCII (por ejemplo, un dominio con letras acentuadas o no latinas) es convertido por el navegador & #39;s motor de URL en su Punycode xn-- Formulario para la solicitud real, porque DNS solo habla ASCII. viendo lo normalizado href En el analizador te muestra exactamente lo que resolverá el navegador, lo que ocasionalmente sorprende a las personas que esperaban que su bonito dominio Unicode viajara sin cambios. Para el dominio de nivel superior, el analizador extrae la etiqueta final de un host con nombre, por lo que shop.example.co.uk informa un TLD de uk. Ésa es una regla deliberadamente simple: no intenta eliminar sufijos de varias partes como .co.uk en un dominio registrable, porque hacerlo correctamente requiere la lista de sufijos públicos, que es un gran conjunto de datos en movimiento. Para una inspección rápida, la última etiqueta es la señal útil, y para cualquier cosa más rigurosa, buscaría una biblioteca dedicada.
Un ejemplo trabajado lo une. Digamos que un proveedor de pago sigue rechazando su URL de devolución. te registraste https://app.example.com/checkout/return Pero la solicitud fallida muestra https://app.example.com:443/checkout/return/. Analice ambos. El analizador muestra que el primero tiene host app.example.com (puerto predeterminado, no hay barra diagonal en el camino) y el segundo tiene host app.example.com también, pero su camino lo es /checkout/return/ con una barra final, y su puerto fue escrito explícitamente como :443. Dos diferencias por el que el ojo se desliza, ambos fatales a una prueba de coincidencia exacta. Una vez que pueda verlos como componentes etiquetados separados, la solución es obvia: normalizar la barra inclinada final y soltar el puerto explícito redundante.
Errores comunes al leer URL
Los errores recurrentes valen la pena nombrarlos. confundir el fragmento con la ruta o consulta - totul după # es el fragmento, lo maneja completamente el navegador y nunca se envía al servidor, por lo que un parámetro que pone después # no llegará a su backend. Suponiendo que falta un puerto significa que no hay puerto - un puerto omitido significa el esquema falta de valor (443 para HTTPS, 80 para HTTP), que el analizador hace explícito para que sepa qué puerto realmente golpeará una solicitud.
Ignorar la codificación doble - si parece un valor %2520 en vez de %20, se codificó dos veces; analizarlo, y si el valor decodificado todavía contiene una secuencia porcentual, decodifica nuevamente. Confiar en el texto visible de un enlace - el texto que ves y el real href Puede diferir completamente, que es todo el mecanismo detrás del phishing; el análisis revela el verdadero host de destino. y Tratar claves de consulta repetidas como duplicados para descartar - suelen ser matrices significativas y al eliminarlas se pierden datos.
Preguntas frecuentes
¿Cuáles son las partes de una URL?
Una URL tiene un esquema (https), credenciales opcionales (user:pass@), un host (ejemplo.com) con un puerto opcional, una ruta (/blog/post), una cadena de consulta opcional (?id=42) y un fragmento opcional (#section). Este analizador separa y etiqueta cada uno.
¿Cómo analizo una cadena de consulta?
Pegue la URL completa y lea la tabla de consultas, o pegue solo la cadena de consulta por su cuenta. El analizador lo divide en ampersands, decodifica el porcentaje de codificación y enumera cada par clave-valor en orden. Las teclas repetidas como TAG=A&tag=B se mantienen como filas separadas.
¿Cuál es la diferencia entre el nombre de host, el host y el origen?
HostName es solo el dominio o IP (ejemplo.com). El host agrega el puerto cuando uno está presente (ejemplo.com:8443). Origen es el esquema más anfitrión (https://ejemplo.com:8443) y es lo que usan los navegadores para la verificación de seguridad del mismo origen.
¿Qué puerto se usa cuando una URL no tiene número de puerto?
El esquema decide. HTTPS tiene como valor predeterminado 443, HTTP a 80, SSH a 22 y FTP a 21. Este analizador muestra el puerto efectivo y lo marca como predeterminado, por lo que sabe qué puerto usaría realmente una solicitud.
¿El analizador decodifica los caracteres codificados porcentuales?
Sí, para valores de consulta. Un parámetro como name=john%20doe se muestra decodificado como "John Doe" en la tabla. La cadena de búsqueda sin procesar también se muestra intacta para que pueda comparar los formularios codificados y decodificados.
¿Puedo analizar una URL sin escribir la parte https?
Sí. Si pega un host o una ruta desnuda como ejemplo.com/precio, el parser se antepone https:// y toma nota de que asumió el esquema. Pegue un esquema explícitamente, como http:// o ftp://, para anular esa suposición.
¿Por qué mi URL no puede analizar?
Por lo general, el host falta o está mal formado, el esquema se escribe incorrectamente o la cadena contiene caracteres que son ilegales en una URL y no están codificados por porcentaje. Compruebe si hay espacios, corchetes sin escapar o una barra infalible después del esquema.
¿Es seguro pegar URL con tokens o ID de sesión?
Sí. El análisis se ejecuta completamente en su navegador utilizando su motor de URL nativo. El enlace nunca se envía a un servidor, nunca se registra ni se almacena, por lo que las URL que contienen tokens de acceso, claves de API o nombres de host internos permanecen en su dispositivo.
