Comments 76
Простите, но я всё-таки напишу, не для хейта, а просто для понимания, несколько люди разные.
Я бы никогда и нигде не хотел встретить документацию или обучающий материал, написанный в подобном стиле!
Первое — это картинки. Я люблю, когда картинки иллюстрируют текст и помогают в нём разобраться, но здесь они настолько выбиваются из контекста и отвлекают… игнорировать их не получается — большие и яркие, смысла в них особо нет, помощи тоже. Скорее они несут развлекательную функцию, которая мне мешала бы понимать текст.
Второе — это дикое количество текста для примитивных случаев. Например, в самом конце статьи:
RegEx: Ольга
Замена: Макар
Текст был: Привет, Ольга!
Текст стал: Привет, Макар!
Вот такой пример плюс картинка уже занимает один экран моего телефона. Это просто выматывает при чтении. Более того, воды в тексте столько, что первую треть, наверное, статьи можно заменить парой абзацев.
Для меня это показатель крайне низкого качества материала. Выучить что-то по такой штуке будет сложно — максимум, составить общее представление и использовать потом как постоянную шпаргалку.
На этом фоне фактические ошибки вроде экранирования закрывающей квадратной скобки "]" или "$matches[1] в php вместо \1" даже как-то и неважны уже.
Просто документацией Mozilla, например, можно пользоваться, а этой статьей — нет.
Впрочем, судя по комментам выше, кому-то нравится и такой стиль. Удивительно, но факт)
regular-expressions.mobi/wordboundaries.html?wlr=1
КМК как и на все такие вопросы ответ: что зависит от конкретной реализации и в каждом случае нужно взвешивать все "за" и "против".
Все нормально у регулярок с производительностью.
И вообще, не нужно на пустом месте озабачиваться "производительностью".
Инструмент надо выбирать по задаче, а не воображаемым проблемам с производительностью. Если проблема решается регуляркой, то надо использовать регулярку. Если регулярка не нужно — то и не использовать. Просто потому что не нужна, а не потому что "непроизводительно".
Надо запомнить одно простое правило — проблемы с производительностью начинаются тогда, когда твой код пытается обработать неадекватно большой объем данных. Для решения проблемы надо этот объем сократить. А вопрос "какую функцию использовать" не имеет никакого отношения к производительности.
Картинки и подача прикольные. Такая статья про регулярки имеет право на существование, даже несмотря на то, что про них уже всё давно написано)
А вот задачу вы выбрали, конечно, ту ещё. Написать корректную регулярку для поиска дат — это уже прям уровень уверенного владения. Поэтому в статье вы не добрались до проверки дней в конкретном месяце, високосных годов и ограничились двумя столетиями :-)
Найдет: testt
Не найдет: testtest
Он найдет «testt» в «testtest», поэтому пример не самый удачный.
Да да, если еще дни в конкретном месяце проверять, ...
Во всяком деле надо знать меру. Так и в регулярках. Пишу на perl уже 20 лет.
Чтобы дни проверять в регулярку можно вставить вызов функции.
import re
from datetime import date
def parce_date(s: str) -> date:
try:
return date.fromisoformat(
re.sub(r'^(\d\d)\.(\d\d)\.(\d{4})$', r'\3-\2-\1', s))
except ValueError as e:
raise e # тут пишем обработчик, какой хотим
print(parce_date('05.08.2015')) # ok
print(parce_date('99.99.2000')) # error
Кто-то сделает одну задачку за 5 минут, а кто-то за 35.Не вижу противоречия — учиться можно до полного просветления, а решать рабочие проблемы желательно в срок. В императивном стиле почти всякий джун что-нибудь да изобразит, а в декларативном может и застрять. Я вот об этом.
Если это, конечно, не учебный процесс — тогда идите до конца )
Атрибут BACKGROUND-COLOR не сработал, поэтому я буду дублировать регулярки текстом (чтобы можно было скопировать себе) и рисунком, чтобы показать, что именно regex нашел:
Для того чтобы вставить текст со своим HTML оформлением как изображение можно использовать как контейнер SVG с элементом foreignObject. Я этот метод использовал в статье "Горизонтальный блог".
Пример
Вставляем html в SVG
Имя файла: html-in-svg.svg
<svg xmlns="http://www.w3.org/2000/svg" width="100%" height="100%"> <foreignObject x="0" y="0" width="100%" height="100%" requiredExtensions="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml"> <p><strong>Текст</strong>: Море, море, море, океан</p> <p><strong>Regex</strong>: море</p> <p><strong>Найдет</strong>: Море, <mark>море</mark>, море, океан</p> </html> </foreignObject> </svg>
Файл необходимо загрузить на хостинг который принимает SVG изображения и отдаёт их напрямую.
Вставляем SVG изображение в статью например так:
Markdown:
HTML:
<img src="https://gateway.ipfs.io/ipfs/bafkreidtapjgkapdgewe2wogb3dhsblgk5osz7fkm4yjvhzqqzcb5voa2e" alt="Текст: Море, море, море, океан Regex: море Найдет: Море, море, море, океан"/>
Результат:
Статья — супер просто!
В какой-то момент мне показалось, что в одном из примеров вы ошибочно поставили прямой слеш вместо обратного. Но он вроде был какой-то не совсем прямой. В общем, из-за того, что эта строка набрана курсивом, айфон отображает её практически с прямыми слешами.
Может вы поправите в статье, так как курсив там всё равно не нужен.
Пишу сюда, а не в личку, т.к. картинку прикрутить можно только тут, а без картинки я не объясню.
Картинка
Правильно ли я понимаю, что Regex на особо предназначен для поиска вида: «первые три символа пятой строки»?
Есть простой способ взять пятую строку? Или пятьсот пятую?
Или трехсот первое слово?
Именованные группы - весьма полезно для регэкса как унифицированного АПИ
let dateRegexp = /(?<year>[0-9]{4})-(?<month>[0-9]{2})-(?<day>[0-9]{2})/;
let str = "2019-04-30";
let groups = str.match(dateRegexp).groups;
alert(groups.year); // 2019
alert(groups.month); // 04
alert(groups.day); // 30
Не пойму, как в исключения добавить все буквы, цифры и знак минус. С буквамии цифрами все понятно [^a-zA-Z0-9_] А вот как туда еще и знак минуса добавить?
Экранировать? \-
Последним в списке
[^a-zA-Z0-9_-]
На мой взгляд, лучше всё-таки экранировать. В рамках скобок символ "-" может являться разделителем диапазона, т.е. спецсимволом. И в представленном выражении уже дважды используется именно в этой роли. Когда есть экран — всё сразу понятно, никакой двусмысленности.
В re.findall такой метод работает, а в re.match почему то нет ((
Регулярные выражения (regexp) — основы