Комментарии 119
Третье поправьте. Шестнадцатиричный цвет.
Пардон, четвёртое. Шестнадцитиричный цвет, в общем.
странно, работает вроде. Что не так?
НЛО прилетело и опубликовало эту надпись здесь
ой, туплю. Поправил.
не так заголовок/название этого пункта.
это не «шестнадцатиричное число» а RGB-цвет, в том виде, как он пишется в HTML.
т.е. в виде шести или трех разрядного шестнадцатиричного числа.
а само число может иметь сколько угодно разрядов — и один, и пятнадцать, и сто, но эта регулярка его ессно не пропустит.
это не «шестнадцатиричное число» а RGB-цвет, в том виде, как он пишется в HTML.
т.е. в виде шести или трех разрядного шестнадцатиричного числа.
а само число может иметь сколько угодно разрядов — и один, и пятнадцать, и сто, но эта регулярка его ессно не пропустит.
всё таки «шестнадцатЕричный»
3. Пароль
Паттерн: /^[a-z0-9_-]{6,18}$/
ненавижу когда меня ограничивают в выборе символов пароля, так этот пример не очень полезный :)
НЛО прилетело и опубликовало эту надпись здесь
и более того, эта регулярка не позволит ввести в пароль спецсимволы, которые, в общем-то, маст хэв.
Согласен с вами. Пользуюсь hotmail, использую 20-символьный пароль. Недавно решил воспользоваться Windows Live Messenger'ом, так он позволяет ввести только 16 символов! Как так?! Разные требования к паролю внутри одной и той же службы! Но что совсем меня удивило — несмотря на то, что мне не удается ввести пароль целиком, мессенджер успешно заходит под моей учетной записью.
А я больше ненавижу ограничение на 6 символов. Кто это придумал, почему именно 6?
Объём памяти среднестатистического пользователя :)
Ну как же, сейчас практически все пароли обычных пользователей состоят из 6 цифр. По две цифры на день, месяц и год рожения :)
скорее всего дело в том, что установлено, что среднестатистический человек может эффективно запоминать не более 7 объектов в совокупности одновременно. Видимо, этот предел-1. Дабы не подходить к порогу.
вообще никакие ограничения не нужны, даже пустой пароль — это пароль
тем более вот это /^[\w_]{6,18}$/
Единственный верный паттерн для пароля: /^.{6,}$/
регулярные выражения взрывают мой мозг, но без них никуда :(
Купил на выходных книгу по регекспам, обьясняется все с самых основ до подробного разбора в конкретных ЯП. Очень помогает, в отличие от многочисленных «туториалов» в интернете (как и эта статья впрочем то же).
Какой автор и название книги?
Регулярные выражения, 3-е издание
www.books.ru/shop/books/592346
www.books.ru/shop/books/592346
Почитайте „регулярные выражения“ в дискретке. Надежнее взорвет)
Если мне память не изменяет, то в e-mail адресе в имени ящика может быть символ "+", поэтому корректнее начало выражения записать: /^([a-z0-9_\.-\+]+)@
Какие сервисы позволяют такое делать? Еще ниразу не видел
НЛО прилетело и опубликовало эту надпись здесь
gmail такое может. он игнорирует всё после плюсика, для него
user+foobar@gmail.com == user@gmail.com
rukeba.com/blog/2008/03/13/imena-pochtovyh-yashikov-v-gmail/
user+foobar@gmail.com == user@gmail.com
rukeba.com/blog/2008/03/13/imena-pochtovyh-yashikov-v-gmail/
прийдется соблюдать стандарты ;)
www.ex-parrot.com/pdw/Mail-RFC822-Address.html
www.ex-parrot.com/pdw/Mail-RFC822-Address.html
Спасибо, не нужно. Эти регекспы более вредны, чем полезны. Про ограничение пароля уже сказали. А я скажу про email и URL. local-part email'а (то, что до @) может содержать, например знак "+". И ещё много чего она может содержать. Вот правильный regexp: www.ex-parrot.com/~pdw/Mail-RFC822-Address.html
URL regexp так вообще смешной. Он не матчит более половины всех URL'ов в интернете. В url-path части этот regexp не разрешает символы =, &, %.
В общем читайте RFC, осмысливайте материал, который переводите. А то потом в интернете полурабочие сайты появляются на таких регекспах.
URL regexp так вообще смешной. Он не матчит более половины всех URL'ов в интернете. В url-path части этот regexp не разрешает символы =, &, %.
В общем читайте RFC, осмысливайте материал, который переводите. А то потом в интернете полурабочие сайты появляются на таких регекспах.
>более вредны, чем полезны
но зато толково и понятно расписано какой символ что делает. для обучения покатит, а для реального использования но очень :/
но зато толково и понятно расписано какой символ что делает. для обучения покатит, а для реального использования но очень :/
*не очень
Почитайте лучше вики по регекспам — там коротко и по существу
хотел написать такой же комментарий, но лучше плюсану Ваш )
полностью согласен, что валидировать урлы/емейлы/ а тем более хтмл/хмл (вложенные структуры по определению не «регулярны») регекспами — не правильно… если попытаться правильно — слишком сложные регекспы получатся, проще уж конечный автомат использовать, или грамматики…
полностью согласен, что валидировать урлы/емейлы/ а тем более хтмл/хмл (вложенные структуры по определению не «регулярны») регекспами — не правильно… если попытаться правильно — слишком сложные регекспы получатся, проще уж конечный автомат использовать, или грамматики…
Перевели бы картинки
Как показывает практика, лучше не использовать нижнее подчеркивание в имени пользователя, особенно в веб ресурсах.
> URL:… ([\/\w \.-]*)*
И вот потом, начитавшись таких статей, люди пишут «хабрапарсеры», которые не понимают в качестве URL`ов ни скобки (круглые и квадратные), ни процент-кодирование, ни банальные "?", "&", ";" и "#", которые уж точно используются в подавляющем количестве URL`ов.
И вот потом, начитавшись таких статей, люди пишут «хабрапарсеры», которые не понимают в качестве URL`ов ни скобки (круглые и квадратные), ни процент-кодирование, ни банальные "?", "&", ";" и "#", которые уж точно используются в подавляющем количестве URL`ов.
Цель статьи — не написать абсолютно универсальные регэкспы, а наглядно показать принципы работы и дать простейшие решения. Если человек понял, как они работают — он допишет и матчинг пары спецсимволов. Много полезной инфы — здесь
это наглая ложь. цель статьи дать быдлокодерам готовую регулярку под видом полезной обучалки
Чтобы понять регекспы надо книжки читать и умные статьи, а не готовые патерны. Чего вам и советую, т.к. извините, но у вас каждая вставка «от себя» не соответствует первоначальному патерну(только вашу вставку с ip-адресом не проверял, ибо в такой извращённый патерн даже лезть не хочется). Да и приведенные патерны далеко не идеальны и не так общеприменимы как выдаются.
Почитайте на досуге Фридла.
Ещё раз, извините, если обидел.
Почитайте на досуге Фридла.
Ещё раз, извините, если обидел.
хабрапарсер хабрапарсер…
code.google.com/p/jevix/
code.google.com/p/jevix/
Вставлю свои три копейки за протокол.
Без протокола валидный адрес будет //www.ya.ru — в вашу регулярку не пройдет.
С одним слешом — адрес от корня текущего хоста, с двумя слешами впереди — указание на домен. Перед всем этим опциональный протокол,
а после двух слешей может быть еще user:password@, что также весьма часто используется.
Без протокола валидный адрес будет //www.ya.ru — в вашу регулярку не пройдет.
С одним слешом — адрес от корня текущего хоста, с двумя слешами впереди — указание на домен. Перед всем этим опциональный протокол,
а после двух слешей может быть еще user:password@, что также весьма часто используется.
>> /^(?:(?: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}\.?)$/
Домен первого уровня должен совпадать с именем ящика? Либо я спросони туго соображаю? :)
ещё пару мелочей есть :)
А как же метасимвол \d? чуть волосы дыбом не стали)
>> От себя: более кратко — /^[\w_]{6,18}$/. Аналогично для юзернейма.
\w — про поддержку юникода этим метасимволом забыли :) По крайней мере в некоторых диалектах
>> /^([\w\._]+)@\1\.([a-z]{2,6}\.?)$/
Домен первого уровня должен совпадать с именем ящика? Либо я спросони туго соображаю? :)
ещё пару мелочей есть :)
объяснение регекспов это хорошо, хоть это уже и много где есть, чем дальше тем проще и понятней становится
регэксп вызывает в моём мозге просто взрыв, вродь всё просто, но когда начинаешь что то ковырять… как я наломал голову когда регэкспом выдирал данные из логов сервера, страшно вспомнить :) но надо
RegExp'сы лучше использовать как write-only, т.к. у каждого свой стиль и под свою специфику написаны.
Очень хорошо понимаются на практике, но нужно на 100% представлять как они работают, что с помощью него нужно сделать и тогда он незаменимый помощник ;)
Очень хорошо понимаются на практике, но нужно на 100% представлять как они работают, что с помощью него нужно сделать и тогда он незаменимый помощник ;)
да я даже и не спорю, поковырявшись я уже давно понял что проще курить ман и пробовать самому, чем найти нечто подходящее в сети :)
вот откуда такие советы берутся? =\
откройте perl best practices — там целый раздел посвящен регуляркам и доступно написано как аккуратно писать поддерживаемые регулярки
откройте perl best practices — там целый раздел посвящен регуляркам и доступно написано как аккуратно писать поддерживаемые регулярки
кстати во всех примерах букву будут подходить только в нижнем регистре.
Для любого регистра нужно писать либо [A-Za-z] либо включить флаг i
Для любого регистра нужно писать либо [A-Za-z] либо включить флаг i
НЛО прилетело и опубликовало эту надпись здесь
Часто бывают небольшие отклонения от этих простых случаев, например, когда логин должен начинаться с буквы латинского алфавита, не заканчиваться дефисом и не иметь двух дефисов подряд и т.п. Мне кажется, поэтапный разбор составления различных решений для каких-то более сложных примеров был бы интереснее.
А очередной разбор типовых — ну, не знаю. Не айс. ;-)
А очередной разбор типовых — ну, не знаю. Не айс. ;-)
Многие примеры не выдерживают никакой критики. По url, email и тп читать соответствующие RFC. Пароль вообще ограничивать никак не надо. А в имени пользователя еще может быть и пробел, к примеру. Обо всем этом уже написали.
Добавлю, что \w — это [a-zA-Z_0-9]. Символ "-" сюда не входит.
Ваше преобразование IP адреса явно неверное. Это сразу видно по \1. При более глубоком вглядывании видны и другие косяки.
Ценность данного перевода стремится к нулю во всех отношениях. Это явно не лучший туториал для новичков. Тут явно нет информации для профи. Тут нет никакого опыта, который можно перенять. Зачем было это переводить, кроме как из-за красивых картинок?
Добавлю, что \w — это [a-zA-Z_0-9]. Символ "-" сюда не входит.
Ваше преобразование IP адреса явно неверное. Это сразу видно по \1. При более глубоком вглядывании видны и другие косяки.
Ценность данного перевода стремится к нулю во всех отношениях. Это явно не лучший туториал для новичков. Тут явно нет информации для профи. Тут нет никакого опыта, который можно перенять. Зачем было это переводить, кроме как из-за красивых картинок?
ужасное нагромождение цветов, текстов, шрифтов и полосочек в картинках
ребус какой-то получился…
ребус какой-то получился…
А еще ко всей вышеперечисленной критике добавлю, что использовать в разборе урлов символ "/" в качестве ограничителя — глупость, ведущая к чрезвычайному загромождению регэкспа. Почему-то очень многие авторы на всю жизнь запоминают, что "/.../" — это регэксп, и никто не задумывается об использовании в качестве ограничителя другого символа.
Вместо вашего
/^(https?:\/\/)?([\w\.]+)\.([a-z]{2,6}\.?)(\/[\w\.]*)*\/?$/
получилось бы более-менее красивое (сам регэксп не рассматриваю)
#^(https?://)?([\w\.]+)\.([a-z]{2,6}\.?)(/[\w\.]*)*/?$#
Вместо вашего
/^(https?:\/\/)?([\w\.]+)\.([a-z]{2,6}\.?)(\/[\w\.]*)*\/?$/
получилось бы более-менее красивое (сам регэксп не рассматриваю)
#^(https?://)?([\w\.]+)\.([a-z]{2,6}\.?)(/[\w\.]*)*/?$#
Я всегда думал что поддержка различных ограничителей производится на уровне конкретного языка(к примеру Perl). Разве она осуществляется на уровне патернов???
Просто тут привязки к языкам нету.
Там, где эти ограничители есть — да (а тут они везде есть). Как правило — это перловские регэкспы, которые вы можете наблюдать в перле, пхп и других местах. В других регэкспах ограничителей нет вообще, например, в апачевском mod_rewrite или у grep. У vim ограничители не используются при поиске, но при замене вы набираете :%s#i#q#g, и ограничитель тоже можно менять.
В общем, везде, где я встречал ограничители, их можно менять, тем самым убирая ненужное экранирование.
В общем, везде, где я встречал ограничители, их можно менять, тем самым убирая ненужное экранирование.
в начале ^ и в конце $ совершенно не нужен
ого! а минусаторы могут пояснить за что минусуют?
я вот пишу так:
string RE;
RE = «productTitle\»>.+?\"(?.+?)\">(?.+?)by (?[^
string RE;
RE = «productTitle\»>.+?\"(?.+?)\">(?.+?)by (?[^
наверное нужно для того, чтобы не было валидации по подстроке?
не минусил, я предположил, из-за чего могли минусы вбабахать
Тогда будут проходить строки типа
БЛАБЛАБЛАvalid@mail.comБЛАБЛАБЛА
итд
БЛАБЛАБЛАvalid@mail.comБЛАБЛАБЛА
итд
Вот если бы еще шпаргалку сделать! :)))
3. Пароль. Зачем ограничили набор символов и максимальную длину не понятно.
5. XML тэг. Регулярка не сработает на теге, в значении аттрибута которого есть символ ">" в кавычках, например: <input value=">>">. Понятно, что символы ">" должны преобразовываться в html-сущности, но тем не менее браузеры это нормально воспринимают, значит такая ситауция возможна.
6. E-mail. Надуманное ограничение доменом второго уровня. (На RFC ссылку дали выше)
7. URL. Свели все урлы до протоколов http/https. За что? Неужели других протоколов не существует (ftp://, svn://)? По вашим правилам в URL обязательно должна быть точка — выдуманное правило, а как быть с localhost или другими url указывающими на домены первого уровня (например в локальной сети такие могут быть). Как быть с url в виде ip-адреса (я уж не говорю про ipv6)?
5. XML тэг. Регулярка не сработает на теге, в значении аттрибута которого есть символ ">" в кавычках, например: <input value=">>">. Понятно, что символы ">" должны преобразовываться в html-сущности, но тем не менее браузеры это нормально воспринимают, значит такая ситауция возможна.
6. E-mail. Надуманное ограничение доменом второго уровня. (На RFC ссылку дали выше)
7. URL. Свели все урлы до протоколов http/https. За что? Неужели других протоколов не существует (ftp://, svn://)? По вашим правилам в URL обязательно должна быть точка — выдуманное правило, а как быть с localhost или другими url указывающими на домены первого уровня (например в локальной сети такие могут быть). Как быть с url в виде ip-адреса (я уж не говорю про ipv6)?
xml тэг:
про тег h1 автор видимо не слышал.
и про .*?
про тег h1 автор видимо не слышал.
и про .*?
вот довольно хорошо, но не идеально работающая регулярка для xml/html:
1. Ловит любые теги имеющие закрывающую часть или без нее.
2. Можно модифицировать первую выборку (.+?) для идеализации например так: ([\d\w_]+?)
3. Внутри словленного тега могут быть другие теги
4. Честно отработает для тегов, которые внутри себя не содержат одноименные закрываемые теги, т.е. если будет такое:
то регулярка словит первый же закрывающий div
/<(.+?)(?:\s+(.*?)>(.*?)</\1|>(.*?)</\1|\s*/)>/s
1. Ловит любые теги имеющие закрывающую часть или без нее.
2. Можно модифицировать первую выборку (.+?) для идеализации например так: ([\d\w_]+?)
3. Внутри словленного тега могут быть другие теги
4. Честно отработает для тегов, которые внутри себя не содержат одноименные закрываемые теги, т.е. если будет такое:
<div> <div>abc</div> </div>
то регулярка словит первый же закрывающий div
вспомнил еще про один тип тэгов, случайно мной забытый и вот модификация:
для тех кому интересно как это работает и почему:
1) — получаем имя тега
2) — группа, которая не будет словлена, т.е. в результирующем массиве ее не будет
2.а) — для тегов имеющих аттрибуты, тело и закрывающую часть
2.a.I) — получение аттрибутов
2.a.II) — получение тела
2.a.III) — закрытие тэга, одноименно для того, который словили в 1)
2.б) — для тегов на имеющих аттрибуты, но имеющих тело и закрывающую часть
2.б.I) — закрытие открывающего тега (у него не аттрибутов)
2.б.II) — смотреть 2.a.II)
2.б.III) — смотреть 2.a.III)
2.в) — для тегов, не имеющих закрывающей части и аттрибутов
2.г) — для тегов, не имеющих закрывающей части, но имеющих аттрибуты
3) — закрытие тега
/<(.+?)(?:\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) — закрытие тега
>
для тех кто еще не знает:
В моей регулярке постоянно используется особая запись:
Вон тот вопросик в конце делает очень полезную операцию: лишает квантификаторы "+", "*" и {число,} жадности. Т.е. в обчном случае для получения внутренностей тега регулярка "<(.*)>" съест всё, что ей дадут от первого символа "<" аж до последнего ">":
Вот для получения того, что нам нужно и используется знак вопроса после квантификаторов "+", "*" и {число,}
регулярки
В моей регулярке постоянно используется особая запись:
.*?
Вон тот вопросик в конце делает очень полезную операцию: лишает квантификаторы "+", "*" и {число,} жадности. Т.е. в обчном случае для получения внутренностей тега регулярка "<(.*)>" съест всё, что ей дадут от первого символа "<" аж до последнего ">":
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"
А где же квантификаторы? Если цель статьи хотя бы кого-то научить — надо было бы добавить немного отсебятины.
Надо собратся и выучить эти выражения.
Еще неплохо оригинальное авторство упоминать: net.tutsplus.com/tutorials/other/8-regular-expressions-you-should-know/
Хабр катится в… ну вы понели.
Может я быдлокодер но автору спасибо!
Часть ЧПУ проще и надежнее распознавать так:
#^[^/]+$#
Статья пафосная и ни о чем.
Читайте Фридла.
#^[^/]+$#
Статья пафосная и ни о чем.
Читайте Фридла.
Спасибо конечно, но вряд ли это кому-то действительно нужно. Тем кому нужны разные жизненные примеры — на www.regexlib.com их тонны.
Мой вариант процессинка простых ссылок а ля 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;
Оборачивает линки в ноиндекс/нофоллоу (снижая привлекательность прямых ссылок для сеорастов).
Язык — 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;
/i вам в помощь :)
в смысле?
НЛО прилетело и опубликовало эту надпись здесь
А, вы про модификаторы… Нет уж, спасибо.
Во первых через них лёгким движением руки вставляют экспойты: www.bugs.php.net/bug.php?id=35960 (и не только в пхп)
Во вторых в их обработке в пхп встречаются баги. Пол дня колупался не мог понять почему регулярка не работала. Весь инет перерыл. Выяснилось — баг пхп с модификатором.
Вобщем обжёгся один раз, и с тех пор как то по босяцки предпочитаю.
Во первых через них лёгким движением руки вставляют экспойты: www.bugs.php.net/bug.php?id=35960 (и не только в пхп)
Во вторых в их обработке в пхп встречаются баги. Пол дня колупался не мог понять почему регулярка не работала. Весь инет перерыл. Выяснилось — баг пхп с модификатором.
Вобщем обжёгся один раз, и с тех пор как то по босяцки предпочитаю.
Сори, правильная ссылка будет: bugs.php.net/bug.php?id=35960
Кстати использовал баг в парсере урлов хабра, позволяющий преобразовывать ссылки с www заминусованным товарищам типа меня, но не обратил внимания что это субдомен.
Кстати использовал баг в парсере урлов хабра, позволяющий преобразовывать ссылки с www заминусованным товарищам типа меня, но не обратил внимания что это субдомен.
Потратил пол-минуты на хождение по ссылке. Повеселили, чесслово.
Вы, юноша, вместо того чтобы полную ерунду писать — лучше потратьте время на то, чтобы прочитать ответ умных людей, да осознать его.
Резюме ответа саппорта — модификатор '/e' позволяет выполнять код в шаблоне подстановки(замены), как это и указано в документации.
Приведенный Вами код выполняет ровно то, что Вы написали, а не то, что Вы подразумевали при его написании. Именно в этом корень Ваших «багов».
Что же до использования регулярных выражений и модификаторов — все они абсолютно безопасны и не содержат никаких «багов» и «дыр». Во всяком случае до тех пор, пока разработчик сам их туда не внедрит, мало ли какие у него идеи.
В бесконечной рекурсии тоже иногда бывает смысл, знаете ли.
Вы, юноша, вместо того чтобы полную ерунду писать — лучше потратьте время на то, чтобы прочитать ответ умных людей, да осознать его.
Резюме ответа саппорта — модификатор '/e' позволяет выполнять код в шаблоне подстановки(замены), как это и указано в документации.
Приведенный Вами код выполняет ровно то, что Вы написали, а не то, что Вы подразумевали при его написании. Именно в этом корень Ваших «багов».
Что же до использования регулярных выражений и модификаторов — все они абсолютно безопасны и не содержат никаких «багов» и «дыр». Во всяком случае до тех пор, пока разработчик сам их туда не внедрит, мало ли какие у него идеи.
В бесконечной рекурсии тоже иногда бывает смысл, знаете ли.
По-моему эти регекспы ужасны. Как минимум не оптимальны, как максимум бесполезны.
в этом правиле дефис в квадратных скобках лучше перенсти в начало
/^[a-z0-9-]+$/
в этом правиле дефис в квадратных скобках лучше перенсти в начало
/^[a-z0-9-]+$/
Вот я не понимаю, зачем пытаться учить на плохих примерах?
Не надо так:
Надо вот так:
Паттерн: /^#?(?:[0-9a-f]{3}){1,2}$/
Если Вам нужно найти 3 или 3+3 последовательностей — так и скажите.
PS. Вот чего я никак не пойму — это почему в символьном классе последовательность задается «тире», а в полном квантификаторе — через запятую? Инопланетная логика.
Кстати, использование в квантификаторе логики «последовательность» или «список» позволила бы делать подобные вещи более красивыми. Жаль, что синтаксис уже точно не изменится.
Если помечтать, то было бы [a]{1-3} — от 1 до 3-х 'a' или [a]{1,3} — точно 1 или точно 3 'a'. Красота!
Не надо так:
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'. Красота!
Как насчет такого URL:
ftp://admin:megapass@ftp.someserver:5555/~blabla/megafile.rar
ftp://admin:megapass@ftp.someserver:5555/~blabla/megafile.rar
безсмысленная статья. человек который их раньше не понимал и не будет понимать, а тот который толком прочитал теорию не найдет ничего нового(подстановки из карманов \1 нету, поз. или негатив. поиск вперед назад без кармана — нету
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
8 полезных регэкспов с наглядным разбором