URL

Znormalizowany

Czym jest Normalizator URL?

Dwa adresy URL, które są „te same”, ale w porównaniu wychodzą różne z powodu wielkości liter albo kolejności parametrów — to jeden z tych bugów, które potrafią pochłonąć pół popołudnia. HTTPS://Example.com/page i https://example.com/page wskazują ten sam zasób, ale porównanie napisów twierdzi, że się różnią. Normalizator bierze URL i tworzy jego kanoniczną postać zgodnie z RFC 3986 §6 oraz WHATWG URL Standard, dzięki czemu dwa URL-e o tym samym znaczeniu dają ten sam ciąg.

Wykonywane normalizacje są nudne, ale ważne: schemat i host małymi literami (zgodnie z RFC 3986 §6.2.2.1 są niewrażliwe na wielkość liter), usunięcie domyślnych portów (:443 dla https, :80 dla http), zdekodowanie znaków niezarezerwowanych w kodowaniu procentowym (%41 → A), posortowanie parametrów zapytania alfabetycznie po kluczu, usunięcie pustego fragmentu (# bez nic za nim) oraz rozwiązanie segmentów ścieżki . / ... Wynikowy JSON zawiera znormalizowany URL, oryginał i tablicę changes wymieniającą dokładnie, co zostało przepisane — widać dzięki temu, dlaczego dwa URL-e z pozoru różne są w istocie takie same.

Wszystko działa w Twojej przeglądarce, korzystając ze standardowego API URL oraz URLSearchParams — bez serwera, bez logów. Jeśli wejście jest już kanoniczne, tablica changes jest pusta i to jest odpowiedź: nic do zrobienia. Przydaje się jako kontrola przed publikacją sitemapy albo ustawieniem <link rel="canonical">.

Jak korzystać z Normalizatora URL

Trzy kroki. Każdy odpowiada przyciskowi na tej stronie.

Wklej URL lub załaduj przykład

Wrzuć URL do lewego panelu. Kliknij Przykład, aby wczytać realistycznie zabałaganiony URL — schemat i host wielkimi literami, domyślny port, pomieszana kolejność query, spacja w kodowaniu procentowym, pusty fragment. Przykładowy URL:

HTTPS://API.Shop.Example.com:443/v1/orders/?status=active&customer=Ava%20Chen&page=2#

Internacjonalizowane nazwy domen (IDN) są konwertowane na Punycode przez konstruktor URL — to postać faktycznie wysyłana w sieci, zgodnie z regułami normalizacji URI. Userinfo (user:pass@host) jest zachowywane, jeśli występuje.

Przeczytaj wynik

Prawy panel pokazuje JSON z trzema polami: normalized (kanoniczny URL), original (to, co wkleiłeś, po przycięciu) oraz changes — tablica wpisów { rule, from, to } z każdą zmianą. Jeśli changes jest pusta, URL już był kanoniczny.

Skopiuj lub pobierz

Kliknij Kopiuj, aby przenieść JSON do schowka, albo Pobierz, aby zapisać go jako plik .json. Minifikuj ściska JSON do jednej linii. Użyj Wyczyść w panelu wejścia, aby zacząć od nowa.

Kiedy naprawdę tego użyjesz

Klucze cache i deduplikacja w analityce

Twój dashboard analityczny widzi Example.com/page i example.com/page jako dwa różne wiersze. Cache CDN tak samo. Znormalizuj na wejściu i duplikat znika. Ten sam trik, gdy budujesz skracarkę URL-i albo deduplikator zakładek — przechowuj postać znormalizowaną jako klucz wyszukiwania.

Kanoniczne URL-e dla SEO

Wyszukiwarki karają duplikaty treści, gdy ta sama strona jest dostępna pod wieloma URL-ami. Twój tag <link rel="canonical"> i URL-e w sitemap.xml powinny pasować do jednej znormalizowanej postaci. Wytyczne Google dotyczące kanonikalizacji opisują reguły; to narzędzie to najszybszy sposób na ich ręczne zastosowanie.

Porównywanie dwóch URL-i pod kątem równości

Piszesz wykrywacz pętli przekierowań albo testujesz webhook. Dwa URL-e są „te same”, jeśli ich postacie znormalizowane się zgadzają. Porównuj napisy po normalizacji — nie buduj własnej funkcji równości na URL.toString(), bo ona nie sortuje parametrów zapytania ani nie usuwa portów domyślnych.

Czyszczenie URL-i przed zapisem lub wyświetleniem

Użytkownik wkleja HTTPS://www.SHOP.com:443/cart/?b=2&a=1# w Twoim formularzu. Nie chcesz takiego wpisu w bazie i tym bardziej nie chcesz wysyłać go mailem. Najpierw znormalizuj, potem zapisz czystą postać. URL-e widziane przez klientów stają się przewidywalne.

Częste pytania

Co jeśli mój URL jest już kanoniczny?

Zobaczysz ten sam URL w normalized i w original, a tablica changes będzie pusta ("changes": []). To jest odpowiedź — nie było czego przepisywać. Strona w tym przypadku nie rzuca wyjątku i nie pokazuje błędu.

Czy ścieżka jest modyfikowana poza usunięciem końcowego ukośnika z roota?

Praktycznie nie. Segmenty . i .. są rozwiązywane (konstruktor URL robi to automatycznie — RFC 3986 §5.2.4 nazywa to „remove dot segments”). Końcowe ukośniki są usuwane tylko wtedy, gdy ścieżka to samo /; /v1/orders/ pozostaje /v1/orders/, bo RFC 3986 mówi, że końcowe ukośniki mogą mieć znaczenie. Frameworki serwerowe potrafią traktować je jako różne trasy.

Dlaczego moje parametry zapytania są sortowane? Zależało mi na kolejności.

W RFC 3986 kolejność query nie jest semantycznie istotna — ?a=1&b=2 i ?b=2&a=1 są równoważne na poziomie URL. Sortowanie alfabetyczne daje stabilną kanoniczną postać, dzięki czemu dwa równoważne URL-e zgadzają się bajt w bajt. Jeśli Twoja aplikacja faktycznie zależy od kolejności parametrów (nie powinna, ale systemy legacy bywają takie), ten normalizator złamie to założenie — nie normalizuj URL-i, które trafiają do serwera dbającego o kolejność.

Dlaczego %20 czasem zmienia się na + po normalizacji?

Zarówno %20, jak i + oznaczają spację w query string (zgodnie z regułami application/x-www-form-urlencoded, których do serializacji używa URLSearchParams). Gdy obiekt URLSearchParams ponownie serializuje query, używa +. Dla każdego standardowego parsera URL są semantycznie identyczne; jeśli Twój serwer traktuje je inaczej, to bug po stronie serwera.

Co dzieje się z domenami internacjonalizowanymi typu café.example?

Konstruktor URL konwertuje host na Punycode — caf%C3%A9.example staje się xn--caf-dma.example. To postać, w jakiej URL faktycznie zostałby wysłany przez DNS, i to właśnie określa RFC 3987 / specyfikacja WHATWG. Artykuł Wikipedii o normalizacji URI opisuje obsługę IDN, jeśli chcesz szczegółów.

Czy jest bezpieczny dla URL-i z poświadczeniami (user:pass@host)?

Parsowanie odbywa się w całości w Twojej przeglądarce — nic nie jest nigdzie wysyłane. Userinfo jest zachowywane podczas normalizacji. Czy w ogóle powinno się przekazywać poświadczenia w URL-u, to inna sprawa — większość przeglądarek i klientów HTTP dziś usuwa userinfo lub ostrzega o tym ze względów bezpieczeństwa, a zwykle lepiej użyć nagłówka Authorization.

Czy usuwa zduplikowane parametry zapytania?

Nie. ?tag=red&tag=red pozostaje ?tag=red&tag=red. Powtarzające się klucze mogą mieć znaczenie (niektóre API używają ich do tablic) i usunięcie duplikatów zmieniłoby semantykę. Sortowanie jest stabilne, więc w obrębie tego samego klucza zachowywana jest oryginalna kolejność.

Inne narzędzia URL i JSON

Normalizacja to jedna operacja. Oto co naturalnie z nią współpracuje: