Парсер URL

Парсер URL представляет собой бесплатный инструмент, который разделяет веб-адрес на схему, путь и строку запроса.

Какие части URL извлекает парсер?

Парсер URL извлекает структурные компоненты веб-адреса, поэтому тебе не приходится разделять строку вручную. Инструмент возвращает три поля, полученные с помощью функции parse_url в PHP.

• Схема: протокол или схема адресации, например 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?

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

Обычно разбор не нужен, если заранее известный и уже структурированный URL будет обрабатывать только программа, а приложение уже использует библиотеку для работы с URL. Разбор также не подходит, если требуется проверить доступность адреса, перейти по перенаправлениям, декодировать каждый параметр запроса или удостовериться в надежности домена.

Для регулярной или автоматизированной обработки используй средства работы с URL, встроенные в выбранную среду. В PHP есть parse_url, в браузерном JavaScript доступен интерфейс URL, Node.js предоставляет класс URL, а Python включает urllib.parse. Если нужно обработать журнал с тысячами адресов, небольшой скрипт командной строки подойдет лучше ручного разбора.

Не разбирай URL только ради изменения формата, если он уже представлен именно так, как требует принимающая система. Повторное кодирование или пересборка адреса без явной необходимости может изменить подписи запросов, повторяющиеся параметры или зарезервированные символы.

Часто задаваемые вопросы

Можно ли разобрать URL без http или https?

Да, функция parse_url в PHP умеет обрабатывать относительные ссылки и частичные URL, но если схема не была указана, в результате ее не будет. Будь внимателен с адресами относительно схемы, которые начинаются с двух косых черт: их смысл зависит от документа или приложения, где они используются.

Сохранятся ли повторяющиеся параметры запроса?

Да, запрос возвращается как исходный компонент, поэтому параметры с одинаковыми именами могут сохраниться в первоначальной последовательности. То, как значения вида tag=red&tag=blue будут преобразованы в массивы или отдельные значения, зависит от парсера строки запроса, который применяется после этого.

Безопасно ли вставлять подписанный URL?

Данные передаются по HTTPS и не сохраняются, но подписанный URL может предоставлять доступ к закрытому содержимому, пока его подпись остается действительной. Если точные учетные данные не нужны, скрой токен или замени имя хоста и значения подходящими заполнителями.

Почему правильный на вид URL иначе работает в моем приложении?

Причиной могут быть особенности декодирования запросов и нормализации Unicode в конкретной программной платформе. После разбора приложения также могут применять дополнительные правила, включая списки разрешенных имен хостов и ограничения перенаправлений. Сначала сравни исходные URL побайтово, а затем проверь, что именно приложение декодирует или переписывает перед отправкой запроса.