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

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

sebastianzartner.de/firefoxExtensions/RExT

Данная заметка не предназначена для начинающих изучать регулярные выражения, для начинающих я бы посоветовал книгу Ben Forta "Teach Yourself Regular Expressions in 10 Minutes" (ISBN: 0-672-32566-7).

Для тестирования и отладки регулярных выражений идеально подходит программа RegexBuddy (http://www.regexbuddy.com). Чтобы отлаживать следующие примеры нужно во вкладку Test скопировать HTML какой-либо страницы или вбить несколько тегов самим.

Задача — найти в HTML все теги IMG и вытащить из тегов значения атрибутов SRC и ALT.

В статье Regexp — это «язык программирования». Основы была поставлена задача: написать регулярное выражение, находящее в цепочке символов текст в двойных кавычках, причем внутри кавычек "..." могут быть и сами символы ", если они экранированы обратным слэшем, например:
one two "foo:=\"quux\"; print" three "four"
Здесь наш регекс должен найти соответствие цепочке
"foo:=\"quux\"; print"
Автором (той статьи) было предложено такое решение:
/ " ( \\" | [^"] )* " /x
(здесь и далее синтаксис Perl; ключ /x означает, что пробелы в регексе не учитываются, мы добавили их лишь для наглядности, чтобы части регекса не слились в единый «модемный шум»).
Этот регекс работает в том случае, когда есть совпадение (текст в кавычках). Проблема же в том, что он находит текст в кавычках даже тогда, когда текста в кавычках (согласно нашим правилам экранирования обратным слэшем) просто нет. Например, в цепочке "\" регекс находит соответствие (равное всей строке "\" ), хотя его быть не должно: кавычка открыта, экранированная кавычка… а вот закрывающей-то кавычки нет.
Ситуацию легко исправить, исходную задачу решить несложно, внеся несколько простых изменений в регекс… но речь не об этом, а о том, что если у вас в руках современный инструмент, т. е. движок регексов (свежая версия Perl, Java или PHP с PCRE), то вы можете «исправить» описанный регекс, добавив в него всего лишь 1 символ. Какой? Куда? Почему? Если знаете ответы, то читать дальше вам не стОит ;-)

 

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

1. Часть ЧПУ (человекопонятный URL)

По сути, слово с дефисами.

Паттерн: /^[a-z0-9-]+$/

По мотивам переведенной статьи

Впервые я увидел регэкспы еще в школе в перле, и в общем полюбил их с первого взгляда, конечно после того как разобрался что это такое :). И с превеликим энтузиазмом принялся все регэкспить. Конечно, при этом, понабивал себе шишек на мозг, но любить их не перестал. Со временем любая искренняя любовь взрослеет и перерастает в глубокую привязанность, с понимаем того, что объект твоего чувства может быть несовершенным, но от этого не менее любимым.

Итак, несколько способов предохраниться от разочарования в этом мощном и прекрасном инструменте…

Регулярные выражения могут оказать Вам неоценимую услугу при их разумном применении в SQL-запросах.
Они могут избавить Вас от необходимости перебирать в курсорных циклах, или (о ужас!) в циклах базового языка приложения солидные куски таблиц. Правда иногда услуга может оказаться «медвежьей».
Примеры и особености применения этой техники

Под впечатлением от идеи создания библиотеки для работы с search-частью произвольной ссылки решил написать функцию (в соавторстве с Kupyc, респект за учаcтие — ему принадлежит бОльшая часть), выполняющую ту-же задачу:

/**
* Функция для модификации GET-параметров uri
*
* @param {String} uri
* @param {String} paramsNew
* @param {Boolean} [isReplace]
* @version 0.2.1
*/

var uriQueryParamsModifier = function (uri, paramsNew, isReplace) {
    var paramsUri = ((paramsUri = uri.match(/\?([^#]+)/)) && paramsUri[1]); 
    if (paramsUri && isReplace) {
        return uri.replace(/\?[^#]+/, !paramsNew ? '' : '?' + paramsNew );
    }    
    if (paramsNew) {
        return uri.replace(/(#)|$/, (!paramsUri ? '?' : '&') + paramsNew + '$1');
    } 
    return uri;
}

* This source code was highlighted with Source Code Highlighter.

Авось кому сгодится.

Поставили на одном проекте антимат на основе Antimat.pm Ильи Солдаткина.
Через некоторое время возникла необходимость его подправить. Было решено, что слово «фиг» матом считать не будем и заказчик захотел добавить еще пару слов. Как быть? Базовый шаблог модуля — строка длиной 12706 символов. Ходить по ней вдоль и что-то искать-править — врагу не пожелаешь.

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

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

Сегодня я хотел бы познакомить вас с книгой Яна Гойвертса и Стивена Левитана «Регулярные выражения. Сборник рецептов», которая поможет вам понять как работать с регулярными выражениями.

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

Но как то у нас временно не работала сеть и тогда я решил написать для себя маленькую утилиту для разбора текста с помощью регулярных выражений, создал WPF приложение, а для разбора текста использовать стал всем известный класс Regex, и уже через пол часа я воспользовался первой версией данной утилиты. Потом в течении двух недель я её доработал по мере необходимости и ловле мелких багов :). После выходных на работе поделился с коллегами, но все восприняли без комментариев очередную утилиту, которую нужно копировать или запускать по сети, кроме одного старшего(не по возрасту) товарища, который сказал, что было бы хорошо сделать её в виде расширения для Visual Studio 2010. И я начал думать о реализации своего расширения…

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

Регулярные выражения (РВ) это, по существу, крошечный язык программирования, встроенный в Python и доступный при помощи модуля re. Используя его, вы указывается правила для множества возможных строк, которые вы хотите проверить; это множество может содержать английские фразы, или адреса электронной почты, или TeX команды, или все что угодно. С помощью РВ вы можете задавать вопросы, такие как «Соответствует ли эта строка шаблону?», или «Совпадает ли шаблон где-нибудь с этой строкой?». Вы можете также использовать регулярные выражения, чтобы изменить строку или разбить ее на части различными способами.

Вашему вниманию очередной выпуск подкаста о веб-разработке «Сделайте мне красиво!»

Show notes:

• HSL нотация цвета в CSS3
• Продвинутая декорация блока c border-image + генератор border-image
• Фиксим border-radius под webkit
• Мобильный HTML5 Boilerplate
• Разъяснение регулярных выражений от Mozilla
• Правила хорошего тона в «Фотошопе»

Наши ссылки: RSS и лента на rpod.ru

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



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

Введение

Прошло примерно 1.5 года с момента разработки первой версии расширения Regex Tester, я уже писал один пост про его создание. В общем я считаю, что мой первый опыт удался, так как расширение имеет хороший рейтинг и на текущий момент его скачали 12 тыс. раз.
В 2010 году у меня были планы довести расширение до ума. Часть функционала я уже тогда начал реализовывать, но в профессиональной жизни у меня произошло интересно событие — я стал Java-разработчиком, перейдя на другой проект, но это совсем другая история. А сейчас я кратко напишу, что изменилось в новой версии расширения и почему я решил его доработать.

Это четвертый вебинар из цикла бесплатных вебинаров по автоматизации тестирования.
Видеозапись (продолжительность 1 час 10 мин.):

Темы и детали видеозаписи под катом

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

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

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

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

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

Хочу обратить внимание хабрасообщества на возможную «уязвимость» в TCL, PostgreSQL и теоретически в некоторых других системах, использующих модули ругулярных выражений или NFA утилиты, изначально написаные самим Генри Спенсором (Henry Spencer). Измененных исходников можно найти добрую сотню (у того же Sun Microsystems, UUNET и т.д.). И хотя, я не думаю, что баг существует изначально с далеких 90-х, хотя бы потому, что кода где возникает эта ошибка я у Генри, в старых его источниках, не нашел, проверить ваши системы все-таки стоит.

И так ошибка: это busyloop на стадии компиляции регулярного выражения вида (((((x)*)*)*)*)*. Причем именно не исполнения, а компиляции, т.е. если есть проверка валидности регулярки и она базируется на том же коде NFA — имеем тот же безконечный цикл + 100% cpu usage.

Ошибку нашли коллеги по opensource проекту TCL, во всех его актуальных версиях (включая develop). Зная, что Postgres использует похожее API, нетрудно было выяснить, что скармливание этого регулярного выражения Postgres приводит к полному зависанию потока (процесса), отрабатывающего запрос.

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

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

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

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