Comments 17
Вот так живешь, пишешь код, а потом бац - оказывается не правильно писал ))
Долго пытался понять что означает слово "экранировать" в данном контексте. Ближе к концу статьи только допёрло, я медленный.
Ну и да, в регексах действительно и пробелы и прочее подозрительное лучше всегда записывать в безопасном виде. Напишете лишний раз \s, и избавите себя от пары часов ловли необъяснимого бага в самый неподходящий момент.
Напишете лишний раз \s
Только нужно не забывать, что в \s входит куча разных символов, включая разделители строк.
В данном примере я условно, конечно.
Хотя даже тут, на практике, в 99.97% случаев в реальных проектах вы знаете что у вас туда прилетит либо только пробел либо только tab (либо или то или другое), и вас это обычно полностью устраивает.
Кстати ещё не надо забывать что регексы водятся не только в жабоскрипте, но и во всех современных языках программирования (и не только в языках), и синтакс у них иногда может в мелочах отличаться. И надо всегда стараться писать максимально совместимо, потому что бывает такое что люди копипастят регекс из фронтенда в эликсирный или жабный бэкенд, а потом опять же тратят не один час на ловлю совершенно необязательной проблемы.
Тут конечно не лениться писать тесты помогает, но тоже не всегда.
Архитектурная ошибка: regex - это язык (команды + данные в одной строке, ровно как SQL). Как только тебе нужно вручную подставлять данные в язык - ты получаешь injection-проблему. Escape - это пластырь. Правильный ответ - не смешивать
Это не самая большая проблема. Важнее падение читаемости сложных регулярок, таких как проверка адреса электронной почты, которая мне напоминает Brainfuck.
Поэтому нужно не регулярки развивать, а добавить удобное апи для описания регулярных парсеров, как тут. Побочный эффект такого апи - возможность не только компоновать, парсить и валидировать, но и генерировать строки, гарантированно соответствующие синтаксису.
А как — не смешивая — разрешить пользователю искать с использованием регулярок? Так-то понятно, что лучше быть здоровым и богатым…
это нужно для корректного сцепления двух регулярных выражений
Для этого надо ещё перенумеровать обратные ссылки во втором регексе, экранированием тут не отделаться. Для конкатенация правильно было бы отдельный метод.
Можно пример? Экранированная строка (правая) не влияет на разбор итоговой регулярки, в ней нет backreferences.
При сложении регексов (\d) и (.)\1 должно получиться (\d)(.)\2 , бэкреф теперь на вторые скобки.
В статье рассматривается другой случай, когда часть регулярки нужно экранировать и искать просто как текст. В вашем случае экранировка не нужна.
Чтобы не мучится с номерами групп, можно использовать ссылки на именованные группы.
Экранирование через '\$&' ломает u флаг
https://github.com/sindresorhus/escape-string-regexp/commit/732905da074f0220487ad6a27590f89bd0819374
Это нормальное поведение Unicode-режима, нельзя что угодно пихать после \.
Функция в моей статье не экранирует -, поэтому её результат нельзя использовать в [наборе символов]. Нужно добавить в статью либо экранировку -, либо предупреждение, не знаю что лучше...
- имхо экранировать обязательно, ибо подавляющее число сценариев использования, когда нужен escape, есть использование регулярки как части большего регулярного выражения. А поскольку мы не всегда можем знать будет ли экранированный кусок использоваться с u или без , то лучше всегда исходить из расчета что u будет включен.
Почему JavaScript-функция RegExp.escape() экранирует латинские буквы, пробелы и ухо луны