Parser e builder URL
Analizza URL in 8 componenti con tabella query e rilevamento IDN/Punycode. Costruisce URL. Resolver relativo.
Resolved
Query parameters
| Key | Value |
|---|---|
No query parameters.
Informazioni su questo strumento
URL Parser & Builder scompone qualsiasi URL nei suoi otto componenti RFC 3986 — scheme, userinfo, host, port, path, query, fragment e la forma codificata originale — e li presenta in un form modificabile. Si cambia qualsiasi campo e l'URL assemblato si aggiorna istantaneamente. La query string è mostrata come una tabella di coppie nome/valore, con il corretto percent-encoding applicato ai caratteri speciali.
Lo strumento gestisce anche le operazioni correlate: rilevamento punycode/IDN sull'host (un'etichetta xn-- si decodifica nella sua forma Unicode, un host Unicode si codifica in xn--), risoluzione di URL relativi contro una base (applicare ../foo?bar a https://example.com/a/b/c e ottenere https://example.com/a/foo?bar) e validazione contro la specifica WHATWG URL (che è più rigorosa di RFC 3986 in alcune aree, in particolare il parsing dell'authority).
Quando usare questo strumento
- Debug della gestione URL. Un redirect che arriva come
%25invece di%— trovare il passaggio di doppia codifica nello stack. - Costruzione di link sicuri. Costruire URL da input utente con il corretto escape anziché concatenazione di stringhe.
- Verifica di un URL sospetto. Decodificare tentativi di traversal
%2E%2Eoffuscati, trucchi omografi IDN e phishing userinfo in chiaro. - Lavorare con OAuth e redirect. Confermare che i parametri
redirect_urisiano codificati correttamente prima che il server di auth li rifiuti.
Sul percent-encoding
RFC 3986 riserva una manciata di caratteri con significato strutturale (:/?#[]@!$&'()*+,;=). All'interno di segmenti di path e valori di query devono essere percent-encoded quando appaiono come dati anziché come sintassi. I parser URL moderni lo fanno automaticamente; la concatenazione manuale di stringhe no. Se ci si ritrova a scrivere "?key=" + value nel codice, si ha quasi certamente un bug di iniezione — utilizzare invece URLSearchParams o il nostro builder.
Domande frequenti
Qual è la differenza tra userinfo e il path?
:// e l'host: https://user:[email protected]/path. È tecnicamente legale negli URL ma Chrome / Firefox lo rimuovono dalla barra degli indirizzi per prevenire il phishing (https://[email protected]). I client HTTP moderni avvertono o lo rifiutano. Se servono credenziali in un URL, codificarle correttamente e preferire header Authorization — userinfo negli URL è un odore di sicurezza.
Perché i valori della mia query string tornano con %20 invece degli spazi?
%20 (percent-encoding) o + (la più vecchia variante form-urlencoded per le query string). Entrambi si decodificano in uno spazio sul server. %20 è la forma universale; + funziona solo all'interno delle query string, mai nei path. Il nostro builder usa %20 ovunque per sicurezza.
Come funziona la risoluzione di URL relativi?
./ e ../ nel path risultante. Esempi: ../x applicato a /a/b/c/d dà /a/b/x; //other.com/path applicato a qualsiasi cosa dà //other.com/path (un riferimento "scheme-relative"). Il nostro strumento esegue questo algoritmo e mostra l'URL risolto.
Il parser rileva attacchi omografi IDN?
xn--) e li decodifica in Unicode, in modo da vedere quali caratteri sono effettivamente presenti. Un "google.com" con un о cirillico al posto della o latina si decodificherà in una forma Unicode che contiene visibilmente il sosia. Si combini con lo strumento Punycode per un'ispezione più approfondita; anche i browser moderni li visualizzano nella barra degli indirizzi.