Я в шоке! Почему до сих пор никто не догадался расширить поиск по странице регулярными выражениями? Можете кто-нибудь написать подобное расширение?

Нашел полезное и довольно удобное расширение для 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.

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

Итак, задача ...

На входе алгоритма есть набор строк S1..SN. Требуется, по данным строкам построить такое минимальное регулярное выражение R, чтобы R(Si)=true, i [1,N] (N порядка нескольких тысяч).
Требование минимальности — не строгое, и доказывать минимальность построенного regexp'a не требуется. Если строки S1..SN обладают некоторой схожей структурой, то regexp должен выявлять эту структуру. Стандартное задание программисту — в меру конкретизировано, но и с некоторой свободой действий.

Несколько лет назад я думал, что regexp осуществляет линейный поиск по тексту, но какое моё удивление было, когда я понял, что это не так. Тогда я убедился на собственном опыте, что от простой смены местами а и b в схеме (...a...)|(...b...) поменялся полностью результат.

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

В книге Дж. Фридла «Регулярные выражения» есть прекрасная табличка, которую хочу тут привести.
Регулярные выражения открывают широкие возможности для поиска и замены в любом тексте. Используя регулярные выражения можно гибко и просто обрабатывать текстовые документы. Одним из простейших применений регулярных выражений является поиск текста — во многих текстовых редакторах предусмотрена возможность поиска по шаблонам регулярных выражений В regexp существует несколько типов метасимволов выполняющих разные функции, давайте кратко их рассмотрим:

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

 

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

Часто ли вы используете регулярные выражения? Задумываетесь ли вы о том, на сколько оправдано их использование? Каковы альтернативы, каковы возможности и ограничения? Какова цена применения регекспа?

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

Настоящей статьёй, я призываю одуматься задуматься.

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

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

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

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

Представим, что у вас есть код:

1. chomp(my $input = <STDIN>);
2. my $kinda_secret = get_data($input);
3. if(defined $kinda_secret) {
4.  print 'Your secret is: ', $kinda_secret
5. }
6. else {
7.  print 'No soup for you'
8. }
9.  
10. sub get_data {
11.  my $input = shift;
12.  open my $fh, '<', 'data.file' or return;
13.  my $retval;
14.  while(<$fh>) {
15.   if(/^$input:(.+?)$/) {
16.    $retval = $1;
17.    last
18.   }
19.  }
20.  close $fh;
21.  
22.  $retval
23. }

* This source code was highlighted with Source Code Highlighter.

Ничего экзотичного. Вариации такого кода могут встретиться где угодно. Смысл кода, надеюсь, ясен (я не имею в виду его практическую ценность).

Вы уже увидели ошибку? Если да, то дальше можно не читать.

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

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

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

Регулярные выражения могут оказать Вам неоценимую услугу при их разумном применении в 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.

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

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

Регулярные выражения — это арифметика для алгоритмов. Они доступны во многих языках программирования, редакторах и настройках приложений. Как и сложение с умножением они просты в использовании.
Но для правильного и эффективного использования regexp-ов нужно понимание того, как они работают. Я постараюсь описать принцип работы регулярных выражений, покажу в каких случаях бывают проблемы и как их решать.

В продолжение общих советов.

It is a typical backtracking regular expression engine, but does some tricks to avoid redundant backtracking

Из релиза 10.00

Вот в чем эти «tricks» заключаются. Смотрите простой пример:
javascript:alert(/(t+){2}/.test('tt'));

IE6,IE8: true
Firefox: true
Safari: true
Chrome: true
Opera9: true

Opera10: false

Будь на чеку, %username%.

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

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

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

Существует множество материалов по регуляркам, множество готовых шаблонов, которые можно просто взять и использовать в валидаторах, поисках и т.д. Обычно это правильные регулярки, для валидации, например, введенного адреса электронной почты. Но мне недавно выпала задача по поиску «неправильных» данных (когда пользователи знают что нельзя писать свои контакты, но пишут извращенными способами), а конкретно email'ов и телефонов.

Задача стояла такая: "Не дать пользователям публиковать свои номера телефонов и адреса электронной почты на сайте".

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