Регулярные выражения *

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

Существует знаменитый ответ на Stack Overflow о том, почему этого ни в коем случае не следует делать. На самом деле, этот ответ стал настолько популярным, что в определённых кругах используется, как копипаста. Каждый раз, когда я натыкаюсь на него, то думаю что он во многом справедлив... но в то же время, не могу согласиться с ним полностью...

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

Регулярки освоить нетрудно. Буквально за пару часов можно получить почти средний уровень владения и научиться читать и писать выражения для поиска ip-адресов, e-mail, html-тегов, телефонных номеров, дат и прочих несложных конструкций. Я думаю, все это вам знакомо, но на всякий случай в конце статьи я добавил несколько ссылок для изучения.

Я уже прошел «курс молодого бойца» по регуляркам, написал свою, вставил в find, и она не сработала. Но пойдем по порядку.

Разработка парсер генератора ISPA: что реализовано и какие планы на будущее.Гибкий парсер нового поколения с теми функциями, которых давно не хватает существующим решениям.

Представьте: нужно проверить документ или веб-страницу и найти повторяющиеся слова, чтобы, скажем, заменить их. А если найти нужно не просто слова, а электронные адреса, которые бывают разными.

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

Регулярные выражения или regex (от англ. regular expression) – это особый синтаксис для описания шаблонов поиска информации. С их помощью можно искать, заменять или извлекать данные из текста с высокой точностью. В основе регулярных выражений лежат символы, которые задают правила для поиска, например, всех цифр или слов, начинающихся на определенную букву. Регулярные выражения позволяют описать сложные условия поиска в простой и читаемой форме, что делает их незаменимыми для различных задач.

Регулярные выражения помогут в разных случаях – от валидации данных, например, при проверке форматов номера телефона до анализа текстов: получения ссылок или другой информации.

Посмотрим на синтаксис регулярных выражений. Дальше на примерах станет понятнее.

Меня с детства привлекала тема признаков делимости числа. Особенно удивительно было узнать про признаки делимости на 3 и на 9, когда путем простого сложения всех чисел и проверки результата можно было узнать делится ли изначальное число на эту цифру. Кроме того было интересно узнать, что существует регулярное выражение определяющее простоту числа. Но основной фокус там в том, что число записывается в унарном виде.

И вот пару лет назад я встретил еще одну интересную задачу по написанию регулярного выражения для определения делится ли искомое число на 7. Само число при этом написано в двоичном виде. Признаки делимости на 7 существуют и для двоичной и для десятичной записи, но как правило они требуют производить операции умножения, сложения и рекурсивно проверять делимость уже получившегося в итоге этих действий меньшего числа, что не очень подходит для написания регулярного выражения. Я предполагал, что каким то образом могут помочь сложные операторы: условное сопоставление (позиционные проверки), обратные ссылки итд, но не разобрался как их использовать конкретно для данной задачи. Гораздо больше я думал в сторону более простой регулярки с использованием только оператора ИЛИ, квантификаторов и скобок. Остановился на построении графа остатков от деления следуя, по которому можно получить остаток заданного числа, но уперся в то, что всякое выражение с использованием скобок, но без ссылок - это в итоге дерево и поэтому произвольный граф туда не ложится. Это как пытаться хранить произвольный граф в JSON или XML - можно, но нужно будет вводить идентификаторы узлов и поля ссылок, а в то же время хранение простого дерева этого не потребует.

Я хочу поделиться своим изобретением, которое позволяет вам использовать только одно регулярное выражение, которое будет искать подстроку в строке с определенным условием. Если хотите, называйте это циклом в RegEx, которого раньше не существовало!

Я поделюсь с вами не только разными полезными шаблонами, но и покажу различные примеры от простых до сложных.

Если я хочу посмотреть видео — разве для этого обязательно покидать vim?

Что ж, прямо в заголовке этого поста я пообещал вам продемонстрировать Bad Apple в vim, пользуясь только поисковыми запросами. Вот Bad Apple в vim, всё, что здесь меняется — только поисковый запрос:

В праздничные выходные мне пришло в голову, что я давно не занимался чем-то бессмысленным. Представляю вашем вниманию... Regex Chess: набор из 84688 регулярных выражений, которые при выполнении по порядку генерируют ход (валидный, то есть не совсем ужасный) для переданного в качестве входных данных состояния шахматной доски. [Прим. переводчика: здесь в оригинале статьи есть интерактивный виджет, позволяющий сыграть с движком.]

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

let regex_list = [/* очень длинный список регулярных выражений */]
let board = "rnbqkbnr / pppppppp / 8 / 8 / 8 / 8 / PPPPPPPP / RNBQKBNR w KQkq - 0 1";
for (regex of regex_list) {
board = re.replace(regex.pattern, regex.target)
}
display(board)

Прочитав этот пост, вы поймёте (надеюсь), как возможна эта последовательность регулярных* выражений, а также что делают конкретные регулярные выражения.

^{* Снобы могут заявить что-то типа «Вы сказали, что будете использовать регулярные выражения, но они не регулярные!" Но меня это не волнует.}

Как всегда, код проекта выложен на GitHub.

Всем привет, меня зовут Алексей Нихаенко и я дата инженер. Это мой первый пост на хабре и я хочу поведать вам свое более близкое знакомство с инструментом Postman.

О чем пойдет речь?

Как-то я исследовал способы наиболее эффективного определения простоты числа и наткнулся на показанный выше код.

Он меня заинтриговал. Хоть это, возможно, и не самый эффективный способ, но определённо один из наименее очевидных, поэтому мне стало любопытно. Каким образом соответствие регулярному выражению .?|(..+?)\1+ должно показать, что число непростое (после его преобразования в унарную систему счисления)?

Если вы заинтересовались, продолжайте чтение, я проанализирую это регулярное выражение и объясню, что же в нём происходит. Объяснение не зависит от языка программирования, однако я приведу версии показанного выше Java-кода на Python, JavaScript и Perl  и объясню, почему они немного различаются.

Я объясню, как регулярное выражение ^.?$|^(..+?)\1+$ способно отфильтровывать все простые числа. Почему это выражение, а не .?|(..+?)\1+ (использованное в примере кода на Java)? Это связано с тем, как работает String.matches(), о чём я расскажу ниже.

Хотя по этой теме есть несколько постов, я считаю, что они недостаточно глубоки и в них приводится лишь высокоуровневое объяснение, недостаточно хорошо излагающее важные подробности. В своей статье я попытаюсь объяснить подробности, чтобы их мог понять любой. Моя цель — сделать этот код понятным каждому, будь вы гуру регулярных выражений или впервые о них услышали.

Мы запустили наш поисковик по Hacker News и RAG-движок с полусырой системой исправления опечаток. В нашей первой версии тратилось более 30 мс на обработку орфографически правильных запросов. Это достаточно много, поэтому по умолчанию мы отключили данную фичу. Наша новейшая версия работает в 100 раз быстрее, справляется за 300 мкс с корректно записанными запросами и тратит ~5 мс/слово на исправление ошибок. В этом посте мы объясним, как нам удалось этого добиться!

Привет, хабровчане!

Я Дима, Python-разработчик из 21YARD, сервиса поиска строительных подрядчиков.

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

Приветствую всех, в данной статье я кратко расскажу и покажу, что такое TDD на очень простом примере.

Итак, представим себя разработчиком в вымышленной ИТ компании, перед которым стоит задача: написать валидатор пользовательских паролей, при этом стараясь следовать принципам TDD.

Начнем разработку нашей программы с ознакомления с требованиями службы безопасности:

Однажды мы в documentat.io решили спасти наших техписов от рутинной ручной замены кавычек и написали для них статью про умную автозамену — с использованием регулярных выражений. Теперь решили поделиться ей на Хабре.

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

Привет, Хабр! Меня зовут Татьяна, я разработчик в Росбанке, и в этом посте я расскажу про регулярные выражения. По своему опыту могу сказать, что регулярки — это очень полезный инструмент. Я часто пользуюсь ими, решая задачи по обработке текста в базах данных. Вначале я остановлюсь на теории, а затем рассмотрю несколько реальных задач, которые были решены с использованием регулярных выражений.

Когда-то я хотел сделать контест по парсингу для Codeforces. Придумал задания двух типов:

1. Дается неформальное описание языка, по которому нужно создать грамматику (например, "язык с правильными скобочными последовательностями")

2. Даны примеры строк в языке, по которым нужно восстановить грамматику

У обоих типов заданий есть свои проблемы, так что контест я не сделал.

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

"Не используйте регулярки - иначе вместо 1 проблемы, у вас их станет 2!" - как то так говорят знатоки... А что остается делать непослушным, желающим эффективный поиск по большому количеству шаблонов?

Да, для такой довольно специфичной проблемы существуют крутые решения вроде Ragel или re2c. Тем не менее, для своего проекта мне показалось нецелесообразным пока осваивать эти прекрасные технологии.

В этой статье мы рассмотрим альтернативы стандартной библиотеке для регулярных выражений в Go, проведем их бенчмарк по скорости и потребляемой памяти. А также с практической точки зрения рассмотрим различия между ними.

История этого эксперимента началась где-то в 2022 году с желания фильтровать поступающую из разнородных каналов информацию. В современном мире люди вынуждены находиться в бурном потоке всевозможных новостей, публикаций и коммерческих объявлений и вручную пытаться найти в этом потоке то, что им нужно.

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