• Отрицательное lookbehind-условие '(?<!re)'
Соответствует, только если перед ним не следует регулярное выражение re.
Примеры:
$test = "HTML is a document description-language and not a programming-language";
$test =~ m/(?<=description-)language/
Найдет первое "language" ("description-language"), как предваряемое "description-", а
$test = "HTML is a document description-language and not a programming-language";
$test =~ m/(?<!description-)language/
Найдет второе "language" ("programming-language").
Следующие примеры выполнены в .Net. Поиск осуществляется в следующем тексте:
void aaa {
if (…) {
try {
…
} catch(Exception e1) {
MessageBox.Show(e1.ToString(), "Error");
} finally {
listBox1.EndUpdate();
}
}
}
Положительный LookaheadШаблон {(?=[^{]*}).*?} находит самый глубоко вложенный блок, выделенный фигурными скобками. Результат выполнения:
1. { … }
2. { MessageBox.Show(e1.ToString(), "Error"); }
3. { listBox1.EndUpdate(); }
Положительный LookbehindШаблон (?<=trys*){(?=[^{]*}).*?} находит самый глубоко вложенный блок выделенный фигурными скобками, перед которым есть try. Результат выполнения: { … }.
Отрицательный LookbehindШаблон (?<!trys*){(?=[^{]*}).*?} находит самый глубоко вложенный блок выделенный фигурными скобками перед которым нет слова try. Результат выполнения:
1. { MessageBox.Show(e1.ToString(), "Error"); }
2. { listBox1.EndUpdate(); }
В этих примерах жирным выделены Lookahead– и Lookbehind-условия.
Еще примерыВот еще несколько примеров использования регулярных выражений, более приближенных к реальной жизни.
Перестановка двух первых слов:s/(S+)(s+)(S+)/$3$2$1/
В других языках замена обычно делается отдельным методом, одним из параметров передается шаблон замены, где можно использовать переменные $1, $2, $3 и т.д.
Поиск пар name=value:m/(w+)s*=s*(.*?)s*$/
Здесь имя – в $1, а значение – в $2.
Чтение даты в формате YYYY-MM-DD:m/(d{4})-(dd)-(dd)/
Теперь YYYY – в $1, MM – в $2, DD – в $3.
Выделение пути из имени файла:m/^.*(\|/)
В "Y:KSregExp!.NetCompilationms-6D(1).tmp" такое выражение найдет "Y:KSregExp!.NetCompilation"
Будучи примененным к файлу C++, выделяет комментарии, строки и идентификаторы "new", "static char" и "const". Работает и на старом RegExp:
("(\"|\\|[^"])*"|/*.**/|//[^r]*|#S+|b(new|static char|const)b)
Выделяет тег <a href=":"> в HTML-коде:
<s*a("[^"]*"|[^>])*>
Регулярные выражения в .Net
Как уже упоминалось выше, регулярные выражения широко используются практически во всех языках программирования. Каждый из языков накладывает свой отпечаток на синтаксис регулярных выражений, хотя суть и не меняется. Так, например, то, что в JScript пишется /a.c/, в VBScript, естественно, будет "a.c".
Microsoft всегда старается сделать все по-своему, поэтому синтаксис регулярных выражений .NET несколько расширен, и включает ряд новых возможностей – например, поиск справа налево. Пишущие по-арабски поймут, зачем это нужно.
Символ Значение w Слово. То же, что и [a-zA-Z_0-9]. W Все, кроме слов. То же, что и [^a-zA-Z_0-9]. s Любое пустое место. То же, что и [ fnrtv]. S Любое непустое место. То же, что и [^ fnrtv]. d Десятичная цифра. То же, что и [0-9]. D Не цифра. То же, что и [^0-9].
Кстати, регулярные выражения в .Net умеют понимать русский язык. Особенно интересно и слегка непривычно то, что они делают это корректно. В Help'е сказано, например, что при поиске границы слова с использованием b работают символы [a-zA-Z_0-9], однако верить этому не следует. На практике это не так. Русские буквы ищутся и находятся не хуже латиницы. Впрочем, может быть, к release-версии все будет приведено к соответствию с Help'ом.
Классы, определяющие регулярные выражения .NET – это часть библиотеки базовых классов Microsoft .NET Framework, что означает одинаковую реализацию регулярных выражений для всех языков и средств, работающих с CLR (Common Language Runtime) – естественно, за вычетом языковых особенностей, типа уже упоминавшихся escape-символов.
В .Net появились условные сравнения (conditional evaluation). Позволяет варьировать используемые шаблоны в зависимости от результатов поиска предыдущего подвыражения. Это заставит, например, пропустить правую скобку, если левая уже была найдена подвыражением. К сожалению, информация об этом пока слишком обрывочна, чтобы говорить об этом подробнее.
Положительный и отрицательный lookbehind. Последние версии Perl поддерживают такую возможность для строк фиксированной длины. У машины регулярных выражений .NET эта возможность не ограничена ничем, кроме здравого смысла.
Кроме перечисленных, есть еще и масса других, менее значительных дополнений и расширений, но перечислять их все нет ни сил, ни желания. Особенно учитывая, что всё может измениться без предупреждения.
Большая ложка дегтяУвы, Microsoft традиционно пребывает в состоянии творческого безумия, и правая рука у него не знает, что делает левая (подробнее об этом см. "Средства программирования). Поэтому в саму среду Microsoft .Net встроена ДРУГАЯ библиотека регулярных выражений. Если они это изменят до выхода финальной версии (все, что вы здесь читаете, написано на базе beta 1), честь им и хвала. Если же не изменят (например, по забывчивости), разработчикам, скорее всего, придется работать по принципу "одним пользуемся, другое продаем".
Компиляция и повторное использование регулярных выраженийПо умолчанию Regex компилирует регулярные выражения в последовательность внутренних байт-кодов регулярных выражений (это высокоуровневый код, отличный от Microsoft intermediate language (MSIL)). При исполнении регулярных выражений байт-код интерпретируется.
Если же конструировать объект Regex с опцией 'с', он компилирует регулярные выражения в MSIL-код вместо упомянутого байт-кода. Это позволяет JIT-компилятору Microsoft .NET Framework преобразовать выражение в родные машинные коды для повышения производительности.
Но сгенерированный MSIL нельзя выгрузить. Единственный способ выгрузить код – это выгрузить из памяти приложение целиком. Это значит, что занимаемые скомпилированным регулярным выражением ресурсы нельзя освободить, даже если сам объект Regex уже освобожден и уничтожен сборщиком мусора.
Из-за этого казуса приходится задумываться – стоит ли компилировать регулярные выражения с опцией 'с', и если да, то какие и сколько. Если приложение должно постоянно использовать множество регулярных выражений, придется обойтись интерпретацией. А вот если есть несколько постоянно используемых регулярных выражений, можно и скомпилировать их для ускорения работы.
Для повышения производительности Regex кэширует в памяти все регулярные выражения. Поэтому повторного разбора при каждом очередном использовании не происходит. Такой подход несколько уменьшает разницу в производительности компилируемых и интерпретируемых регулярных выражений.
Приложение RegExpTest
В качестве примера использования регулярных выражений мы создали .Net-приложение, использующее регулярные выражения для поиска в тексте.
Рис.2. Приложение RegExpTest
Мода – великая вещь, поэтому писать приложение следует не на Java, не на VB, а на C#. Это модно, и доказывает, что автор не стоит на месте, а работает над собой.
Отрывки кода этого примера приведены в Листинге 1. Само приложение можно скачать с нашего ftp-сайта.
Листинг 1. Использование регулярных выражений в C#
// Класс для хранения информации о найденном вхождении
protected class MyItem {
public MyItem(string Match, int Index, int Len) {
this.Match = Match;
this.Index = Index;
this.Len = Len;
}
public override string ToString() {
return Index.ToString() + ", " + Len.ToString() + ", " + Match;
}
public string Match;
public int Index;
public int Len;
}
…
protected void Parce() {
int iCountMatchs = 0;
try {
// Очищаем лист-бокс
listBox1.Items.Clear();
statusBar1.Text = "Parsing…";
// создаем объект re, задавая в его конструкторе
// шаблон и опции
Regex re = new Regex(tbPattern.Text, tbOptions.Text);
// Выполняем поиск заданного выше шаблона внутри
// текста и текстового поля
tbTextForSearch MatchCollection mc = re.Matches(tbTextForSearch.Text);
iCountMatchs = mc.Count;
// Выводим информацию о количестве найденных вхождений…
