URL парсер

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

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

URL парсерът разпознава структурните компоненти на уеб адреса, без да се налага да разделяш текста ръчно. Инструментът връща три полета, получени чрез функцията parse_url на PHP.

• Схема посочва протокола или схемата за адресиране, например https или http.
• Път посочва компонента на пътя, например /account/orders/42.
• Заявка съдържа текста след въпросителния знак, с който започва компонентът на заявката, и преди всеки некодиран знак диез, например page=2&sort=date.

Парсирането е полезно при преглед на API заявки, URL адреси за обратно извикване, регистри на приложения или данни от трети страни. То ти позволява да отделиш информацията за маршрутизиране от параметрите на заявката, преди да отстраняваш грешки, да записваш данни в регистър или да преобразуваш адреса.

Върнатите полета не включват отделно име на хост, порт или фрагмент. Ако са ти нужни тези компоненти, използвай по-пълнофункционална библиотека за парсиране на URL адреси в приложението си.

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

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

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

Обработката се извършва на сървъра. Въведените данни се изпращат до него през HTTPS и не се съхраняват. Въпреки това не изпращай активни токени за достъп, подписани връзки за изтегляне, идентификатори на сесии или други данни за удостоверяване, когато редактиран пример без чувствителните стойности е достатъчен.

Примери и тълкуване на резултатите

При абсолютен API URL адрес парсерът отделя протокола от маршрута и необработения низ на заявката.

Вход 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 адрес?

Парсирането е полезно, когато трябва да установиш как е структуриран даден адрес, преди кодът или инфраструктурата да го обработи. Типични случаи са проверка на адреси за webhook обратно извикване преди внедряване, преглед на целите за пренасочване, отделяне на 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 адрес байт по байт, след което провери какво декодира или пренаписва приложението ти, преди да изпрати заявката.