Naprawiacz URL
Naprawiaj uszkodzone adresy URL online — typograficzne cudzysłowy, brakujące https, podwójne ukośniki, zmieszane kodowanie, znaki nowej linii wklejone z Worda lub Slacka.
Czym jest Naprawiacz URL?
Skopiowałeś link z maila, dokumentu Worda, wiadomości na Slacku albo strony w Confluence — i teraz ma wokół siebie zaokrąglone cudzysłowy (" zamiast "), półpauzę (–) tam, gdzie powinien być myślnik, brak https:// z przodu albo zabłąkany znak nowej linii, który przeciął URL na dwie części. Wklej go tu i odzyskaj działający URL. Naprawiacz URL czyści szkody składniowe, jakie zostawia po sobie kopiuj-wklej, kierując się regułami standardu URL od WHATWG oraz RFC 3986.
Naprawiacz radzi sobie z rzeczami, które wyrażenie regularne musiałoby traktować jako przypadki specjalne w nieskończoność: typograficzne cudzysłowy, typograficzne myślniki, przypadkowe podwójne ukośniki w ścieżce, zmieszane lub podwójne kodowanie procentowe (więc %2520 wraca do %20, gdy to wyraźnie podwójne kodowanie), niezakodowane spacje oraz znaki CR/LF/tab, które wpadły do URL, bo ktoś nacisnął Enter w złym momencie. Nie zmyśla nazwy hosta, nie zmienia parametrów zapytania ani nie dodaje segmentu ścieżki, którego tam nie było. Wynik jest następnie walidowany regułami URL API przeglądarki, żebyś wiedział, że po drugiej stronie naprawdę się sparsuje. Międzynarodowe nazwy hostów (Unicode, IDN) są zachowywane zgodnie z RFC 3987.
Twój URL trafia na backend, żeby naprawa mogła się wykonać, i od razu wraca z powrotem. Nie logujemy danych wejściowych — URL-e często zawierają tokeny sesji, identyfikatory klientów albo inne rzeczy, których nie chcesz oglądać w pliku logu. Jeśli URL zawiera prawdziwy sekret (podpisany link S3, jednorazowy token uwierzytelniający), zrotuj go po wklejeniu gdziekolwiek — także tutaj.
Jak korzystać z Naprawiacza URL
Trzy kroki. Każdy odpowiada przyciskowi na tej stronie — nic nie jest ukryte.
Wklej uszkodzony URL albo wczytaj przykład
Wrzuć uszkodzony URL do edytora po lewej. Kliknij Przykładowy URL, aby wczytać celowo zepsuty przykład z zaokrąglonymi cudzysłowami, półpauzą, brakiem schematu i niezakodowaną spacją — czyli to, co naprawdę wkleja się z maila. Przykład uszkodzonego URL:
"shop.example.com/orders/ORD–1001?customer=Ava Chen"Zaokrąglone cudzysłowy z Worda otaczają URL, półpauza w segmencie ścieżki, brak schematu i dosłowna spacja w wartości zapytania. Cztery odrębne problemy w jednym krótkim wierszu.
Kliknij Napraw URL!!
Naciśnij zielony przycisk Napraw URL!!. Naprawiacz zdejmuje cudzysłowy z brzegu, zamienia półpauzę na myślnik, dokleja https:// i koduje spację procentowo, żeby wynik spełniał RFC 3986.
Skopiuj naprawiony URL
Prawy panel pokazuje wyczyszczony URL. Spójrz na niego, skopiuj i wklej w przeglądarce, w wywołaniu fetch(), w README albo w teście, który padał. Jeśli chcesz zobaczyć URL rozłożony na części, prześlij go potem przez nasz Parser URL.
Kiedy naprawdę z tego skorzystasz
Linki wklejane z maila albo Worda
Outlook i Word po cichu zamieniają proste cudzysłowy w zaokrąglone, a myślniki w półpauzy. URL wygląda dobrze w wiadomości, a psuje się w sekundę po wklejeniu do terminala. Naprawiacz cofa tę „mądrą” autokorektę, więc link znów działa.
URL-e oprawione w cudzysłowy przez logger
Logi aplikacyjne w formacie JSON uwielbiają drukować URL-e jako "https://api.example.com/v1/orders?id=ORD-1001". Kiedy chwytasz to do szybkiego curl, otaczające cudzysłowy lecą razem. Naprawiacz je zdejmuje i przestajesz się zastanawiać, czemu shell narzeka na niezamknięty cudzysłów.
Znaki nowej linii w środku URL od Slacka albo Jiry
Długie URL-e w Slacku, Jirze albo na stronie Confluence często się zawijają i przy kopiowaniu zabierają ze sobą zabłąkane \n. Ścieżka wygląda dobrze, ale fetch() odrzuca URL z błędem parsera. Naprawiacz spłaszcza znaki nowej linii i URL znów jest jednym ciągłym łańcuchem.
Podwójnie zakodowane querystringi
Kiedy URL przechodzi przez dwa systemy, które oba kodują procentowo, kończysz z %2520 tam, gdzie powinno być %20. Naprawiacz redukuje oczywiste podwójne kodowania do jednej warstwy — przydatne, gdy debugujesz łańcuchy przekierowań albo payloady webhooków.
Częste pytania
Czy mój URL jest gdzieś zapisywany albo wysyłany w miejsce, którego nie widzę?
Twój URL trafia na nasz backend, żeby naprawa mogła się wykonać, i od razu wraca. Nie logujemy samych danych wejściowych — URL-e często niosą tokeny sesji albo dane osobowe w ścieżce/zapytaniu. Logujemy, że doszło do naprawy, a nie co zostało naprawione. Jeśli URL zawiera prawdziwy sekret (podpisany link, token uwierzytelniający), traktuj go jako ujawniony od momentu, gdy wkleiłeś go do dowolnego narzędzia zewnętrznego — w tym tego — i zrotuj.
Jakie błędy URL faktycznie naprawia?
Te codzienne: brak schematu (domyślnie https://), zaokrąglone/typograficzne cudzysłowy wokół URL, półpauza lub myślnik tam, gdzie powinien być zwykły myślnik, przypadkowe // w ścieżce, podwójne kodowanie procentowe (%2520 → %20, gdy to ewidentne podwójne kodowanie), niezakodowane spacje w wartościach zapytania, znaki tab/CR/LF zostawione w URL przez edytor tekstu, oraz otaczające nawiasy ostre w stylu <https://example.com> z linków Markdown.
Czy zmieni mi wartości ścieżki, zapytania albo fragmentu?
Nie. Naprawiacz jest celowo zachowawczy. Nie wymyśla hosta, nie zgaduje brakującego TLD, nie dodaje ani nie usuwa segmentów ścieżki, nie dodaje ani nie usuwa parametrów zapytania, nie zmienia ich kolejności i nie wywala fragmentu. Dotyka tylko znaków, które są składniowo błędne. Jeśli na wejściu jest customer=Ava Chen, na wyjściu wychodzi customer=Ava%20Chen — ta sama wartość, tylko poprawnie zakodowana zgodnie z RFC 3986.
Czy obsługuje międzynarodowe (Unicode) nazwy domen?
Tak. Znaki Unicode w hoście albo w ścieżce są zachowywane jako Internationalized Resource Identifiers (forma IRI). Jeśli twoja aplikacja potrzebuje formy punycode (ASCII) hosta, przepuść wyczyszczony URL przez bibliotekę URL swojego języka — moduł url w Node, pakiet idna w Pythonie albo wbudowany konstruktor URL w przeglądarce dadzą ci obie formy.
A naprawdę długie URL-e?
Wejście ma limit 64 KB — czyli mniej więcej 64 000 znaków. Realne URL-e prawie zawsze mieszczą się poniżej 2 000 znaków; jeśli twój jest większy, zwykle jest tak, bo coś zostało dwukrotnie zakodowane w wielki blok, albo w querystringu siedzi binarny payload, który powinien być w ciele POST. Naprawiacz powie ci, że wejście jest za duże; najpierw przytnij albo przebuduj.
Zwrócił błąd zamiast naprawionego URL. Co teraz?
Niektóre wejścia są nie do uratowania — na przykład URL, w którym kompletnie brakuje hosta, albo taki, którego struktura jest tak zniekształcona, że model nie potrafi rozpoznać, o co chodziło. W takim przypadku spójrz na URL, popraw ręcznie oczywiste rzeczy (host i schemat to typowi podejrzani) i puść jeszcze raz. Możesz też wrzucić wynik do naszego Walidatora URL, żeby zobaczyć, na co dokładnie skarży się parser URL.
Inne narzędzia URL, które mogą się przydać
Naprawienie URL to jeden krok. Kiedy już parsuje się czysto, te narzędzia doprowadzą sprawę do końca: