Парсер URL

Парсер URL, це безкоштовний інструмент, який розділяє вебадресу на схему, шлях і рядок запиту.

Які компоненти URL виділяє парсер?

Парсер URL визначає структурні компоненти вебадреси, тож тобі не доведеться розділяти її вручну. Інструмент повертає три поля, отримані за допомогою PHP-функції parse_url.

• Схема визначає протокол або схему адресації, наприклад https чи http.
• Шлях містить шлях, наприклад /account/orders/42.
• Запит містить текст після знака питання, з якого починається компонент запиту, і до першого незакодованого знака решітки, наприклад page=2&sort=date.

Розбір URL корисний під час перевірки запитів до API, URL зворотного виклику, журналів застосунків або сторонніх даних. Він дає змогу відокремити інформацію про маршрут від параметрів запиту перед налагодженням, журналюванням або перетворенням адреси.

Серед повернених полів немає окремого імені хоста, порту чи фрагмента. Якщо тобі потрібні ці компоненти, скористайся у своєму застосунку повнофункціональною бібліотекою для розбору URL.

Як користуватися парсером URL?

Введи повний або частковий URL і переглянь значення схеми, шляху та запиту, які поверне інструмент. Повна абсолютна адреса зазвичай дає найзрозуміліший результат, оскільки явно містить схему.

1. Скопіюй URL із браузера, відповіді API, запису вебхука або журналу сервера.
2. Додай рядок запиту, якщо потрібно перевірити назви або значення параметрів.
3. Порівняй отриманий шлях із маршрутом, який очікує твій застосунок.
4. Перевір, чи є схема та запит там, де вони потрібні для твоєї інтеграції.

Обробка відбувається на сервері. Введені дані передаються на сервер через HTTPS і не зберігаються. Попри це, не надсилай чинні токени доступу, підписані посилання для завантаження, ідентифікатори сеансів або інші облікові дані, якщо для перевірки достатньо відредагованого прикладу з прихованими конфіденційними значеннями.

Приклади та пояснення результатів

Для абсолютного URL API парсер відокремлює протокол від маршруту та необробленого рядка запиту.

Вхідні дані https://api.example.co.uk/v1/orders/42?expand=items&currency=GBP

Схема https

Шлях /v1/orders/42

Запит expand=items&currency=GBP

Запит повертається як один компонент. За поширеними правилами кодування форм і рядків запиту амперсанд розділяє поля, а перший знак рівності в кожному полі відокремлює назву від значення. Сам розбір URL не підтверджує, що expand або currency є параметром, який підтримує API.

Відносне посилання також може містити шлях і запит без зазначення схеми.

Вхідні дані /search?q=red%20shoes&page=2

Схема no scheme component

Шлях /search

Запит q=red%20shoes&page=2

Відсутність схеми часто є нормальною для посилань, створених у межах одного сайту. Однак якщо дані мають містити абсолютні URL зворотного виклику, такий результат може вказувати на відсутній префікс https://.

Цей парсер не перевіряє URL на дійсність. Він допомагає помітити підозрілу структуру, наприклад відсутню схему, неочікуваний шлях або текст запиту не в тому місці. Проте успішний розбір не доводить, що адреса існує, визначається через DNS або повертає успішну HTTP-відповідь.

Як обробляються пробіли, розділові знаки та незвичні дані?

Зарезервовані символи впливають на поділ URL, а закодовані символи зазвичай залишаються в тому компоненті, де вони розташовані. Парсер лише розділяє компоненти, не декодуючи й не нормалізуючи їхній вміст.

• Незакодований знак питання починає компонент запиту. Якщо буквальний знак питання має бути частиною даних поза наявним запитом, його слід закодувати у відсотковому форматі, інакше він спрацює як роздільник запиту.
• Амперсанд зазвичай розділяє параметри запиту, але цей інструмент повертає весь рядок запиту, не розбираючи його на окремі параметри.
• Незакодований знак решітки (#) у стандартному синтаксисі URL є роздільником фрагмента. Дані фрагмента не входять до полів, які повертає цей інструмент.
• Пробіли зазвичай потрібно кодувати, найчастіше як %20. Знак плюса може позначати пробіл у даних запиту, закодованих як дані форми, але таке тлумачення належить до декодування запиту, а не до розбору URL.
• Символи з діакритичними знаками та текст не латиницею у шляху чи запиті слід кодувати у відсотковому форматі UTF-8, якщо цього вимагає система-одержувач. Для широкої сумісності з протоколами інтернаціоналізовані доменні імена використовують у формі, сумісній з ASCII.
• Числа не мають особливих правил розбору. Вони залишаються звичайними символами в шляху або значенні запиту.

Порожнє поле не містить корисної структури URL для перевірки. Для дуже довгих URL також можуть діяти обмеження в інших системах, зокрема у браузерах, вебсерверах, проксі та фреймворках застосунків. Цей інструмент не визначає, чи прийме інша система URL певної довжини.

Коли варто розбирати URL?

Розбір доречний, коли потрібно з'ясувати структуру адреси до того, як її обробить код або інфраструктура. Типові приклади: перевірка адрес зворотного виклику вебхуків перед розгортанням, аналіз цільових адрес перенаправлення, відокремлення маршрутів API від фільтрів і читання URL, скопійованих із журналів зворотного проксі.

Зазвичай розбір не потрібен, якщо відомий, уже структурований URL оброблятиме лише машина, а застосунок уже використовує бібліотеку для роботи з URL. Це також не та операція, яка потрібна для перевірки доступності, переходу за перенаправленнями, декодування всіх параметрів запиту або перевірки надійності домену.

Для регулярної або автоматизованої роботи використовуй засоби для URL, вбудовані у твоє середовище. У PHP є parse_url, у браузерному JavaScript доступний інтерфейс URL, Node.js надає клас URL, а Python містить urllib.parse. Для обробки файла журналу з тисячами адрес невеликий скрипт командного рядка підійде краще за ручний розбір.

Не розбирай URL лише для того, щоб змінити формат адреси, яка вже має точний вигляд, потрібний системі-одержувачу. Повторне кодування або перебудова адрес без чіткої причини може змінити підписи запитів, дубльовані параметри або зарезервовані символи.

Поширені запитання

Чи можна розібрати URL без http або https?

Так, PHP-функція parse_url може обробляти відносні посилання та часткові URL, однак якщо схему не вказано, у результаті її не буде. Будь уважний з адресами, що починаються з двох скісних рисок і використовують схему з контексту, оскільки їхнє значення залежить від документа або застосунку, у якому вони містяться.

Чи збережуться повторювані параметри запиту?

Запит повертається як необроблений компонент, тому повторювані назви можуть зберегтися у вихідній послідовності. Те, як значення на зразок tag=red&tag=blue перетворяться на масиви або окремі значення, залежить від парсера рядка запиту, який використовуватиметься далі.

Чи безпечно вставляти підписаний URL?

Введені дані передаються через HTTPS і не зберігаються, але підписаний URL усе одно може надавати доступ до приватного вмісту, поки його підпис чинний. Приховай токен або заміни ім'я хоста й значення репрезентативними заповнювачами, якщо точні облікові дані не потрібні.

Чому URL здається правильним, але в моєму застосунку працює інакше?

Відмінності можуть виникати через особливості декодування запитів у конкретному фреймворку та нормалізацію Unicode. Після розбору застосунки також можуть використовувати додаткові правила, зокрема списки дозволених імен хостів та обмеження перенаправлень. Порівняй необроблений URL байт за байтом, а потім перевір, що саме застосунок декодує або переписує перед надсиланням запиту.