Опережающие и ретроспективные проверки в регулярных выражениях

[Bytamine]

Сколько этим пользовался, а только сегодня узнал, что они называются опережающие и ретроспективные )

[ComodoHacker]

Отдельное вам спасибо за уважение к русскому языку и попытку переода терминов. Хотя бы в заголовке.

[zerkms]

Раз такое дело: мало кто знает ещё о так называемых «possessive quantifiers». При этом они предоставляют довольно интересное поведение.

Почитать: www.regular-expressions.info/possessive.html

[bolk]

В регулярках вообще много такого, что мало кто знает. В PCRE есть «глаголы» (VERBS), например. Про рекурсивные регулярки мало кто слышал почему-то и так далее.

[matiouchkine]

Смею предположить потому, что всегда проще написать две регулярки последовательно, вместо того, чтобы ломать мозг потенциальному поддерживателю кода.

[bolk]

Это как сказать. Например, глагол «UCP» (так кажется, могу путать) нужен для корректной работы с UTF-8.

[matiouchkine]

Чтобы использовать магическое слово «UCP» — не обязательно знать про «VERBS в PCRE», правда?

[BarsMonster]

Собеседовал недавно человека, решаем задачку… Он в конце регулярного выражения ставит модификаторы isU

Спрашиваю «А зачем они нужны и что значат»?
Ответ — «Не знаю, они нужны чтобы все правильно работало, всегда их ставлю»

[matiouchkine]

Смешно, конечно.

Но я себя заставлял разбираться в PCRE года через три, после того, как начал пользоваться всякими регулярками. Просто болк — он педант, он шагу не ступит, пока не проверит поле вокруг на триста миль вперед на отсутствие мин. Это очень ценное качество, но оно не всем дано.

[akirsanov]

Зато человек не жадный.

[bolk]

Я не про модификаторы, я про «глаголы».

[bolk]

Неправильно. UCP — это и есть VERBS. Применяется он, например, так: /(*UCP)\w+/.

[matiouchkine]

Я знаю, как он применяется, спасибо.

Это никак не отменяет тезис «увидел на стаковерфло, и повторил», правда?

[aalexand]

Рекурсивное регулярное выражение — это уже не регулярное выражение, а стековая машина. Это не делает их менее полезными, но важно понимать, что это уже не конечный автомат.

[bolk]

Рекурсивное регулярное выражение — это всё ещё регулярное выражение, пусть и не автомат. Где есть требование делать их конечным автоматом?

[aalexand]

Классическое использование термина «регулярное выражение» означает «выражение, описывающее некоторый регулярный язык». Это, как мы видим, не всегда так, но мою чуткую душу это коробит, так что вот и напоминаю.

[bolk]

Например, мне как-то нужно было матчиться на функцию, в которую могла быть вложена другая функция. Что-то вроде sin(cos(0.3))

[bolk]

Неизвестен он.

[Meredian]

Простите за банальность, но традиционно, про html и регекспы
Вас спасает надежда на то, что пользователь не будет злоупотреблять, но вообще когда-нибудь оно обязательно сломается ;)

[BarsMonster]

Да, именно на этот вопрос я натыкался когда столкнулся с проблемой.
Но в данном случае пользователь — только я, и я не склонен ломать свой сайт ;-)

[LastDragon]

www.books.ru/books/regulyarnye-vyrazheniya-3-e-izdanie-fail-pdf-626982/?show=1 там еще много интересного есть :)

[skorney]

Хорошая книга, тоже рекомендую, даже не жалко бумаги на бумажный вариант.

[HomoLuden]

Может лучше было использовать Markdown или другой движок? Пусть заморочка с абзацами (два пробела в конце строки или одна пустая), но зато готовый набор множества других «плюшек»

[matiouchkine]

Ага. Здравствуй, бухгалтер, теперь ты пишешь на маркдауне.

[HomoLuden]

Неа. Здравствуй, бухгалтер, теперь ты пишешь на HTML. Бухгалтеру необязательно говорить, что две решетки перед заголовком это «MARKDOWN».
Но вообще я согласен. Даже заморочка с абзацами и переносами для некоторых целевых групп неприемлемы.

[BarsMonster]

Изначально(лет 10 назад) на том сайте так и было, но с течением времени оказалось, что обычный HTML проще и удобнее.
Markdown у всех разный, а HTML — везде один :-)

[HomoLuden]

HTML тоже разнится (я о кроссбраузерности). Хотя в данном случае набор поддерживаемых тегов подразумевается ограниченный весьма?

[BarsMonster]

Да, как на хабре. Никаких css, и прочих радостей жизни.

[EvilMan]

Мне кажется, что стоит упомянуть, что данные проверки относятся к так называемым «позиционным» проверкам, т.е. они совпадают не с текстом, а с позицией в тексте. При этом текст не «поглощается», что позволяет матчить его другой частью регулярного выражения.

[Placido]

Можно еще вспомнить, что опережающие проверки можно использовать перед искомым выражением (там, где обычно пишут условия для ретроспективной проверки) для имитации логического оператора «И» в регулярных выражениях. Например,

(?=.*\d)(?=^[A-Z]).{8,}

будет искать строки длиной не менее 8 символов, в которых есть хотя бы одна цифра И которые начинаются с прописной латинской буквы.

[truezemez]

Есть еще редко используемый модификатор — x. Он позволяет писать комментарии и игнорирует переносы строк:

$str = 'test-pcre-comments76755';
preg_match('
	~
	^      #начало строки
	(\w+)  #слово
	.+?    #любая последовательность (не жадная)
	(\d+)  #число
	$      #конец строки
	~x
', $str, $matches);
var_dump($matches);

array
  0 => string 'test-pcre-comments76755' (length=23)
  1 => string 'test' (length=4)
  2 => string '76755' (length=5)

[bolk]

Он ещё и пробелы игнорирует.

[hermit931]

Наверное стоило так же упомянуть, что есть так же разные диалекты (в одном из них эти проверки не работаю), которые используют разные языки. К примеру в JS ретроспективная проверка не работает :). Я сейчас уже не помню, всех тонкостей, но их много

[BarsMonster]

Там проблемы в основном с look-behind — это упомянуто. Look-ahead работает обычно везде.
Добавил про JS.

[hermit931]

C Look-ahead в JS не сталкивался, чаще требуется look-behind. Был разочарован, когда пол-часа долбился с написанием правила для такой проверки, и удивлялся, почему не работает. Оказалось что просто JS не поддерживает ее.

[senia]

Упоминать это можно в виде такой таблички.

[hermit931]

Неплохо бы добавить табличку к посту )

[BarsMonster]

Готово )

[Nordvind]

Назовите хотя бы одну причину, почему не надо использовать нормальный html парсер, а пользоваться регексами, которыми невозможно нормально парсить context-free grammar?

[BarsMonster]

Причина проста: гвозди забивают молотком, а не микроскопом.

Именно парсить HTML (выкусывать ссылки, картинки и прочее) — конечно стоит парсером.
Заменять переводы строк — можно тем, что работает проще, быстрее и не требует поддержки.

[Nordvind]

Бред. Имеет смысл только для написанных на коленке приложениях для себя, или для очень небольших объемов html. Регексы, особенно чужие — write-only код, со всеми вытекающими.

[BarsMonster]

Еще раз — я не предлагаю выдирать урлы картинок регэкспорм — хотя это и можно сделать.
Регулярные выражения в 20 символов для простых задач — проще и понятнее, чем парсер.

[bezumkin]

С некоторых пор пользуюсь Jevix в своих проектах — очень доволен!

Практически забыл про оформление текстов. Вы, кстати, тоже им пользуетесь, прямо сейчас, на Хабре.

[antoo]

Вместо регэкспов можно спокойно использовать стандартную функцию nl2br

[sectus]

Такое выражение поломается

<ul>
<li></li>
<li></li>
</ul>

[justAdmin]

В Perl еще есть нечасто используемый ключик e, который позволяет запускать код Perl и использовать возвращаемое значение в подстановке:

# Преобразовываем urlencoded строки в читаемые utf8
s/ ( (?: %[0-9A-F]{2} )+ )/ { my $a1 = uri_unescape($1); utf8::decode($a1); $a1; } /gex;