Серьезно, прекратите. Это пустая трата времени и сил. Поищите регулярку для проверки Email в Google, взгляните на нее — и захочется отойти подышать свежим воздухом. Вспоминается одна очень известная цитата:
Некоторые люди, сталкиваясь с проблемой, думают: «О, я воспользуюсь регулярными выражениями».
Теперь у них две проблемы.Джэйми Завински, regex.info
Наибольшее число отзывов, не говоря уже об «ошибках», мне приходит на регулярное выражение e-mail адреса:
b[A-Z0-9._%+-]+@[A-Z0-9.-]+.[A-Z]{2,4}b
Я утверждаю, что это регулярное выражение определяет любой e-mail адрес. В обратной связи обычно показывается один e-mail адрес, который не подпадает под это выражение; также, в отчетах об «ошибках» содержится предложение создать идеальный regexp.
Как я объясню ниже, мое утверждение справедливо тогда, когда вы принимаете мое определение того, что есть действительный адрес электронной почты, а что — нет. Если вы используете другое определение, то вам придется подкорректировать выражение. Определение действительного e-mail адреса — это отличный пример, показывающий, что
В расширениях Хрома принято указывать версию скрипта в виде не более чем 4 чисел, разделённых точками, и величиной не более 32767 каждое и не начинающихся с цифры 0. Этого более чем достаточно, если в номер версии включены обычные данные: версия, подверсия, сборка. Если в версию хотим поместить дату в виде 3 чисел, то в наиболее удобной для чтения записи (версия.год.месяц.день) числа года, месяца и дня занимают 3 места из 4. На версию остаётся первое число (как более приоритетное перед датой), а на подверсию и минор ничего не остаётся. Задача: как расположить минорную версию, чтобы уложиться в формат, чтобы дата была читаемой, а версия с минором при сравнении 2 строк занимала правильное место в ряду версий? Кроме того, нужна процедура выделения даты и версии с минором из общей строки.
Читать полностью »
Есть одна бородатая шутка: «если у вас есть проблема, и вы собираетесь решать ее с использованием регулярных выражений, то у вас есть две проблемы». Действительно, регулярные выражения – очень мощный и гибкий инструмент, применяемый для решения весьма широкого круга задач. Но, как водится, для поддержания баланса, такой серьёзный инструмент имеет весьма недружелюбный вид.
(<([a-z]+[^>]*)>)(.*)(</2>)
Такая чупакабра новичка приводит в трепетный ужас, да и знающего человека заставляет невольно поморщить нос. А ваша девушка вообще решит, что вы свихнулись, когда увидит вас за написанием такой конструкции.
Когда-то и мне пришлось по долгу службы подружиться с регулярными выражениями. Прочитав Фридла и несколько статей на Хабре, я, конечно, начал понимать этот синтетический язык. Тем не менее, каждый раз, когда приходилось написать очередную регулярку, я быстро закапывался в нагромождении скобок, слешей, точек, плюсов, знаков вопроса, и других хорошо вам знакомых конструкциях. Разобраться в этой каше было очень сложно, особенно если возвращаешься к задаче месячной давности. Я мечтал об инструменте, который помог бы мне разобраться в собственном творении. Приблизительно подходящих по смыслу сервисов нагуглилось с десяток, но все они приносили мало пользы. Как раз тогда я и начал разрабатывать этот проект.
Итак, regexponline – инструмент, способный наглядно изобразить структуру регулярного выражения, разобрав его по элементарным компонентам; продемонстрировать совпадающие и не совпадающие его части; помочь в написании и отладке выражения, которое почему-то не совпадает с нужной строчкой.
Читать полностью »
Как частый посетитель тэга PHP на StackOverflow, я очень часто встречаю вопросы о том, как распарсить какие-то конкретные аспекты HTML, используя регулярные выражения. Самый распространённый ответ на это:
«Ты не можешь парсить HTML с помощью регулярных выражений, потому что HTML не является регулярным. Используй XML парсер, и будет тебе счастье»
Это утверждение — в контексте вопроса — находится где-то между сильно вводящим в заблуждение и абсолютно неправильным. Что я хочу попытаться продемонстрировать в этой статье, так это то, насколько могущественны современные регулярные выражения на самом деле.
Читать полностью »
Меня всегда интересовала история появлений научных понятий. Перед изучающим новый предмет сначала встает череда безликих определений. Некоторые из них таковыми и остаются, другие привлекают внимание и со временем вырастают в полноценные объекты «картины мира». В качестве недоступного идеала такого стремления можно привести высказывание Литлвуда о Рамануджане:
каждое натуральное число было его лучшим другом
Мне всегда было интересно не только освоить понятие, но и разобраться, как оно появилось. За каждым определением всегда стоит личность. Интересно понять, какие идеи лежали в основе того или иного понятия и почему новые определения были восприняты и поддержаны другими людьми с таким энтузиазмом, что остались в учебниках.
Далее будет приведено небольшое исследование подобного рода, объектом которого является понятие регулярного выражения.
Читать полностью »
Между регулярными выражениями в JavaScript и регулярными выражениями PCRE (употребляющимися в Perl и в PHP) есть ряд различий, главнейшим из которых, вероятно, является отсутствие lookbehind (ретроспективной проверки) в JavaScript.
Естественной задачею программистов, раздражённых этими различиями, является внедрение PCRE в JavaScript.
На движке Node к концу нынешнего января Брайан Уайт (Brian White) решил эту задачу, создав модуль node-pcre, служащий обёрткою вокруг движка PCRE.
Этому можно порадоваться, и порадуемся.
Однако node-pcre,Читать полностью »
Данный пост будет, как правило, интересен студентам, так как подобное задание было получено в качестве лабораторной работы по дисциплине «Лингвистические основы информатики».
Итак, давайте же рассмотрим техническое задание подробнее. Что нам требуется? А требуется нам создать анализатор, который будет разбивать заданный текст на языке Java по классам — ключевым словам, идентификаторам, операторам, пунктуаторам (сепараторам) и т.п., и выводить результат работы в таблицу. Таблица будет содержать следующие столбцы:
Напомню, что токен — это последовательности символов в лексическом анализе в информатике, соответствующий лексеме.
Спецификатор описывает к какому классу относится токен. То есть, например, для токена «boolean» в таблице выведется «Keywords».
Ну описание, позицию и длину описывать, я думаю, не стоит.
Вроде бы задание понятно. Теперь разобьем его на подзадачи.
0) Изначально я бы посоветовал изучить спецификацию языка, для которого вы будете писать анализатор. Далее нам нужно:
1) Загрузить массив данных о наших ключевых словах, операторах и пунктуаторах, так как они уникальны.
2) Распарсить заданный текст на токены и определить их классы. (Распарсить — то же самое, что и разобрать, т.е. выбрать эти элементы из текста в переменные)
3) Занести данные о токенах в массив и отсортировать его.
4) Вывести данные в таблицу.
Читать полностью »
Я хочу предложить вам поломать голову вечерок-другой над интересными задачками, на регулярные выражения, которые Callum Macrae выкладывает на своем сайте на GitHub каждый Вторник.
Каждый вопрос представлен в виде набора тестов. Задача — написать такой регулярное выражение, чтобы все тесты стали зелеными.
Некоторые из задач сами по себе довольно простые, а самая интересная часть — в том, чтобы написать наиболее короткое возможное регулярное выражение.
Тесты используют JavaScript Regex движок вашего браузера, который обладает всеми основными возможностями PCRE. Подробнее можно посмотреть тут (англ.) , в колонке ECMA в таблице.
Я собрал в этой статье русские версии задач и материалов, которые могут помочь в их решении. Было бы интересно увидеть самые интересные решения в комментах.
Регулярные выражения (РВ) — это очень удобная форма записи так называемых регулярных или автоматных языков. Поэтому РВ используются в качестве входного языка во многих системах, обрабатывающие цепочки. Рассмотрим примеры таких систем:
В данной статье мы сначала ознакомимся с конечными автоматами и их видами(ДКА и НКА), и далее рассмотрим пример построения минимального ДКА по регулярному выражению.
Читать полностью »