Как проверить в регулярном выражение ip адрес на java?
Помогите модернизировать регулярное выражение с таким условием
1.(шаблон xxx.xxx.xxx.xxx) могут указыватся через , это уже сделано (?=^(((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(\.)){3}(25[0-5](,|$)|2[0-4][0-9](,|$)|[01]?[0-9][0-9]?(,|$)?))*$)(?=^.{0,8000}[^,\s]$)|^$
2.или с использованием символа-подстановки "*" в последнем октете (шаблон xxx.xxx.xxx.*)
3.или использованием начального и конечного значения диапазона и только в последнем октете (шаблон xxx.xxx.xxx.0-xxx.xxx.xxx.255)
Валидные строки
10.80.212.195
10.80.212.*
10.80.212.0-10.80.212.255
Не валидные все строки которые не относятся к ip адресу или октет больше 255
Например 10.82.212.300
Мда. А ведь это просто IPv4. Могло-бы быть и IPv6.
Кстати регулярок недостаточно чтобы проверять семантику IP-блоков. Например такой блок 10.80.212.0-10.80.212.255 или ему подобный может проходить валидацию через регулярки но при этом он будет не валидный с точки зрения смысла.
Кстати для факультатива задачка. IP адреса могут иметь еще несколько форм записи. Например
20.53.203.50 - десятичная с точкой
339069746 - просто десятичная
0x1435CB32 - hex
все они пингуются утилитой ping и раньше даже открывались браузерами как адреса. Сейчас к сожалению
такая нотация не используется. А зря. Было-бы проще не пробивать башкой десятичные нотации с точкой.
сергей кузьмин, Ну не совсем так, из бэка(джава) запрашивается строка в котором находится регулярное выражение, а на фронте оно уже реализуется в конкретном поле.
Dimonchik, ну.. в регулярках группы несут смысл. Например после результата удачного парсинга я хочу в группах иметь определенные атомарные части выражения.
Не знаю как в твоём языке разработки а в Java поддерживаются labels. Тоесть я к примеру пишу
"(?<beginIp>.....)"
И в коде могу взять группу по имени groups("beginIp') и получаю 255.255.255.255.
ну, так в чем вопрос-то? ну оберни в скобки любую нужную группу ) там же по ссылке, по-моему, такое разбирается, хотя не только такое
есть возвратные - для переменных, есть невозвратные, PCRE ж везде PCRE
что не срабатывает в выражении для приведенных строк?
это я молчу за немного мутную постановку задачи, с выбивающейся двухдиапазонной записью
красивее записать можно, для одного диапазона, но потеряется читаемость
а так-то вообще можно \d ввести зная изначально что там реальные адреса
Спасибо работает как надо, только когда поле не заполнено ругается, прошлая регулярка((?=^(((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(\.)){3}(25[0-5](,|$)|2[0-4][0-9](,|$)|[01]?[0-9][0-9]?(,|$)?))*$)(?=^.{0,8000}[^,\s]$)|^$) не ругалась когда поле не было заполнено. Что надо добавить чтоб поле было не обязательным для заполнения?
Dimonchik, Твое решение подходит и для моего кейса тоже, а как добавить в эту регулярку дополнительные проверки. Например если будет написано 10.80.212.195- или 10.80.212.195, то это считалось ошибочным.
Правильно
10.80.212.195-10.80.212.198
10.80.212.195,10.80.212.198
Не правильно
10.80.212.195-
10.80.212.195,
Мне кажется что если не решать эту задачу только регулярками а сделать такое.
- проверить что строка состоит из 4х чисел разделенным точками
- проверить что каждое число в диапазоне [2..255] (проверять уже как Integer)
то тогда функция проверки будет простая и наглядная. Это для кейса 10.80.212.195.
Для масок подсети и IPBlocks единая функция проверки все равно безсмысленна - ведь на следующем уровне API
нам надо различать классы { IP, IP+Mask, IPBLock } и нам выгодно сделать 3 функции-предиката. Тем более что классы результата различны.
Простой
