Известная шутка программистов гласит, что если решение вашей проблемы включает в себя парсинг текста при помощи регулярного выражения, то теперь у вас есть две проблемы. Некоторые программисты, прочитав шутку, решают попробовать иной подход. Возможно, регулярные выражения не так уж нужны. Возможно, задачу можно решить простым split строки или чем-то подобным. Однако другие могут задуматься немного глубже и задаться вопросом: «А если я сделаю нечто настолько дерзкое, что в результате получу три проблемы?» Мой пост написан в таком духе!

В нём используется код на Python, однако его легко можно адаптировать под любой язык с поддержкой функций высшего порядка.

Привет, Хабр! Эта статья про плагин Rainbow CSV, который я написал для 5 текстовых редакторов:

VS Code, Vim, Sublime Text 3, Atom, Gedit

Думаю, что многие читатели этой статьи периодически сталкиваются с CSV (comma-separated), ТSV (tab-separated) и подобными файлами. Если попробовать открыть их в текстовом редакторе (а как иначе узнать что там внутри?), то откроется совершенно невзрачная картина как с левой стороны изображения. Глядя на это сложно сказать даже сколько колонок в таблице. С правой стороны картинки тот же файл с включенным RainbowCSV, читаемость значительно повысилась за счет синтаксической подсветки.

Регулярные выражения в Python от простого к сложному

Решил я давеча моим школьникам дать задачек на регулярные выражения для изучения. А к задачкам нужна какая-нибудь теория. И стал я искать хорошие тексты на русском. Пяток сносных нашёл, но всё не то. Что-то смято, что-то упущено. У этих текстов был не только фатальный недостаток. Мало картинок, мало примеров. И почти нет разумных задач. Ну неужели поиск IP-адреса — это самая частая задача для регулярных выражений? Вот и я думаю, что нет.
Про разницу (?:...) / (...) фиг найдёшь, а без этого знания в некоторых случаях можно только страдать.

Плюс в питоне есть немало регулярных плюшек. Например, re.split может добавлять тот кусок текста, по которому был разрез, в список частей. А в re.sub можно вместо шаблона для замены передать функцию. Это — реальные вещи, которые прямо очень нужны, но никто про это не пишет.
Так и родился этот достаточно многобуквенный материал с подробностями, тонкостями, картинками и задачами.

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

Привет, Хабр.

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

Некоторые из них для наглядности будут показаны на примере языков программирования PHP или JavaScript, но в целом они работают независимо от ЯП.

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

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

Поехали!

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

Хитрость в том, чтобы сразу определить значение слова «действительный».

Мы разработчики — технические ребята, так что наиболее логичным будет проверить на соответствие официальным критериям. Вот некоторые примеры валидных адресов email, которые соответствуют критериям.


^{en.wikipedia.org/wiki/Email_address#Valid_email_addresses}

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

Большинство из нас, впервые столкнувшись с данной проблемой, начинают забивать в поисковых системах что-то типа: «regexp online generator» и к своему великому сожалению осознают что гугл сломался все результаты в поиске являются сервисами для проверки корректности уже составленного регулярного выражения (или я плохо гуглил).

А как же составить это самое регулярное выражение?

До недавнего времени существовало 2 ответа на этот вопрос:

1. Изучить документацию по регулярным выражениям и составить регулярку самому
2. Попросить кого-то более опытного сделать это за вас

Теперь, после нескольких месяцев разработки, рад представить и 3-й ответ:

» Генератор регулярных выражений

История

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

Кто-то парсирует текстовый файл программой на Питоне, другой пишет скрипт с регулярными выражениями на Перле, Си-программист стыдливо возится с буферами и указателями, иногда применяя Yacc и Lex.

А можно ли парсировать текст голым железом? Вообще без программы?

— А как это?, — спросил меня знакомый, — С помощью Ардуино?

— Внутри Ардуино стоит вполне фон-неймановский процессор и работает программа, — ответил я, — Нет, еще более голое железо.

— А-а-а-а, этот, микрокод?, — догадался мой товарищ и взглянул на меня победно.

— Нет, термин «микрокод» использовался для специфической организации процессоров в 1970-е годы, потом его использование сошло на нет, — ответил я и добавил, — Правда есть еще микрооперации в интеловских процессорах, в которые перекодируется x86, но это тоже другое. Нет, я имею в виду парсинг текста устройством, состоящим из логических элементов И-ИЛИ-НЕ и Д-триггерами, как на картинке ниже.

— Невозможно! — воскликнул мой приятель, — в таком устройстве где-то сбоку должен сидеть процессор и хитро подмигивать!

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

— Нуу, машина Тьюринга, — протянул приятель, — это абстракция, типа Демона Максвелла.

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

От переводчика: прочитав статью, начал было отвечать в комментариях, но решил, что текст, на которую я собирался ссылаться, достоин отдельной публикации. Встречайте!

Если вы знаете, как валидировать email-адрес, поднимите руку. Те из вас, кто поднял руку — опустите её немедленно, пока вас кто-нибудь не увидел: это достаточно глупо — сидеть в одиночестве за клавиатурой с поднятой рукой; я говорил в переносном смысле.

До вчерашнего дня я бы тоже поднял руку (в переносном смысле). Мне нужно было проверить валидность email-адреса на сервере. Я это уже делал несколько сот тысяч раз (не шучу — я считал) при помощи классного регулярного выражения из моей личной библиотеки.

В этот раз меня почему-то потянуло ещё раз осмыслить мои предположения. Я никогда не читал (и даже не пролистывал) RFC по email-адресам. Я попросту основывал мою реализацию на основе того, что я подразумевал под корректным email-адресом. Ну, вы в курсе, что обычно говорят о том, кто подразумевает. [прим. перев. Автор имеет в виду игру слов: «when you assume, you make an ass out of you and me» — «когда вы (что-то) подразумеваете, вы делаете /./удака из себя и из меня»]

И обнаружил кое-что занимательное: почти все регулярные выражения, представлены в интернете как «проверяющие корректность email-адреса», излишне строги.

В этой статье мы рассмотрим два способа поиска с помощью регулярных выражений. Один широко распространён и используется в стандартных интерпретаторах многих языков. Второй мало где применяется, в основном в реализациях awk и grep. Оба подхода сильно различаются по своей производительности:



В первом случае поиск занимает A?ⁿAⁿ времени, во втором — Aⁿ.

Степени обозначают повторяемость строк, то есть A?³A³ — это то же самое, что и A?A?A?AAA. Графики отражают время, требуемое для поиска через регулярные выражения.

Обратите внимание, что в Perl для поиска строки из 29 символов требуется более 60 секунд. А при втором методе — 20 микросекунд. Это не ошибка. При поиске 29-символьной строки Thompson NFA работает примерно в миллион раз быстрее. Если нужно найти 100-символьную строку, то Thompson NFA справится менее чем за 200 микросекунд, а Perl понадобится более 10¹⁵ лет. Причём он взят лишь для примера, во многих других языках наблюдается та же картина — в Python, PHP, Ruby и т. д. Ниже мы рассмотрим этот вопрос более детально.

Наверняка вам трудно поверить приведённым данным. Если вы работали с Perl, то вряд ли подмечали за ним низкую производительность при работе с регулярными выражениями. Дело в том, что в большинстве случаев Perl обращается с ними достаточно быстро. Однако, как следует из графика, можно столкнуться с так называемыми патологическими регулярными выражениями, на которых Perl начинает буксовать. В то же время у Thompson NFA такой проблемы нет.

Возникает логичный вопрос: а почему бы в Perl не использовать метод Thompson NFA? Это возможно и следует делать, и об этом пойдёт далее речь.

Хочу просто поделиться недавно найденным сервисом для работы с регулярными выражениями. Да, это еще один сервис. Но у него есть особенность — он позволяет не только составлять регулярные выражения, но и помогает разбирать уже написанные — эдакий regexp-декомпилятор.
Сервис называется Regex101.

Сразу оговорюсь, если Вы — профессионал в использовании регулярных выражений, то Вам лучше дальше не читать во избежание ^(.*)$

GitHub-пользователь jehna нашёл интересный метод ухода от реализации сложных регулярных выражений традиционным способом.
Вербальные выражения превращают сложный и иногда нетривиальный путь от логики до собственно регулярного выражения в ненавязчивую прогулку с использованием связанного набора функций.

Серьезно, прекратите. Это пустая трата времени и сил. Поищите регулярку для проверки Email в Google, взгляните на нее — и захочется отойти подышать свежим воздухом. Вспоминается одна очень известная цитата:

Некоторые люди, сталкиваясь с проблемой, думают: «О, я воспользуюсь регулярными выражениями».
Теперь у них две проблемы.

Джэйми Завински, regex.info

Есть одна бородатая шутка: «если у вас есть проблема, и вы собираетесь решать ее с использованием регулярных выражений, то у вас есть две проблемы». Действительно, регулярные выражения – очень мощный и гибкий инструмент, применяемый для решения весьма широкого круга задач. Но, как водится, для поддержания баланса, такой серьёзный инструмент имеет весьма недружелюбный вид.

(<([a-z]+[^>]*)>)(.*)(</\2>)

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



Когда-то и мне пришлось по долгу службы подружиться с регулярными выражениями. Прочитав Фридла и несколько статей на Хабре, я, конечно, начал понимать этот синтетический язык. Тем не менее, каждый раз, когда приходилось написать очередную регулярку, я быстро закапывался в нагромождении скобок, слешей, точек, плюсов, знаков вопроса, и других хорошо вам знакомых конструкциях. Разобраться в этой каше было очень сложно, особенно если возвращаешься к задаче месячной давности. Я мечтал об инструменте, который помог бы мне разобраться в собственном творении. Приблизительно подходящих по смыслу сервисов нагуглилось с десяток, но все они приносили мало пользы. Как раз тогда я и начал разрабатывать этот проект.

Итак, regexponline – инструмент, способный наглядно изобразить структуру регулярного выражения, разобрав его по элементарным компонентам; продемонстрировать совпадающие и не совпадающие его части; помочь в написании и отладке выражения, которое почему-то не совпадает с нужной строчкой.

Как частый посетитель тэга PHP на StackOverflow, я очень часто встречаю вопросы о том, как распарсить какие-то конкретные аспекты HTML, используя регулярные выражения. Самый распространённый ответ на это:

«Ты не можешь парсить HTML с помощью регулярных выражений, потому что HTML не является регулярным. Используй XML парсер, и будет тебе счастье»

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

Кроссворд, подсказки в котором — регулярные выражения.

Оригинал в PDF.

Автор — не я! Это часть MIT Mistery Hunt 2013.

Я хочу предложить вам поломать голову вечерок-другой над интересными задачками, на регулярные выражения, которые Callum Macrae выкладывает на своем сайте на GitHub каждый Вторник.

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

Тесты используют JavaScript Regex движок вашего браузера, который обладает всеми основными возможностями PCRE.  Подробнее можно посмотреть тут (англ.) , в колонке ECMA в таблице.

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

UPD: В регулярных выражениях ECMAScript нету ретроспективных проверок.

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

• Команда grep операционной системы Unix или аналогичные команды для поиска цепочек, которые можно встретить в Web-броузерах или системах форматирования текста. В таких системах РВ используются для описания шаблонов, которые пользователь ищет в файле. Различные поисковые системы преобразуют РВ либо в детерминированный конечный автомат (ДКА), либо недетерминированный конечный автомат (НКА) и применяют этот автомат к файлу, в котором производится поиск.
• Генераторы лексических анализаторов. Лексические анализаторы являются компонентом компилятора, они разбивают исходную программу на логические единицы (лексемы), которые могут состоять из одного или нескольких символов и имеют определенный смысл. Генератор лексических анализаторов получает формальные описания лексем, являющиеся по существу РВ, и создает ДКА, который распознает, какая из лексем появляется на его входе.
• РВ в языках программирования.

В данной статье мы сначала ознакомимся с конечными автоматами и их видами (ДКА и НКА), и далее рассмотрим пример построения минимального ДКА по регулярному выражению.

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

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

Задача банальная — заменить переводы строк на <br/>, за исключением случая, если перед этим шел html-тэг (для простоты только символ >). Отходя от темы — такой алгоритм замены нужен чтобы иметь и автоматическое добавление переводов строки внутри блоков текста в стиле хабра, и при этом не ломать обычную HTML верстку.

В общем, наверное, как и другой любой начинающий JavaScript прогрммист (2 года назад), мне хотелось все реализовать своими руками. Так возникло ужасающее очень быстрое регулярное выражение из 280 символов.

Немного истории

Приблизительно полтора года назад, я узнал о библиотеке yass, которая была самым быстрым инструментом для поиска DOM элементов в JavaScript по CSS селекторам (ссылка на тесты).
И тут у меня возник ужасный интерес. Я захотел придумать способ, который будет еще быстрее. В то время я как раз читал книгу «Регулярные выражения Библиотека программиста» второе издание от Дж. Фридла. И вот… Это было лето, я еще был студентом и у меня была масса времени. Работа закипела…

Вместо вступления

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

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