Software Engineer
0,0
рейтинг
12 августа 2009 в 22:22

Разработка → 8 полезных регэкспов с наглядным разбором

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

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


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

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



2. Юзернейм


Буквы, цифры, дефисы и подчёркивания, от 3 до 16 символов.

Паттерн: /^[a-z0-9_-]{3,16}$/
username

3. Пароль


То же, что и юзернейм, только от 6 до 18.

Паттерн: /^[a-z0-9_-]{6,18}$/
password
От себя: более кратко — /^[\w_]{6,18}$/. Аналогично для юзернейма.

4. Шестнадцатиричный цвет


Символ # (необязательно), затем слово, состоящее из букв от a до f или цифр, длиной 3 или 6.

Паттерн: /^#?([a-f0-9]{6}|[a-f0-9]{3})$/
hex

5. XML тэг


За открывающей скобкой < должно стоять слово из букв — имя элемента, затем могут быть атрибуты — любые символы, кроме закрывающей скобки >. Далее — любой текст (содержимое) и закрывающий тэг, т.е. <имя />, или как минимум один пробел, слэш и закрывающаю скобка (самозакрывающийся тэг).

Паттерн: /^<([a-z]+)([^>]+)*(?:>(.*)<\/\1>|\s+\/>)$/
xml_tag

6. Email


Общий вид — логин@поддомен.домен. Логин, как и поддомен — слова из букв, цифр, подчёркиваний, дефисов и точек. А домен (имеется в виду 1го уровня) — это от 2 до 6 букв и точек.

Паттерн: /^([a-z0-9_\.-]+)@([a-z0-9_\.-]+)\.([a-z\.]{2,6})$/
email
От себя: можно короче — /^([\w\._]+)@\1\.([a-z]{2,6}\.?)$/. Это ещё и чуть правильнее — точка в домене первого уровня может встретиться только один раз и только в конце.

7. URL


Первым делом — необязательный протокол (http:// или https://), затем последовательность букв, цифр, дефисов, подчёркиваний и точек (домены уровня > 1), потом домен нулевого уровня (от 2 до 6 букв и точек) и, наконец, файловая структура — набор слов из букв, цифр, дефисов, подчёркиваний и точек со слэшем в конце. Всё это может завершаться опять-таки слэшем.

Паттерн: /^(https?:\/\/)?([\da-z\.-]+)\.([a-z\.]{2,6})([\/\w \.-]*)*\/?$/
url
От себя: лучше так — /^(https?:\/\/)?([\w\.]+)\.([a-z]{2,6}\.?)(\/[\w\.]*)*\/?$/

8. IP адрес


4 группы цифр (от 1 до 3 цифр в каждой) разделены точками. Если группа состоит из 3 символов, то первый из них — 1 или 2; если 1, то остальные от 0 до 9, а если 2 — то второй от 0 до 5; если второй символ от 0 до 4, то третий — от 0 до 9, а если второй 5 — то третий от 0 до 5. Если же группа состоит из 2 символов, то первый — от 1 до 9, второй — от 0 до 9. В случае односимвольной группы этим символом может быть цифра от 1 до 9.

Паттерн: /^(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$/
ip
От себя: по-моему, так правильнее — /^(?:(?:25[0-5]|2[0-4]\d|[01]?\d\d?)\.){3}(?:25[0-5]|2[0-4]\d|[01]?\d\d?)$/.

Взято отсюда
Игорь @ZIJ
карма
137,6
рейтинг 0,0
Software Engineer
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (119)

  • 0
    Третье поправьте. Шестнадцатиричный цвет.
    • 0
      Пардон, четвёртое. Шестнадцитиричный цвет, в общем.
      • 0
        странно, работает вроде. Что не так?
        • 0
          Имелось ввиду наверное что надо нет «16ричное число», а «16ричный цвет» ну или как в Adobe'вских продуктах: WebRGB
        • 0
          ой, туплю. Поправил.
          • 0
            можно усложнить шаблон и добавить туда (через "|" — «или») все именованные цвета (red, green, blue и т.д.)… хотя это уж не так важно…
        • 0
          не так заголовок/название этого пункта.
          это не «шестнадцатиричное число» а RGB-цвет, в том виде, как он пишется в HTML.
          т.е. в виде шести или трех разрядного шестнадцатиричного числа.
          а само число может иметь сколько угодно разрядов — и один, и пятнадцать, и сто, но эта регулярка его ессно не пропустит.
    • 0
      всё таки «шестнадцатЕричный»
  • +35
    3. Пароль
    Паттерн: /^[a-z0-9_-]{6,18}$/

    ненавижу когда меня ограничивают в выборе символов пароля, так этот пример не очень полезный :)
    • 0
      Действительно, ограничивать пользователя в выборе пароля это перебор. В крайнем случае можно придумать что-нибудь ограничивающее минимальную сложность пароля, например:
      минимум одна маленькая латинская буква, минимум одна большая латинская буква, минимум одна цифра, минимум один знак (не цифро-буквенный) + длинна пароля минимум 8 символов…
      • 0
        Тогда получится максимум два юзера не-гика :)
    • +2
      и более того, эта регулярка не позволит ввести в пароль спецсимволы, которые, в общем-то, маст хэв.
      • 0
        об этом я и написал
      • 0
        В результате получается проверка на недопустимый пароль, ага!
    • 0
      Согласен с вами. Пользуюсь hotmail, использую 20-символьный пароль. Недавно решил воспользоваться Windows Live Messenger'ом, так он позволяет ввести только 16 символов! Как так?! Разные требования к паролю внутри одной и той же службы! Но что совсем меня удивило — несмотря на то, что мне не удается ввести пароль целиком, мессенджер успешно заходит под моей учетной записью.
      • 0
        это значит, что хранится только N первых символов пароля, остальные просто отбрасываются
        • +1
          так они там даже не хэш хранят???
          • 0
            Я думаю, эти ограничения только на клиентской стороне и на сервере длина пароля может быть больше 16 символов
            • 0
              наоборот, на клиентской стороне ты хоть поэму туда впиши, но сервер возьмёт только первые 16 символов
          • 0
            хеш, но не от всего пароля а от максимально-возможной (по требованиям ресурса) его части
    • 0
      А я больше ненавижу ограничение на 6 символов. Кто это придумал, почему именно 6?
      • +2
        Объём памяти среднестатистического пользователя :)
      • 0
        Ну как же, сейчас практически все пароли обычных пользователей состоят из 6 цифр. По две цифры на день, месяц и год рожения :)
      • 0
        скорее всего дело в том, что установлено, что среднестатистический человек может эффективно запоминать не более 7 объектов в совокупности одновременно. Видимо, этот предел-1. Дабы не подходить к порогу.
      • 0
        вообще никакие ограничения не нужны, даже пустой пароль — это пароль
    • +2
      тем более вот это /^[\w_]{6,18}$/
    • +1
      Единственный верный паттерн для пароля: /^.{6,}$/
      • +1
        /^.*$/
  • 0
    регулярные выражения взрывают мой мозг, но без них никуда :(
    • 0
      Купил на выходных книгу по регекспам, обьясняется все с самых основ до подробного разбора в конкретных ЯП. Очень помогает, в отличие от многочисленных «туториалов» в интернете (как и эта статья впрочем то же).
    • 0
      Почитайте „регулярные выражения“ в дискретке. Надежнее взорвет)
      • +2
        знаете, вокруг и так хватает того, что взрывает мозг, чтобы еще дополнительно что то искать :)
  • +12
    Если мне память не изменяет, то в e-mail адресе в имени ящика может быть символ "+", поэтому корректнее начало выражения записать: /^([a-z0-9_\.-\+]+)@
  • +24
    Спасибо, не нужно. Эти регекспы более вредны, чем полезны. Про ограничение пароля уже сказали. А я скажу про email и URL. local-part email'а (то, что до @) может содержать, например знак "+". И ещё много чего она может содержать. Вот правильный regexp: www.ex-parrot.com/~pdw/Mail-RFC822-Address.html

    URL regexp так вообще смешной. Он не матчит более половины всех URL'ов в интернете. В url-path части этот regexp не разрешает символы =, &, %.

    В общем читайте RFC, осмысливайте материал, который переводите. А то потом в интернете полурабочие сайты появляются на таких регекспах.
    • +2
      >более вредны, чем полезны
      но зато толково и понятно расписано какой символ что делает. для обучения покатит, а для реального использования но очень :/
      • +1
        *не очень
      • +2
        Почитайте лучше вики по регекспам — там коротко и по существу
    • +1
      хотел написать такой же комментарий, но лучше плюсану Ваш )
      полностью согласен, что валидировать урлы/емейлы/ а тем более хтмл/хмл (вложенные структуры по определению не «регулярны») регекспами — не правильно… если попытаться правильно — слишком сложные регекспы получатся, проще уж конечный автомат использовать, или грамматики…
  • +3
    Перевели бы картинки
    • 0
      Как раз этим занимаюсь)
  • +1
    Как показывает практика, лучше не использовать нижнее подчеркивание в имени пользователя, особенно в веб ресурсах.
  • +6
    > URL:… ([\/\w \.-]*)*

    И вот потом, начитавшись таких статей, люди пишут «хабрапарсеры», которые не понимают в качестве URL`ов ни скобки (круглые и квадратные), ни процент-кодирование, ни банальные "?", "&", ";" и "#", которые уж точно используются в подавляющем количестве URL`ов.
    • 0
      Цель статьи — не написать абсолютно универсальные регэкспы, а наглядно показать принципы работы и дать простейшие решения. Если человек понял, как они работают — он допишет и матчинг пары спецсимволов. Много полезной инфы — здесь
      • +20
        это наглая ложь. цель статьи дать быдлокодерам готовую регулярку под видом полезной обучалки
        • 0
          Ай маладЭц! Не в бровь, а в глаз, как говорится.
      • +1
        Чтобы понять регекспы надо книжки читать и умные статьи, а не готовые патерны. Чего вам и советую, т.к. извините, но у вас каждая вставка «от себя» не соответствует первоначальному патерну(только вашу вставку с ip-адресом не проверял, ибо в такой извращённый патерн даже лезть не хочется). Да и приведенные патерны далеко не идеальны и не так общеприменимы как выдаются.

        Почитайте на досуге Фридла.
        Ещё раз, извините, если обидел.
    • 0
      хабрапарсер хабрапарсер…
      code.google.com/p/jevix/
  • +1
    Вставлю свои три копейки за протокол.
    Без протокола валидный адрес будет //www.ya.ru — в вашу регулярку не пройдет.
    С одним слешом — адрес от корня текущего хоста, с двумя слешами впереди — указание на домен. Перед всем этим опциональный протокол,
    а после двух слешей может быть еще user:password@, что также весьма часто используется.
  • +3
    >> /^(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$/

    А как же метасимвол \d? чуть волосы дыбом не стали)

    >> От себя: более кратко — /^[\w_]{6,18}$/. Аналогично для юзернейма.

    \w — про поддержку юникода этим метасимволом забыли :) По крайней мере в некоторых диалектах

    >> /^([\w\._]+)@\1\.([a-z]{2,6}\.?)$/

    Домен первого уровня должен совпадать с именем ящика? Либо я спросони туго соображаю? :)

    ещё пару мелочей есть :)
    • –1
      спасибо, поправил в отсебятине. но основной паттерн оставил — чтобы была связь с картинкой :)
      • 0
        ещё с ip адресом было бы нагляднее и красивее еслиб привели что-то типа:
        $re = qr/25[0-5]|2[0-4]\d|[01]?\d\d?/;
        $message =~ /($re\.){3}$re/;
      • +1
        Не вижу поправленного, \1
  • 0
    объяснение регекспов это хорошо, хоть это уже и много где есть, чем дальше тем проще и понятней становится
  • 0
    регэксп вызывает в моём мозге просто взрыв, вродь всё просто, но когда начинаешь что то ковырять… как я наломал голову когда регэкспом выдирал данные из логов сервера, страшно вспомнить :) но надо
    • –1
      RegExp'сы лучше использовать как write-only, т.к. у каждого свой стиль и под свою специфику написаны.

      Очень хорошо понимаются на практике, но нужно на 100% представлять как они работают, что с помощью него нужно сделать и тогда он незаменимый помощник ;)
      • 0
        да я даже и не спорю, поковырявшись я уже давно понял что проще курить ман и пробовать самому, чем найти нечто подходящее в сети :)
      • +1
        вот откуда такие советы берутся? =\

        откройте perl best practices — там целый раздел посвящен регуляркам и доступно написано как аккуратно писать поддерживаемые регулярки
  • +3
    кстати во всех примерах букву будут подходить только в нижнем регистре.

    Для любого регистра нужно писать либо [A-Za-z] либо включить флаг i
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      спасибо, исправил
  • +2
    Часто бывают небольшие отклонения от этих простых случаев, например, когда логин должен начинаться с буквы латинского алфавита, не заканчиваться дефисом и не иметь двух дефисов подряд и т.п. Мне кажется, поэтапный разбор составления различных решений для каких-то более сложных примеров был бы интереснее.

    А очередной разбор типовых — ну, не знаю. Не айс. ;-)
  • +6
    Многие примеры не выдерживают никакой критики. По url, email и тп читать соответствующие RFC. Пароль вообще ограничивать никак не надо. А в имени пользователя еще может быть и пробел, к примеру. Обо всем этом уже написали.

    Добавлю, что \w — это [a-zA-Z_0-9]. Символ "-" сюда не входит.

    Ваше преобразование IP адреса явно неверное. Это сразу видно по \1. При более глубоком вглядывании видны и другие косяки.

    Ценность данного перевода стремится к нулю во всех отношениях. Это явно не лучший туториал для новичков. Тут явно нет информации для профи. Тут нет никакого опыта, который можно перенять. Зачем было это переводить, кроме как из-за красивых картинок?
    • 0
      убрал ошибочный регексп, спасибо
    • 0
      Добавлю, что \w — это [a-zA-Z_0-9]
      В большинстве случаев \w поддерживает юникод и там не только латинские буквы!
      • 0
        В первой строке цитировал. Извините.
  • 0
    ужасное нагромождение цветов, текстов, шрифтов и полосочек в картинках
    ребус какой-то получился…
  • +2
    А еще ко всей вышеперечисленной критике добавлю, что использовать в разборе урлов символ "/" в качестве ограничителя — глупость, ведущая к чрезвычайному загромождению регэкспа. Почему-то очень многие авторы на всю жизнь запоминают, что "/.../" — это регэксп, и никто не задумывается об использовании в качестве ограничителя другого символа.
    Вместо вашего
    /^(https?:\/\/)?([\w\.]+)\.([a-z]{2,6}\.?)(\/[\w\.]*)*\/?$/
    получилось бы более-менее красивое (сам регэксп не рассматриваю)
    #^(https?://)?([\w\.]+)\.([a-z]{2,6}\.?)(/[\w\.]*)*/?$#
    • 0
      Я всегда думал что поддержка различных ограничителей производится на уровне конкретного языка(к примеру Perl). Разве она осуществляется на уровне патернов???
      • 0
        Просто тут привязки к языкам нету.
      • 0
        Там, где эти ограничители есть — да (а тут они везде есть). Как правило — это перловские регэкспы, которые вы можете наблюдать в перле, пхп и других местах. В других регэкспах ограничителей нет вообще, например, в апачевском mod_rewrite или у grep. У vim ограничители не используются при поиске, но при замене вы набираете :%s#i#q#g, и ограничитель тоже можно менять.
        В общем, везде, где я встречал ограничители, их можно менять, тем самым убирая ненужное экранирование.
  • –8
    в начале ^ и в конце $ совершенно не нужен
    • 0
      ого! а минусаторы могут пояснить за что минусуют?
      • 0
        за глупость
    • 0
      я вот пишу так:
      string RE;
      RE = «productTitle\»>.+?\"(?.+?)\">(?.+?)by (?[^
    • 0
      наверное нужно для того, чтобы не было валидации по подстроке?
    • 0
      не минусил, я предположил, из-за чего могли минусы вбабахать
    • 0
      Тогда будут проходить строки типа
      БЛАБЛАБЛАvalid@mail.comБЛАБЛАБЛА
      итд
  • 0
    Вот если бы еще шпаргалку сделать! :)))
  • +1
    3. Пароль. Зачем ограничили набор символов и максимальную длину не понятно.
    5. XML тэг. Регулярка не сработает на теге, в значении аттрибута которого есть символ ">" в кавычках, например: <input value=">>">. Понятно, что символы ">" должны преобразовываться в html-сущности, но тем не менее браузеры это нормально воспринимают, значит такая ситауция возможна.
    6. E-mail. Надуманное ограничение доменом второго уровня. (На RFC ссылку дали выше)
    7. URL. Свели все урлы до протоколов http/https. За что? Неужели других протоколов не существует (ftp://, svn://)? По вашим правилам в URL обязательно должна быть точка — выдуманное правило, а как быть с localhost или другими url указывающими на домены первого уровня (например в локальной сети такие могут быть). Как быть с url в виде ip-адреса (я уж не говорю про ipv6)?
  • 0
    xml тэг:
    про тег h1 автор видимо не слышал.
    и про .*?
    • –1
      вот довольно хорошо, но не идеально работающая регулярка для xml/html:

      /<(.+?)(?:\s+(.*?)>(.*?)</\1|>(.*?)</\1|\s*/)>/s
      

      1. Ловит любые теги имеющие закрывающую часть или без нее.
      2. Можно модифицировать первую выборку (.+?) для идеализации например так: ([\d\w_]+?)
      3. Внутри словленного тега могут быть другие теги
      4. Честно отработает для тегов, которые внутри себя не содержат одноименные закрываемые теги, т.е. если будет такое:

      <div>
         <div>abc</div>
      </div>
      

      то регулярка словит первый же закрывающий div
      • –1
        вспомнил еще про один тип тэгов, случайно мной забытый и вот модификация:
        /<(.+?)(?:\s+(.*?)>(.*?)</\1|\s*>(.*?)</\1|\s*/|\s+(.*?)/)>/s
        

        для тех кому интересно как это работает и почему:

        1) — получаем имя тега
        <(.+?)

        2) — группа, которая не будет словлена, т.е. в результирующем массиве ее не будет
        (?:\s+(.*?)>(.*?)</\1|>(.*?)</\1|\s*/|\s+(.*?)/)

        2.а) — для тегов имеющих аттрибуты, тело и закрывающую часть
        \s+(.*?)>(.*?)</\1

        2.a.I) — получение аттрибутов
        \s+(.*?)>

        2.a.II) — получение тела
        (.*?)

        2.a.III) — закрытие тэга, одноименно для того, который словили в 1)
        </\1

        2.б) — для тегов на имеющих аттрибуты, но имеющих тело и закрывающую часть
        >(.*?)</\1

        2.б.I) — закрытие открывающего тега (у него не аттрибутов)
        \s*>

        2.б.II) — смотреть 2.a.II)
        2.б.III) — смотреть 2.a.III)
        2.в) — для тегов, не имеющих закрывающей части и аттрибутов
        \s*/

        2.г) — для тегов, не имеющих закрывающей части, но имеющих аттрибуты
        \s+(.*?)/

        3) — закрытие тега
        >
      • 0
        для тех кто еще не знает:
        В моей регулярке постоянно используется особая запись:
        .*?

        Вон тот вопросик в конце делает очень полезную операцию: лишает квантификаторы "+", "*" и {число,} жадности. Т.е. в обчном случае для получения внутренностей тега регулярка "<(.*)>" съест всё, что ей дадут от первого символа "<" аж до последнего ">":
        abc<div class="x"><any_tag/></div><any_tag/>abcd
        на выходе даст:
        div class="x"><any_tag/></div><any_tag/
        А нам ведь нужно только
        div class="x"

        Вот для получения того, что нам нужно и используется знак вопроса после квантификаторов "+", "*" и {число,}
        регулярки
        <(.*?)>
        <(.+?)>
        <(.{2,}?)>
        добросовестно выдадут
        div class="x"
        • НЛО прилетело и опубликовало эту надпись здесь
          • +1
            эхх… нельзя делать добро — оно не остается безнаказанным =)

            кстати, в регулярке автора вот такой вот тег:
            <img src="sd"/>
            словлен не будет. там предполагается наличие пробела перед "/", т.е. нужно не \s+, а \s*
  • 0
    А где же квантификаторы? Если цель статьи хотя бы кого-то научить — надо было бы добавить немного отсебятины.
  • +1
    • +2
      Кстати, это единственный правильный регексп для e-mail, из представленных здесь.
      Просто бесит, когда ставишь какой нибудь продукт, а в нём невозможно ввести локальный адрес, что-нибудь типа: vasia@work.
  • 0
    Надо собратся и выучить эти выражения.
  • 0
    Еще неплохо оригинальное авторство упоминать: net.tutsplus.com/tutorials/other/8-regular-expressions-you-should-know/
    • 0
      Оно с момента публикации неплохо упомянуто — внизу топика «Взято отсюда»
  • 0
    Хабр катится в… ну вы понели.
  • –3
    Может я быдлокодер но автору спасибо!
  • +2
    Часть ЧПУ проще и надежнее распознавать так:

    #^[^/]+$#

    Статья пафосная и ни о чем.
    Читайте Фридла.
    • 0
      #^[^/]+$#

      Тогда уже
      #[^/]+$#

      Иначе в любой ссылке не будет совпадения из-за имеющихся там слэшей.
      • 0
        Точно
  • +2
    Спасибо конечно, но вряд ли это кому-то действительно нужно. Тем кому нужны разные жизненные примеры — на www.regexlib.com их тонны.
  • –1
    Мой вариант процессинка простых ссылок а ля http… и ссылок на картинки в картинки. Работает если текст начинается с ссылки, корректно обрабатывает большинство ссылок на всех моих проектах (корректнее хабра, к примеру).
    Оборачивает линки в ноиндекс/нофоллоу (снижая привлекательность прямых ссылок для сеорастов).
    Язык — PHP.

    $processedtxt = preg_replace_callback(
    "#[^(\"')]?[hHtTpP]{4}[:]\/\/[a-zA-z.\/0-9-+?=&%\#;]*#",
    create_function('$matches',
    '$pos = strpos(strtolower($matches[0]),«http»);$first=\'\';'.
    'if ($pos == 1) {$first=substr($matches[0],0,1); $matches[0] = substr($matches[0],1);}'.
    '$ext= substr(strtolower($matches[0]),strlen($matches[0])-3);'.
    'if ($ext == «gif» or $ext == «jpg» or $ext == «png») return "";'.
    'else return "$first$matches[0]";'),$text);
    return $processedtxt;
    • 0
      /i вам в помощь :)
      • –1
        в смысле?
        • НЛО прилетело и опубликовало эту надпись здесь
          • –2
            А, вы про модификаторы… Нет уж, спасибо.
            Во первых через них лёгким движением руки вставляют экспойты: www.bugs.php.net/bug.php?id=35960 (и не только в пхп)
            Во вторых в их обработке в пхп встречаются баги. Пол дня колупался не мог понять почему регулярка не работала. Весь инет перерыл. Выяснилось — баг пхп с модификатором.
            Вобщем обжёгся один раз, и с тех пор как то по босяцки предпочитаю.
            • –1
              Сори, правильная ссылка будет: bugs.php.net/bug.php?id=35960
              Кстати использовал баг в парсере урлов хабра, позволяющий преобразовывать ссылки с www заминусованным товарищам типа меня, но не обратил внимания что это субдомен.
            • +1
              Потратил пол-минуты на хождение по ссылке. Повеселили, чесслово.
              Вы, юноша, вместо того чтобы полную ерунду писать — лучше потратьте время на то, чтобы прочитать ответ умных людей, да осознать его.
              Резюме ответа саппорта — модификатор '/e' позволяет выполнять код в шаблоне подстановки(замены), как это и указано в документации.
              Приведенный Вами код выполняет ровно то, что Вы написали, а не то, что Вы подразумевали при его написании. Именно в этом корень Ваших «багов».

              Что же до использования регулярных выражений и модификаторов — все они абсолютно безопасны и не содержат никаких «багов» и «дыр». Во всяком случае до тех пор, пока разработчик сам их туда не внедрит, мало ли какие у него идеи.
              В бесконечной рекурсии тоже иногда бывает смысл, знаете ли.
  • 0
    По-моему эти регекспы ужасны. Как минимум не оптимальны, как максимум бесполезны.

    в этом правиле дефис в квадратных скобках лучше перенсти в начало
    /^[a-z0-9-]+$/
  • +1
    Вот я не понимаю, зачем пытаться учить на плохих примерах?

    Не надо так:
    4. Шестнадцатиричный цвет
    Паттерн: /^#?([a-f0-9]{6}|[a-f0-9]{3})$/


    Надо вот так:
    Паттерн: /^#?(?:[0-9a-f]{3}){1,2}$/

    Если Вам нужно найти 3 или 3+3 последовательностей — так и скажите.

    PS. Вот чего я никак не пойму — это почему в символьном классе последовательность задается «тире», а в полном квантификаторе — через запятую? Инопланетная логика.
    Кстати, использование в квантификаторе логики «последовательность» или «список» позволила бы делать подобные вещи более красивыми. Жаль, что синтаксис уже точно не изменится.
    Если помечтать, то было бы [a]{1-3} — от 1 до 3-х 'a' или [a]{1,3} — точно 1 или точно 3 'a'. Красота!
  • 0
    Как насчет такого URL:

    ftp://admin:megapass@ftp.someserver:5555/~blabla/megafile.rar
  • 0
    безсмысленная статья. человек который их раньше не понимал и не будет понимать, а тот который толком прочитал теорию не найдет ничего нового(подстановки из карманов \1 нету, поз. или негатив. поиск вперед назад без кармана — нету

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.