Parser URL

Parser URL to bezpłatne narzędzie, które rozdziela adres internetowy na schemat, ścieżkę i ciąg zapytania.

Jakie elementy adresu wyodrębnia parser URL?

Parser URL rozpoznaje elementy struktury adresu internetowego, dzięki czemu nie musisz dzielić go ręcznie. Narzędzie zwraca trzy pola uzyskane za pomocą funkcji parse_url w PHP.

• Schemat wskazuje protokół lub schemat adresowania, na przykład https albo http.
• Ścieżka wskazuje część adresu zawierającą ścieżkę, na przykład /account/orders/42.
• Zapytanie zawiera tekst po znaku zapytania rozpoczynającym tę część adresu i przed niezakodowanym znakiem kratki, na przykład page=2&sort=date.

Parsowanie przydaje się podczas sprawdzania żądań API, adresów wywołań zwrotnych, dzienników aplikacji i danych pochodzących od zewnętrznych dostawców. Pozwala odróżnić informacje o routingu od parametrów zapytania przed debugowaniem, rejestrowaniem lub przekształcaniem adresu.

Zwracane pola nie obejmują osobno nazwy hosta, portu ani fragmentu. Jeśli potrzebujesz tych elementów, skorzystaj w swojej aplikacji z bardziej rozbudowanej biblioteki do parsowania adresów URL.

Jak używać parsera URL?

Wpisz pełny lub częściowy adres URL, a następnie sprawdź zwrócone wartości schematu, ścieżki i zapytania. Pełny adres bezwzględny zwykle daje najbardziej jednoznaczny wynik, ponieważ jawnie określa schemat.

1. Skopiuj adres URL z przeglądarki, odpowiedzi API, rekordu webhooka lub dziennika serwera.
2. Uwzględnij ciąg zapytania, jeśli chcesz sprawdzić nazwy albo wartości parametrów.
3. Porównaj zwróconą ścieżkę z trasą oczekiwaną przez aplikację.
4. Sprawdź, czy schemat i zapytanie są obecne tam, gdzie wymaga ich integracja.

Przetwarzanie odbywa się na serwerze. Wprowadzone dane są przesyłane na serwer przez HTTPS i nie są przechowywane. Mimo to nie podawaj aktywnych tokenów dostępu, podpisanych linków do pobierania, identyfikatorów sesji ani innych danych uwierzytelniających, jeśli do uzyskania odpowiedzi wystarczy przykład z ukrytymi poufnymi informacjami.

Przykłady i interpretacja wyników

W przypadku bezwzględnego adresu API parser oddziela protokół od trasy i surowego ciągu zapytania.

Dane wejściowe https://api.example.co.uk/v1/orders/42?expand=items&currency=GBP

Schemat https

Ścieżka /v1/orders/42

Zapytanie expand=items&currency=GBP

Zapytanie jest zwracane jako jeden element. Zgodnie z powszechną konwencją stosowaną w formularzach i ciągach zapytań znak ampersand oddziela pola, a pierwszy znak równości w każdym polu rozdziela jego nazwę i wartość. Samo sparsowanie adresu URL nie potwierdza, że expand lub currency jest parametrem rozpoznawanym przez API.

Odwołanie względne również może zawierać ścieżkę i zapytanie bez określania schematu.

Dane wejściowe /search?q=red%20shoes&page=2

Schemat no scheme component

Ścieżka /search

Zapytanie q=red%20shoes&page=2

Brak schematu jest często prawidłowy w przypadku linków tworzonych w obrębie jednej witryny. Jeśli jednak dane powinny zawierać bezwzględne adresy wywołań zwrotnych, taki sam wynik może wskazywać na brak prefiksu https://.

Ten parser nie służy do sprawdzania poprawności adresów URL. Może pomóc wykryć podejrzaną strukturę, na przykład brak schematu, nieoczekiwaną ścieżkę lub tekst zapytania w niewłaściwym miejscu. Wynik parsowania nie dowodzi jednak, że adres istnieje, jest rozpoznawany przez DNS ani że zwraca poprawną odpowiedź HTTP.

Co dzieje się ze spacjami, znakami interpunkcyjnymi i nietypowymi danymi?

Znaki zastrzeżone wpływają na sposób podziału adresu URL, natomiast znaki zakodowane zasadniczo pozostają częścią elementu, w którym występują. Parser rozdziela elementy adresu, ale nie dekoduje ani nie normalizuje ich zawartości.

• Niezakodowany znak zapytania rozpoczyna część zapytania. Jeśli dosłowny znak zapytania ma być danymi poza istniejącym zapytaniem, należy go zakodować procentowo, o ile bez kodowania zostałby potraktowany jako separator zapytania.
• Znak ampersand zwykle oddziela parametry zapytania, ale narzędzie zwraca cały ciąg zapytania zamiast interpretować każdy parametr osobno.
• Niezakodowany znak kratki (#) jest separatorem fragmentu w standardowej składni URL. Dane fragmentu nie należą do pól zwracanych przez to narzędzie.
• Spacje powinny być zwykle kodowane, najczęściej jako %20. Znak plus może oznaczać spację w danych zapytania zakodowanych jak formularz, ale taka interpretacja należy do dekodowania zapytania, a nie do parsowania adresu URL.
• Znaki diakrytyczne i znaki spoza alfabetu łacińskiego w ścieżce lub zapytaniu powinny być kodowane procentowo w UTF-8, jeśli wymaga tego system odbierający. Internacjonalizowane nazwy domen korzystają z postaci zgodnej z ASCII, aby zapewnić szeroką zgodność z protokołami.
• Liczby nie są traktowane w szczególny sposób. Pozostają zwykłymi znakami w ścieżce lub wartości zapytania.

Puste dane wejściowe nie zawierają użytecznej struktury URL, którą można sprawdzić. Bardzo długie adresy URL mogą również podlegać ograniczeniom w innych miejscach, między innymi w przeglądarkach, serwerach WWW, serwerach proxy i frameworkach aplikacji. Narzędzie nie określa, czy inny system zaakceptuje adres URL o konkretnej długości.

Kiedy warto parsować adres URL?

Parsowanie ma sens, gdy chcesz ustalić strukturę adresu, zanim zostanie on przetworzony przez kod lub infrastrukturę. Typowe zastosowania to sprawdzanie adresów wywołań zwrotnych webhooków przed wdrożeniem, kontrolowanie celów przekierowań, oddzielanie tras API od filtrów oraz odczytywanie adresów URL skopiowanych z dzienników odwrotnego serwera proxy.

Zwykle nie jest to potrzebne, jeśli znany adres URL o ustalonej strukturze będzie przetwarzany wyłącznie przez maszynę, a aplikacja korzysta już z biblioteki do obsługi URL. Parsowanie nie jest też właściwą operacją, jeśli chcesz sprawdzić dostępność adresu, śledzić przekierowania, zdekodować wszystkie parametry zapytania lub zweryfikować wiarygodność domeny.

Do zadań powtarzalnych lub zautomatyzowanych używaj funkcji obsługi URL dostępnych w danym środowisku. PHP udostępnia parse_url, JavaScript w przeglądarce ma interfejs URL, Node.js oferuje klasę URL, a Python zawiera urllib.parse. Przy przetwarzaniu pliku dziennika z tysiącami adresów lepiej sprawdzi się niewielki skrypt uruchamiany z wiersza poleceń niż ręczne parsowanie.

Nie parsuj adresu URL tylko po to, aby zmienić jego format, jeśli ma już dokładnie taką postać, jakiej wymaga system odbierający. Ponowne kodowanie lub przebudowywanie adresów bez wyraźnej potrzeby może zmienić podpisy zapytań, powtarzające się parametry albo znaki zastrzeżone.

Najczęściej zadawane pytania

Czy mogę sparsować adres URL bez http lub https?

Tak. Funkcja parse_url w PHP potrafi interpretować odwołania względne i częściowe adresy URL, ale jeśli nie podano schematu, nie będzie on dostępny w wyniku. Zachowaj ostrożność w przypadku adresów względnych względem schematu, które zaczynają się od dwóch ukośników, ponieważ ich znaczenie zależy od dokumentu lub aplikacji, w których występują.

Czy powtarzające się parametry zapytania zostaną zachowane?

Zapytanie jest zwracane jako surowy element, więc powtarzające się nazwy mogą pozostać w pierwotnej kolejności. Sposób przekształcania wartości takich jak tag=red&tag=blue w tablice lub osobne wartości zależy od parsera ciągu zapytania użytego na dalszym etapie.

Czy wklejenie podpisanego adresu URL jest bezpieczne?

Dane wejściowe są przesyłane przez HTTPS i nie są przechowywane, ale podpisany adres URL może zapewniać dostęp do prywatnych treści, dopóki jego podpis pozostaje ważny. Jeśli dokładne dane uwierzytelniające nie są potrzebne, ukryj token albo zastąp nazwę hosta i wartości reprezentatywnymi symbolami zastępczymi.

Dlaczego poprawnie wyglądający adres URL działa inaczej w mojej aplikacji?

Różnice mogą wynikać ze sposobu dekodowania zapytań i normalizacji Unicode w danym frameworku. Po sparsowaniu aplikacje mogą też stosować dodatkowe reguły, w tym listy dozwolonych nazw hostów oraz ograniczenia przekierowań. Porównaj surowy adres URL bajt po bajcie, a następnie sprawdź, co aplikacja dekoduje lub przepisuje przed wysłaniem żądania.