Как валидировать URL с помощью регулярного выражения

Программирование упростило работу со структурированными и неструктурированными текстовыми данными. Инструменты вроде регулярных выражений и внешних библиотек делают проверку форматов более доступной.

Вы можете использовать большинство языков, включая Python и JavaScript, для быстрой валидации URL с помощью регулярного выражения. Приведённый ниже regex не идеален, но годится для базовой проверки привычных ссылок.

Важно: регулярные выражения ограничены по точности и преднамеренно упрощают многие случаи. Они удобны для первичной фильтрации входных данных, но не заменяют корректный парсинг и дополнительные проверки (например, проверку DNS, схемы, портов, кодировку и т. п.).

Регулярное выражение для проверки URL

В статье предлагается простое регулярное выражение, которое считает URL корректным при выполнении следующих условий:

1. Строка начинается с http или https, за которыми следует ://.
2. Совокупная длина поддомена и корневого домена — от 2 до 256 символов; разрешены буквенно-цифровые символы и ряд специальных символов.
3. TLD (домен верхнего уровня) содержит только буквы и составляет от 2 до 6 символов.
4. Конец строки может содержать путь, параметры и другие допустимые символы (повторяются 0 или более раз).

Ниже — вариант регулярного выражения для использования в JavaScript:

^(http(s):\/\/.)[-a-zA-Z0-9@:%._\+~#=]{2,256}\.[a-z]{2,6}\b([-a-zA-Z0-9@:%_\+.~#?&//=]*)$

И аналог для Python (обратите внимание на экранирование обратных слэшей в строковом литерале):

^((http|https)://)[-a-zA-Z0-9@:%._\\+~#?&//=]{2,256}\\.[a-z]{2,6}\\b([-a-zA-Z0-9@:%._\\+~#?&//=]*)$

Разбор компонентов выражения (кратко):

• (http|https):// — убеждаемся, что протокол http или https присутствует и за ним следует ://.
• [-a-zA-Z0-9@:%._\+~#?&//=] — множество символов, разрешённых в домене и в пути/параметрах.
• {2,256} — ограничение длины для части до точки (поддомен + домен).
• \. — литерал точки (разделитель домена и TLD).
• [a-z]{2,6} — домен верхнего уровня из 2–6 букв (латинских).
• \b — граница слова (граница между буквенно-цифровым и неалфавитным символом).
• • — повторение нуля или более раз для частей пути/параметров.
• ^ и $ — начало и конец строки соответственно.

Если вы неуверены в выражении, сначала изучите основы регулярных выражений. Они требуют практики; начните с простых примеров и постепенно усложняйте.

Примеры URL, которые покрывает это регулярное выражение

• https://www.something.com/
• http://www.something.com/
• https://www.something.edu.co.in
• http://www.url-with-path.com/path
• https://www.url-with-querystring.com/?url=has-querystring
• http://url-without-www-subdomain.com/
• https://mail.google.com

Использование регулярного выражения в реальной программе

Код в этом разделе лежит в репозитории на GitHub и распространяется под лицензией MIT — используйте свободно.

Пример на Python:

import re  
   
def validateURL(url):  
    regex = "^((http|https)://)[-a-zA-Z0-9@:%._\\+~#?&//=]{2,256}\\.[a-z]{2,6}\\b([-a-zA-Z0-9@:%._\\+~#?&//=]*)$"  
    r = re.compile(regex)  
   
    if (re.search(r, url)):  
        print("Valid")  
    else:  
        print("Not Valid")  
   
url1 = "https://www.linkedin.com/"  
validateURL(url1)  
url2 = "http://apple"  
validateURL(url2)  
url3 = "iywegfuykegf"  
validateURL(url3)  
url4 = "https://w"  
validateURL(url4)

Этот код использует re.compile() для компиляции шаблона, затем re.search() для поиска соответствия. re.search() возвращает первое совпадение; если нужен список всех совпадений, используйте re.findall().

Результат выполнения примера: первая строка распознаётся как валидный URL, остальные — нет.

Пример на JavaScript:

function validateURL(url) {  
   if(/^(http(s):\/\/.)[-a-zA-Z0-9@:%._\+~#=]{2,256}\.[a-z]{2,6}\b([-a-zA-Z0-9@:%_\+.~#?&//=]*)$/g.test(url)) {  
        console.log('Valid');  
    } else {  
        console.log('Not Valid');  
    }  
}  
   
validateURL("https://www.linkedin.com/");  
validateURL("http://apple");  
validateURL("iywegfuykegf");  
validateURL("https://w");

Этот код проверяет строки с помощью метода test(). В браузере или в Node.js он напечатает “Valid” или “Not Valid” для каждого вызова.

Ограничения и когда это не работает

Важно понимать, какие случаи этот regex не покрывает:

• URL с IP-адресом в хосте, например http://127.0.0.1:8000 — нужен другой шаблон.
• Непривычные схемы: ftp://, file://, data: и т. п. они не распознаются.
• Международные доменные имена (IDN) с не-ASCII символами (кириллица, иероглифы) — этот шаблон их не обрабатывает.
• Очень длинные TLD (новые gTLD могут быть длиннее 6 символов).
• Порты, user:pass@host — допускаются не во всех вариантах или потребуют доработки.
• Нестандартные символы в пути или запросе, требующие URL-энкодинга.

Если ваша задача — полная и RFC-совместимая валидация URL, используйте парсер URL из стандартной библиотеки (например, urllib.parse в Python или new URL() в JavaScript) и дополнительные проверки (разбор порта, проверка схемы, проверка DNS).

Альтернативы регулярным выражениям

• Стандартные парсеры URL: в Python — urllib.parse.urlparse(), в JavaScript — конструктор URL. Они корректно разбирают компоненты и удобны для последующих проверок.
• Библиотеки валидации: validator.js (Node/Browser), rfc3986-парсеры и т. п.
• Проверка доступности: DNS lookup + HTTP HEAD/GET для проверки, существует ли ресурс.

Выбор альтернативы зависит от целей: быстрый фильтр — regex; строгая валидация и парсинг — парсер; проверка существования — сетевые запросы.

Ментальная модель и эмпирические правила

• Правило 1: регулярные выражения хороши для формальных, простых шаблонов и первичной фильтрации.
• Правило 2: если запросы приходят от пользователей, проверка должна быть мягкой — лучше принять и затем дополнительно обрабатывать.
• Правило 3: если URL используется для доступа к ресурсам (скачивание, редирект), выполняйте серверную проверку и сетевые проверки.

Мини-методология для внедрения в проект (SOP)

1. Определите требования: какие схемы, допустимые TLD, поддержка IDN, порты и т. д.
2. Если достаточно простой синтаксической проверки — примените исходный regex и запишите тесты.
3. Добавьте список негативных и позитивных примеров для unit-тестов (см. раздел ниже).
4. Для критичных операций (редирект, скачивание) добавьте сетевую проверку и ограничения по таймауту.
5. Логируйте невалидные URL для анализа и улучшения валидации.

Тестовые случаи и критерии приёмки

Критерии приёмки:

• Регулярное выражение корректно распознаёт базовые http(s) URL из списка позитивных примеров.
• Регулярное выражение отклоняет очевидно неправильные строки (без схемы, случайный текст).
• Тестовый набор содержит примеры с путями, query string и без www.
• Для сценариев с IP и IDN задокументированы случаи, которые не обрабатываются и требуются расширения.

Примеры тестов (позитивные):

• https://example.com/
• http://sub.domain.co.uk/path?x=1&y=2
• https://mail.google.com

Негативные примеры:

• just-a-string
• http://localhost:8000 (в текущем regex отклоняется)
• ftp://files.example.com
• http://127.0.0.1

Рекомендации по безопасности и надёжности

• Никогда не выполняйте автоматические редиректы по непроверенным URL, пришедшим от пользователя.
• Очистите и нормализуйте URL перед использованием (удалите управляющие символы, нормализуйте кодировку).
• Применяйте белые списки доменов или шаблоны, если приложение должно работать только с ограниченным набором хостов.

Быстрые шпаргалки (cheat sheet)

• Быстрая фильтрация: используйте предложенный regex.
• Полный разбор: URL-парсер (new URL() в JS, urllib.parse в Python).
• Проверка существования: DNS lookup + HEAD/GET с таймаутом.

Когда стоит не использовать regex

• Если вам нужна полная совместимость с RFC 3986.
• Если поддержка IDN и нестандартных TLD критична.
• Если нужно анализировать и изменять компоненты URL (лучше парсер).

Резюме

Регулярное выражение, описанное в этой статье, пригодно для базовой валидации привычных URL с http/https и типичными доменами. Это удобный инструмент для первичной фильтрации входных данных и быстрой проверки формата. Для сложных или критичных сценариев используйте стандартные парсеры, дополнительные проверки DNS/HTTP и тесты.

Важно: расширяйте список тестов, логируйте отклонённые варианты и корректируйте подход в зависимости от задач проекта.