Encoders & Utilities

URL Parser & Builder

Розбирає URL на 8 компонентів з query-таблицею і IDN/Punycode. Будує URL. Relative-резолвер.

Protocol Hostname

Port (optional) Path

Username (optional) Password (optional)

Fragment / hash (optional)

Query parameters

Про цей інструмент

URL Parser & Builder розкладає будь-яку URL на її вісім RFC 3986-компонентів — scheme, userinfo, host, port, path, query, fragment і оригінально-encoded-форму — і подає їх у редагованій формі. Змініть будь-яке поле, і зібрана URL оновлюється миттєво. Query-string показано як таблицю name/value-пар із правильним percent-encoding на спецсимволах.

Інструмент також обробляє пов'язані операції: punycode/IDN-детекцію на host (label xn-- декодується в Unicode-форму, Unicode-host кодується в xn--), relative-URL resolution проти base (застосуйте ../foo?bar до https://example.com/a/b/c і отримайте https://example.com/a/foo?bar) і валідацію проти WHATWG URL-специфікації (яка строгіша за RFC 3986 у деяких місцях, особливо authority parsing).

Коли використовувати цей інструмент

Дебаг URL-обробки. Redirect, що приходить як %25 замість % — знайдіть double-encoding-крок у своєму стеку.
Побудова безпечних посилань. Конструюйте URL з user-input із правильним екрануванням замість string-конкатенації.
Верифікація підозрілої URL. Декодуйте obfuscated %2E%2E traversal-спроби, IDN homograph-трюки і userinfo-фішинг у відкритому вигляді.
Робота з OAuth і redirects. Підтвердіть, що redirect_uri-параметри правильно encoded, перш ніж auth-сервер їх відкине.

Про percent-encoding

RFC 3986 резервує жменьку символів зі структурним значенням (:/?#[]@!$&'()*+,;=). Усередині path-сегментів і query-values вони мають бути percent-encoded, коли з'являються як дані, а не синтаксис. Сучасні URL-парсери роблять це автоматично; ручна string-конкатенація — ні. Якщо застаєте себе на написанні "?key=" + value в коді, у вас майже напевно injection-баг — використовуйте URLSearchParams або наш builder.

Часті запитання

Яка різниця між userinfo і path?

Userinfo — все між :// і host: https://user:[email protected]/path. Це технічно легально в URL, але Chrome / Firefox стрипають його з адресного бару, щоб запобігти фішингу (https://[email protected]). Сучасні HTTP-клієнти попереджають або відмовляють. Якщо потрібні credentials у URL, encode-те їх правильно і надавайте перевагу Authorization-заголовкам — userinfo в URL — security smell.

Чому query-string-значення повертаються з %20 замість пробілів?

Бо пробіли не легальні символи в URL — вони мають бути encoded або як %20 (percent-encoding), або як + (старша form-urlencoded-форма для query-strings). Обидва декодуються в пробіл на сервері. %20 — універсальна форма; + працює лише в query-strings, ніколи в paths. Наш builder використовує %20 усюди задля безпеки.

Як працює relative-URL resolution?

RFC 3986 §5 специфікує алгоритм: розбийте base URL на компоненти, замініть ті компоненти, що надає relative URL, і нормалізуйте ./ і ../ у результуючому шляху. Приклади: ../x, застосоване до /a/b/c/d, дає /a/b/x; //other.com/path, застосоване до чогось, дає //other.com/path («scheme-relative»-reference). Наш інструмент запускає цей алгоритм і показує resolved-URL.

Чи детектує парсер IDN homograph-атаки?

Він детектить punycode-encoded hosts (labels xn--) і декодує їх у Unicode, тож можна побачити, які символи реально присутні. «google.com» з кириличним о замість латинського o декодується в Unicode-форму, що видимо містить look-alike. Комбінуйте з Punycode-інструментом для глибшої інспекції; сучасні браузери також показують це в address-bar.