Parser i konstruktor URL
Rozkłada URL na 8 komponentów z tabelą query i detekcją IDN/Punycode. Buduje URL. Resolver względny.
Resolved
Query parameters
| Key | Value |
|---|---|
No query parameters.
O tym narzędziu
URL Parser & Builder rozkłada dowolny URL na osiem komponentów RFC 3986 — scheme, userinfo, host, port, path, query, fragment i oryginalną-zakodowaną formę — i prezentuje je w edytowalnej formie. Zmień dowolne pole, a złożony URL aktualizuje się natychmiast. Query string jest pokazany jako tabela par name/value, z prawidłowo zastosowanym percent-encoding dla znaków specjalnych.
Narzędzie obsługuje też powiązane operacje: detekcja punycode/IDN na hoście (etykieta xn-- dekoduje się do swojej formy Unicode, host Unicode koduje się do xn--), rozwiązywanie relative-URL wobec bazy (zastosuj ../foo?bar do https://example.com/a/b/c i dostań https://example.com/a/foo?bar) i walidacja wobec specyfikacji WHATWG URL (która jest stricter niż RFC 3986 w niektórych obszarach, zwłaszcza parsowaniu authority).
Kiedy używać tego narzędzia
- Debugowanie obsługi URL. Przekierowanie, które przybywa jako
%25zamiast%— znajdź krok podwójnego kodowania w swoim stacku. - Budowanie bezpiecznych linków. Konstruuj URL-e z user inputu z prawidłowym escapowaniem zamiast konkatenacji stringów.
- Weryfikacja podejrzanego URL. Zdekoduj zaciemnione próby traversalu
%2E%2E, triki homograficzne IDN i phishing userinfo na widoku. - Praca z OAuth i przekierowaniami. Potwierdź, że parametry
redirect_urisą poprawnie zakodowane, zanim serwer auth je odrzuci.
O percent-encoding
RFC 3986 rezerwuje garść znaków ze znaczeniem strukturalnym (:/?#[]@!$&'()*+,;=). Wewnątrz segmentów path i wartości query muszą być percent-encoded, gdy pojawiają się jako dane, nie składnia. Nowoczesne parsery URL robią to automatycznie; ręczna konkatenacja stringów nie. Jeśli przyłapujesz się na pisaniu "?key=" + value w kodzie, prawie na pewno masz bug injection — użyj URLSearchParams lub naszego buildera.
Najczęstsze pytania
Czym różni się userinfo od path?
:// a hostem: https://user:[email protected]/path. Jest technicznie legalne w URL-ach, ale Chrome / Firefox stripują to z paska adresu, by zapobiec phishingowi (https://[email protected]). Nowoczesne klienty HTTP ostrzegają lub odmawiają. Jeśli potrzebujesz credentiali w URL, zakoduj je prawidłowo i preferuj nagłówki Authorization — userinfo w URL-ach to security smell.
Dlaczego moje wartości query-string wracają z %20 zamiast spacji?
%20 (percent-encoding), albo + (starszy form-urlencoded wariant dla query strings). Oba dekodują się do spacji po stronie serwera. %20 to uniwersalna forma; + działa tylko wewnątrz query strings, nigdy w ścieżkach. Nasz builder używa %20 wszędzie dla bezpieczeństwa.
Jak działa rozwiązywanie relative URL?
./ i ../ w wynikowej ścieżce. Przykłady: ../x zastosowane do /a/b/c/d daje /a/b/x; //other.com/path zastosowane do czegokolwiek daje //other.com/path (referencja "scheme-relative"). Nasze narzędzie uruchamia ten algorytm i pokazuje rozwiązany URL.
Czy parser wykrywa ataki homograficzne IDN?
xn--) i dekoduje je do Unicode, byś mógł zobaczyć, które znaki są faktycznie obecne. "google.com" z cyrylicką о zamiast łacińskiej o zdekoduje się do formy Unicode, która widocznie zawiera podróbkę. Połącz z narzędziem Punycode dla głębszej inspekcji; nowoczesne przeglądarki też wyświetlają to w pasku adresu.