Xpoint
   [напомнить пароль]

Статья "Учимся регулярно выражаться"

Метки: [без меток]
2006-10-24 14:27:24 [обр] Илья Лебедев aka WingedFox(0/65)[досье]

Здравствуйте

Покритикуйте, пожалуйста, статью Учимся регулярно выражаться.

Заранее спасибо 8*)

спустя 25 минут [обр] гоша(0/39)[досье]
Непонятно на кого расчитано. Начинающих отпугнет "словарь" и то, что всё в одну кучу. Опытным не нужно предисловие. ИМХО оставить вторую часть типа как "рецепт". Выражения лучше записывать с "x" и комментариями, тогда и разжевывать так не придется. Неплохо бы пример текста, и что выражение в нем находит.
спустя 19 минут [обр] Илья Лебедев aka WingedFox(0/65)[досье]

Рассчитано на начинающих, которые плачутся "не понимаю, как выражение работает".

Такую запись я сделал специально, чтобы подключалась голова до того, как пишется выражение.
Задача - научить "визуализировать" рег.

PS: а пример текста есть. В разделе "Задача".
Добавил выделение, чтобы было более заметно.

спустя 15 минут [обр] Илья Cтpeльцын aka SelenIT(0/171)[досье]

Илья Лебедев aka WingedFox[досье]
У меня тоже есть пара претензий к словарю (возможно, субъективных и несправделивых). Буквально с первых строк застрял на "операторе" (вместо привычного для меня "метасимвола" — моя логика: есть символы, которые означают сами себя, а есть мета-символы, которые означают что-то другое). Затем, максимальный/минимальный vs жадный/нежадный квантификаторы — по-моему, тут избыточность, вторая пара вполне интуитивна и самодостаточна.

Далее, "неудачное совпадение" — по-моему, просто сбивает с толку (как это так, совпадение есть, но "некачественное", что ли?), звучит примерно как "осетрина не первой свежести". Почему бы не сказать просто "совпадение" и "несовпадение" ("отсутствие совпадения", на худой конец)?

И еще мелочь, но... почему-то мне режет глаз, когда то, что делает тег <p>, называют по-русски "параграфом". Лично для меня параграф — это текст страниц эдак на 2-3 после знака §, а то, что разделяется отступами/красной строкой — это абзац (и яндекс того же мнения).

Но за описание процесса формализации и последовательного усложнения регурялки — Respect!

спустя 32 минуты [обр] Илья Лебедев aka WingedFox(0/65)[досье]

Илья Cтpeльцын aka SelenIT[досье]

застрял на "операторе" (вместо привычного для меня "метасимвола"

Имхо, значение слова "оператор" более определённо, чем "метасимвол". Используя именно такое определение, было легче объяснить, зачем он нужен. Хотя, метасимвол и привычнее.

Первая пара появилась после первых тестов статьи, когда возникли вопросы "что это значит".
Пожалуй, имеет смысл вынести её в сноски.

С "неудачным совпадением" - отдельная проблема. Я описываю процесс, а "несовпадение" это чёткий и однозначный результат. Это была попытка показать, что переход к альтернативному варианту происходит в процессе поиска. Похоже, что не слишком удачная. 8*)

Параграф идёт из спецификации. Конечно, Лингво ставит "абзац" на 1 место, но "параграф" тоже правомерен.
Ну и как-то прижилось уже обозначение <p> параграфом.

Спасибо за отзыв.

спустя 29 минут [обр] Илья Cтpeльцын aka SelenIT(0/171)[досье]

Илья Лебедев aka WingedFox[досье]

Имхо, значение слова "оператор" более определённо, чем "метасимвол".

Полностью согласен — именно поэтому мне трудно принять метасимволы как операторы, хотя по сути оно, видимо, так и есть :)

С "неудачным совпадением" - отдельная проблема. Я описываю процесс...

Мне оно бросилось в глаза применительно к проверке позиции. По-моему, там как раз однозначный результат (хоть и промежуточный): если ожидалось несовпадение с подшаблоном, а найдено совпадение (и наоборот) => проверка не выполнена (конечный результат — несовпадение со всем шаблоном).

Параграф идёт из спецификации

Спецификация-то англоязычная, в английском языке "paragraph" означает именно то, что надо (иначе тег назывался бы не <p>, а <abz>:). И если бы в русском языке не было слова "параграф" с другим значением, я бы не возражал против такого неологизма-заимствования (в отличие от термина "иконка", он был бы совершенно нейтральным). Но если калька имеет в русском языке другое значение, а для самого понятия есть привычный термин "абзац" (вдобавок он короче:) — имхо, незачем вводить/поддерживать путаницу. Согласитесь, фраза а-ля "за последнюю декаду Интернет пережил драматические изменения" некорректна :)

спустя 1 час 37 минут [обр] Сергей Чернышев(3/589)[досье]
Критикую - почему она не в Базе Знаний Xpoint?
спустя 5 часов [обр] Илья Лебедев aka WingedFox(0/65)[досье]

Илья Cтpeльцын aka SelenIT[досье]
Внёс исправления, со многим согласен сам... 8*)
Спасибо за конструктивную критику!

Сергей Чернышев[досье]
Наверное потому, что у меня сейчас нет ни желания, ни времени разбираться с её интерфейсом.
Может быть в будущем...

спустя 21 минуту [обр] Илья Лебедев aka WingedFox(0/65)[досье]
Статья переехала вместе на новое место:
http://debugger.ru/articles/nativeregexp
спустя 1 час 45 минут [обр] Илья Cтpeльцын aka SelenIT(0/171)[досье]

Илья Лебедев aka WingedFox[досье], право же, несколько минут моего ворчания по мелочам не стоят отдельной благодарности — наверняка десятки людей оказали куда большую помощь... Однако, мне понравилось придираться:), так что, если не возражаете — очередная порция.

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

Чуть раньше, по-моему, небольшая логическая "петля" с противоречием: операторы — символы РВ, не участвующие в совпадении (из дефиниции), но первый класс операторов — "символы" — по смыслу явно как раз "участники совпадений". Может, вообще выкинуть одну строчку перед описанием оператора .? Ведь из определения достаточно ясно: если символ не оператор — он лишь участвует в совпадении и только...

Далее, "модификатор m - <склеивание> всех физических строк в одну" — нет ли ошибки? Может, правильнее s (по крайней мере, по моему опыту в PHP)?

И совсем уж мелочи:

  • в определении квантификатора остался "максимальный" — наверное, надо бы заменить на "жадный", для единообразия;
  • в проверке позиции, видимо, редактор самовольно заменил <= на "⇐";
  • есть мелкие очепятки (где-то 3-5 шт.). И лично я, конечно, написал бы "нежадный" слитно, для гармонии с "незахватывающими"... но в мануале по PHP оно стоит раздельно, так что, видимо, надо равняться на него (хотя ИМХО в этом мануал, точнее его переводчики, не совсем правы:).

Еще раз прошу прощения за занудство:)

спустя 10 часов [обр] Илья Лебедев aka WingedFox(0/65)[досье]

Илья Cтpeльцын aka SelenIT[досье]
Только за пропущенные мной "модификаторы" Вам отдельная и огромная благодарность!

Может, вообще выкинуть одну строчку перед описанием оператора .? Ведь из определения достаточно ясно:

В том-то и дело, что не ясно. Имхо, на таких моментах лучше расставлять акценты.

 "модификатор m - <склеивание> всех физических строк в одну" — нет ли ошибки? Может, правильнее s

s переключает . в режим совпадения с переводами строк.

И лично я, конечно, написал бы "нежадный" слитно

Это отдельная история. Например: http://rus.1september.ru/2003/10/6.htm

спустя 38 минут [обр] гоша(0/39)[досье]

m влияет только на то, что ловят ^ и $. Поскольку ни то, ни другого у вас нет, он видимо не нужен.

опечатки в коде для таких статей критичны (напр. "<(\w )[^>]*>((?:(?!</\1>).)*))</\1>"). И такое ощущение, что плюс везде на пробел заменился.

спустя 6 минут [обр] гоша(0/39)[досье]
да, и "нежадный" в данном случае лучше всё-таки слитно, т.к. это качественное прилагательное (= "обладающий свойством нежадности"), а не отрицание.
спустя 27 минут [обр] Дмитрий Кононов(0/16)[досье]

Внесу и я свои 5 копеек.

Опечатка.
В разделе "Словарь операторов" надо заменить "(?< =" на "(?<=", т.е. убрать лишний пробел.

Теперь пунктуация.
Во втором абзаце в предложении "Здесь вступают в работу регулярные выражения..." лучше поставить двоеточие, а не тире.
В разделе "Шаг 6. Добавление модификаторов и ограничителей" заменить "Самые распространённые это:" на "Самые распространённые - это" (тире вместо двоеточие).
В том же разделе в подразделе "Модификаторы" не хватает запятой после "например", а после "здесь же" запятая не нужна.
В разделе "Шаг 3. Выделение требуемых тегов."
заменить
"Используя регулярное выражение полученное на предыдущем шаге мы можем"
на
"Используя регулярное выражение, полученное на предыдущем шаге, мы можем".
Причастный и деепричастный обороты.

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

В разделе "Словарь операторов" фразу "проверка позиции" я бы заменил на "позиционная проверка". Мне кажется, она лучше отражает суть, т.к. "lookahead/lookbehind assertion" на русском звучат как опережающая и ретроспективная проверка соответственно.

И еще. В заголовках не ставятся завершающие точки. Уберите их начиная с заголовка "Шаг 3..." по "Шаг 6..."

Почему у вас кавычки по тексту заменены на символы "<" и ">"?
Например, фраза "<как выбрать содержимое определённого тега>".

Из того, что нашел беглым просмотром.

спустя 10 минут [обр] Дмитрий Кононов(0/16)[досье]
Похоже, что гоша[досье] прав насчет плюсов. Везде заменились на пробелы.
спустя 21 минуту [обр] Илья Cтpeльцын aka SelenIT(0/171)[досье]

Илья Лебедев aka WingedFox[досье]

s переключает . в режим совпадения с переводами строк.

Ну да. В результате РВ смотрит на текст как на одну большую строку и не "спотыкается" на первом \n. Имхо, это больше похоже на "склеивание в 1 физ. строку". Действие m, как справедливо заметил гоша[досье], дает скорее обратный эффект — каждая строка обрабатывается отдельно...

на таких моментах лучше расставлять акценты

Может быть, лучше расставить их прямо в определении оператора? Или до него: явно написать, что символы в составе РВ бывают двух видов — "просто символы" aka литералы (тем более, что этот термин у Вас все равно вводится в примечании) и операторы; операторы — это... (и далее по тексту).

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

спустя 1 час [обр] Илья Лебедев aka WingedFox(0/65)[досье]

Дмитрий Кононов[досье]
Спасибо. БОльшая часть корректировок принята. 8*)

А ведь, когда-то, у меня были одни пятёрки по русскому....
Пора обратно, в школу.

"(?< =" на "(?<=", т.е. убрать лишний пробел.

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

Ёлочки и плюсы потерялись при импорте, поменялись на скобки и пробелы. Исправлено.

Илья Cтpeльцын aka SelenIT[досье]
Спасибо, лишнее отрезал =)

Задачу я поставил по поиску однострочных совпадений. В принципе, по специфике рега ни s ни m не нужны. 8*)
Переписал концовку, чтобы рег мог совпасть с многострочным содержимым.

По спецификации:

/s enables "single-line mode". In this mode, the dot matches newlines.
/m enables "multi-line mode". In this mode, the caret and dollar match before and after newlines in the subject string.

Признаю, заблуждался =)

спустя 1 час 43 минуты [обр] Закиров Руслан(12/341)[досье]

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

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

# ( - начнём захватывать совпадения в последовательность
# (?: - начнём захватывать совпадения в последовательность, но не сохраняем её

Не ясно, что первый вариант сохрянет, добавьте "... в последовательность с сохранением"

"наборы символов" - "классы символов"

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

Запись \n неоднозначна(может возникнуть путаница с символом новой строки) и к тому же синтаксис \[0-9] не рекомендуется использовать, предпочтительно $[0-9].

И самое главное

на форумах очень часто задают вопрос «как выбрать содержимое определённого тега» и «как разобрать HTML разметку».

На правильных форумах людей отправляют в сторону соотвтствующих модулей.

Может стоило начать с других примеров, например с поиска IP адресов в тексте, вот несколько шагов:

/\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}/

/\d{1,3}(?:\.\d{1,3}){3}/

my $unit = qr/\d{1,3}/; /$unit(?:\.$unit){3}/

my $unit = qr/25[0-5]|2[0-4][0-9]|[0-1]?[0-9]{1,2}/;
/$unit(?:\.$unit){3}/

my $unit = qr/25[0-5]|2[0-4][0-9]|[0-1]?[0-9]{1,2}/;
/(?<!\d)$unit(?:\.$unit){3}(?!\d)/

Вам решать.

спустя 26 минут [обр] arto(42/494)[досье]
можно еще сравнивать производительность разных решений.
спустя 1 час 11 минут [обр] Даниэль Алиевский(0/125)[досье]

В самом начале резануло:

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

Какое-то очень странное сравнение "человеческих ресурсов" и регулярных выражений. Конечно же, никакие регулярные выражения - и даже сверхсложные программы - не сравнятся с человеком по возможностям анализа текста. Да и "автоматизированную обработку" далеко не всегда можно сделать с помощью одних regexp-ов. Скажем, делать на них поиск по русскоязычному сайту - довольно дурная идея. У регулярных выражений есть множество областей применения, прежде всего для обработки текстов на искусственных языках (типа HTML, языков программирования и т.п.), но по Вашему введению возникает совсем другое впечатление.

Далее, установка, что "регулярные выражения монстроподобны и сложны для восприятия" мне кажется не вполне корректной. Если нормальную, понятную C-программу записать в одну строку без какого-либо форматирования, результат тоже будет нечитаемым. В Perl регулярное выражение можно записывать в много строк, комментируя каждый оператор - модификатор "x". В таком варианте regexp, как мне кажется, не только не менее понятен, но, может быть, куда более очевиден, чем программа на традиционном языке типа Pascal, решающая эквивалентную задачу.

спустя 16 минут [обр] Сергей Чернышев(3/589)[досье]

Илья Лебедев aka WingedFox[досье]
Я вас понимаю, хотя интерфейс не сильно отличается от интерфейса форума.

Кстати, если бы вы делали это в wiki, то половины этой темы просто не было бы - все опечатки исправили бы те кто их нашел, да и много чего еще.

спустя 27 минут [обр] Superman(0/16)[досье]
Сергей Чернышев[досье] статья и так в вики
спустя 28 минут [обр] Илья Лебедев aka WingedFox(0/65)[досье]

Сергей Чернышев[досье]
Гм... Так это и есть DokuWiki + несколько плагинов =)
Только для редактирования контента требуется зарегистрироваться, потому как спамроботы уже очень хорошо знают про этот движек.

Даниэль Алиевский[досье]
Исправил немного вступление, чтобы отделить мух от котлет.
А установка на "монстроподобность" идёт от самих начинающих. У меня был период, когда за день сваливалось до десятка вопросов и тема была общая "как разобраться с этим бредом".
Кстати, из читателей на "монстроподобность" указывали только те, кто очень хорошо понимает реги.

Ну и потом, я только 1 раз видел в исходниках рег, откомментированный через /x
И второй раз - в книге Фридла.
Так что задача "научить читать и записывать реги" всё ещё существует. Надеюсь, моя статья поможет в этом.

Закиров Руслан[досье]
Переводить "Lookaround", "Lookforward" и "Lookbehind" так как Вы предлагаете - отнюдь не лучший вариант =)
А пример был выбран по статистике вопросов, статью я начал писать тогда, когда меня достало объяснять это решение.
Конечно, есть и более простые вопросы, на которых лучше учиться. 8*)

и к тому же синтаксис \[0-9] не рекомендуется использовать, предпочтительно $[0-9].

Где не рекомендуется? И какие языки позволяют использовать обращение к совпадению при поиске через $[0-9]?

Внёс уточнения в словарь, спасибо.

спустя 3 дня [обр] Сергей Чернышев(3/589)[досье]
Ок. Я сдаюсь - я пытался вас подтолкнуть к мысли, что База Знаний Xpoint тоже хорошее место для статей.
Powered by POEM™ Engine Copyright © 2002-2005