Комментарии 32
Удалено
Сча будет не сарказм, я написал более 10к регулярное и где-то образовалось верблюжие море и не разу не обломался, посмотреть их можете в профиле на гитхабе.
Что по статье: для меня описать регулярное выражение через конструктор это смерти подобное, при большом количестве это будет выглядеть еще хуже чем нативно
Alcatel|Alc(?!or )[a-z0-9]+|One[ _]?Touch|idol3|TIMXL|(?:(?:4003[AJ]|4009[ADEFIKMSX]|4013[DEJKMX]|4014[ADEKMX]|4015[ADNTX]|4016[ADX]|4017[ADEFSX]|4018[ADEFMX]|4024[EDX]|4027[ADNX]|4028[AEJS]|4032[ADEX]|4034[ADEFGXTL]|4035[ADXY]|4045[ADEX]|4047[ADFGNX]|4049[DEGMX]|4060[SW]|A466BG|A621BL|4114E|4087U|5001[ADJTU]|5002[ADFH]|5003[ADGU]|5006D|5007[AU]|5008[ADUYT]|5009[AD]|5010[DEGSUX]|5011A|5012[DFG]|5015[ADEX]|5016[AXJ]|5017[ABDEOX]|5019D|5022[EDX]|5023[EF]|5024[ADJF]|5025[DEG]|5026[ADJ]|5027B|5028[AYD]|5029[EYD]|5030[DE]|5032W|5033[AEFXDJGMOTXYQS]|5034D|5036D|5038[ADEX]|5039[DY]|5041[CD]|5042[ADEFGWXT]|5044[ADGIKOPSTY]|5045[ADFGIJTXY]|5046[ADGIJSTUY]|5047[DIUY]|5048[AYUI]|5049[EGSWZ]|5050[ASXY]|5051[ADEJMTWX]|5052[ADY]|5053[ADKY]|5054[ADNSTWX]|5056[ADEGIJMNTUWX]|5057M|5058[AIY]|5059[ADJXYZIST]|5060[ADJ]|5061[KU]|5065[ADNWX]|5070D|5080[ADFQUX]|5085[ABCDGHIJNOQY]|5086[ADY]|5090[AIY]|5095[IKY]|5098[OS]|5099[ADYUI]|5116J|5145A|6016[ADEX]|6025H|6036[AXY]|6037[BKY]|6039[AHJKY]|6042D|6043[AD]|6044D|6045[BFIKOYX]|6050[AFY]|6055[ABDHIKPUYZ]|6058[ADX]|6060[SX]|6062W|6070K|7040[ADEFKRT]|7041[DX]|7042A|7043[AEKY]|7044[AX]|7045Y|7048[ASWX]|7053D|7055A|7070X|7071[ADX]|8030Y|8050[DEGX]|8063|8088[XQM]|9001[DIX]|9002X|9003[AX]|9024O|9005X|9026X|9007[ATX]|9008[ADIJNTUX]|9009G|9010X|9020A|9022X|9027[FTWX]|9029Z|9203A|A(?:464BG|570BL|50[13]DL|57[17]VL|574BL)|I213|I216X|(?<!\.)80(?:82|6[78])|A576CC)(?:_(?:EEA|RU))?|P360X)?:[);/ Представили?
нужно залесть в документацию либы и прочитать, как работать с либой, правильно ее записать под конструктор.
мысленно представить как это будет выглядеть в готовой версии, сложив все массивы в уме, это тяжело для людей, которые пишут регулярки лапками всю жизнь
Вот плюсуюсь неоднократно. Лучше самому представлять как регулярки работают.
Alcatel|Alc(?!or .....
Сильно подозреваю, что с помощью конструктора будет проще - здесь явно виден какой-то массив строк (или структур), который удобнее хранить в "вертикальном" виде. Хотя бы во избежание конфликтов в git, которые на такой строке могут быть весёлыми
Скажем, дату или номер телефона пользователи как только не вводят. И чтобы привести введённое к стандартному виду, как раз и нужны регулярки.
Это набор чаров или кодепойнтов? А набор ли это вообще? Строка гасится нуль-терминатором или нет? В строке есть ltr-rtl? Что считать цифрой и что считать плюсом? И ещё сотню вопросов сюда добавьте.
Дело то получается вовсе не в строках, а внезапно в юникоде. Всенепременно попробуйте юникод, вам понравится. Ну потому что — что бы вы не писали — вы скатитесь в низкоуровневое нутро вовсе не строк, а юникода. Если для вас это открытие — так вы совсем не программист.
п.с.: То что вы написали выше — оно вообще не соответствует никаким стандартам. И я тут ни при чём. Это стандарты такие. Ну а тогда причём тут я?
Соберём плюс и цифры. Всё.На этой плонете у всех свои цифры. И пол-планеты пишут задом наперёд, сверху вниз и прочим «раком». И плюсы и прочее тоже у всех свои. Я вовсе не собираюсь «гнусить» и выдавать тут «некую дичь». Мир такой, и например я ничего с этим поделать не могу. Ещё раз напишу, то что вы написали выше не соответствует вообще никаким стандартам, извините.
п.п.с.: Не у всех есть раст. Иногда нужно очень быстро. Иногда нужно своё. Вариантов масса. И парсер превращается в монструозную хреновину. Почему? Так а опять всё просто :) Потому что в юникоде нет кодепойнтов на стандартизованные телефонные цыфры, телефонные разделители и телефонный плюсик с жостким запретом на rtl и т.д. и т.п. Ещё раз?))) Ок. Проблема не в парсинге а в юникоде. Парсинг всего и вся в этом мире плох и ужасен только потому что ужасен юникод. Вот и всё. :)
На этой плонете у всех свои цифры. И пол-планеты пишут задом наперёд, сверху вниз и прочим «раком».Я знаю об этом. Просто моя позиция — нафиг таких.
И парсер превращается в монструозную хреновину.Только код парсера можно читать и дорабатывать, а код монструозной регулярки почти нет. Она ведь тоже по такой же самой логике раздуется до монструозности, разве нет?
У вас есть проблема. Вы решили использовать регулярные выражения чтобы её решить. Теперь у вас две проблемы.
Огромное количество регулярок в интернете не могут провалидировать вполне существующую почту:
box@5.ua
Можно номер этого волшебного RFC?
Полную грамматику по этому RFC вы можете найти тут: https://www.icosaedro.it/phplint/mailer-tutorial/email-ebnf-syntax.text
RFC это прекрасно, но на деле в 99,9999% случаев email без единой точки после @ - это опечатка, и её практичнее ловить на входе. Опять же, домены не из любых алфавитов на практике собираются.
Парсер любых URL в тексте.
Вам, автор, все время хочется писать велосипеды. Которые, с вашей точки зрения, гораздо лучше. Ведь они синие и трехколесные. С трехколесного упасть сложнее, чем с двухколесного! А синий цвет — вызывает доверие по теории цветов, если я не ошибаюсь. И хорошо бы, если бы вы свои велосипеды так и преподносили остальным: с них труднее упасть и они вызывают доверие. Но вы часто пишите свои поделки с таким посылом: все велосипеды, кроме моих, это лютая шляпа. Никому не нужны двухколесные, горные и прочие другие. Есть мои и все.
Я не очень хочу уходить в дискуссию регулярок, но регулярки совсем не сложные. Их синтаксис можно выучить за то же самое время, что и синтаксис любой библиотеки, идущей им на замену. Они гораздо гибче и дают нейтив интеграцию в большинстве мест, где они уместны. А количество человеко-часов, потраченное на написание компиляторов регулярок гораздо больше, чем у альтернатив, из чего следует, что места, которые можно оптимизировать, оптимизированны в большинстве своем. Да, можно написать регулярку, которая убъет программу — есть такие вот сложные для исполнения номера. Но обычно это объясняется большой вариативностью и решить такое — не проблема регулярок конкретно, а проблема вообще.
Ваше желание упростить работу с регулярками я бы направил на создание не генератора, а дебаггера или хотя бы хайлайтера какого-то. Короче чтобы эти вот длинные регулярки не пугали, а можно было бы просто закинуть в какой-то редактор и посмотреть где там группа, где там квантификатор и прочее.
Потратив пару дней на изучение регулярок и много лет применяя их в практике я не имею ни малейшего желания:
1) зачем то что-то стороннее внедрять в свои проекты
2) учить новый синтаксис
3) доверять библиотеке парсинг (это, на секундочку, не шутки — если у вас там где то дырка в билдере, вы можете очень просто создать дыру безопасности)
4) верить, что все это будет быстрее или хотя бы на уровне регулярок
Поэтому, мне не понятно — зачем это все. Как пет-проект для саморазвития — отличная затея! Но чтобы это вот на серьезе выкладывать и говорить, что регулярки это не ок — вы серьезно?
1) добавление нового синтаксиса и «языка»
2) изучение нового синтаксиса к текущему ЯП проекта
3) доверие регулярке тоже может привести к дыре в безопасности, и проводить их аудит сложнее
4) вера в скорость регулярок тоже часто безосновательная
Диалекты регулярок, во-первых, очень похожи или часто даже практически одинаковы. Во-вторых, один раз поняв их синтаксис — вы убъете гораздо больше зайцев, чем если будете разбираться со всеми возможными апишками билдеров в разных языках и местах системы.
Про доверие — в обоих сценариях вы не пишете императивную программу с нуля и не двигаете байты в памяти. Вы все равно перепоручаете кому-то эту задачу. Только одно дело вы это поручите кому-то, кто это делает больше 30 лет (при чем не один), а другое дело вы поручите эту задачу новоиспеченному продукту от одного человека.
Диалекты регулярок, во-первых, очень похожи или часто даже практически одинаковы. Во-вторых, один раз поняв их синтаксис — вы убъете гораздо больше зайцевВы знаете, сколько не пытался, не получается всё это запомнить. Может имея дело с ними каждый день я бы их запомнил, но когда они нужны раз в 2 года, всё забывается.
чем если будете разбираться со всеми возможными апишками билдеров в разных языках и местах системы.А я и не говорю, что надо пользоваться билдерами. Я предлагал вообще писать код на том же языке, на котором весь проект. Да, просто используя for, if, while и т.п.
Как-то раз помогал сыну маминой подруги парсить набор валидных объявлений переменных одним регулярным выражением (на подмножестве C, C#, Pascal — там потом ещё его друзья подтянулись) с поддержкой массивов и т.п. Регулярка должна была распознавать валидный код ровно до того места, где есть ошибка (если есть). Дичь конечно, но преподаватель у них вот так захотел. Вот там итоговое выражение получалось в экран размером, со всякими backtracking'ами и прочими прелестями. Компоновал итоговое выражение из более простых, иначе никак в такой ситуации. Для такой задачи на самом деле использовать регулярные выражения — бред, никто в здравом уме делать так не будет, для этого есть лексические и синтаксические анализаторы. Бедные студенты, мне было их искренне жаль.
Как верно подмечено выше, если у вас настолько сложный парсинг, что нужно компоновать выражения и/или использовать какие-то билдеры — скорее всего другой инструмент подойдёт лучше для этой задачи. И наоборот, если есть массив данных попроще — таких как номер телефона или email — обычные регулярные выражения подойдут как нельзя лучше, и никаких билдеров не нужно.
Фичи интересные, но учить регулярки они не отменяют - во первых нужно понимать что это такое и как оно вообще работает, а во вторых-когда оно сломается придётся заглянуть под капот. А вот как обвязку над регулярками вытаскивающую данные в объект без лишних телодвижений продать в принципе можно.
Поздравляю, вы сделали эрзац-парсер-комбинаторы
Да хватит уже писать эти регулярки