Какие специальные символы должны быть экранированы в регулярных выражениях?

Question

Какие специальные символы должны быть экранированы в регулярных выражениях?

254

Я устал от того, что всегда пытаюсь угадать, если мне нужно избегать специальных символов типа "()[]{}|" и т.д. при использовании многих реализаций регулярных выражений.

Это отличается от, например, Python, sed, grep, awk, Perl, переименования, Apache, find и т.д. Есть ли какой-либо набор правил, который говорит, когда я должен, а когда не должен, сбегать от специальных символов? Это зависит от типа regexp, такого как PCRE, POSIX или расширенные регулярные выражения?

Igor Katson 29 дек. 2008, в 23:30

Источник

3

Хорошие библиотеки регулярных выражений имеют функции, такие как escape() позволяющие использовать произвольные строки в качестве частей регулярных выражений.
ivan_pozdeev 27 июнь 2013, в 08:38
1

Вы можете использовать онлайн-выражения Regex, такие как gskinner.com/RegExr (это бесплатно). (Введите, затем наведите курсор мыши на введенное вами регулярное выражение)
hexicle 12 июль 2013, в 08:03
0

В PHP вы можете использовать php.net/preg_quote
Camilo Martin 08 дек. 2013, в 11:22
1

Избегайте всех не алфавитно-цифровых символов. период.
Salman Abbas 22 фев. 2014, в 21:51
1

Этот вопрос был добавлен в FAQ по регулярному выражению переполнения стека в разделе «Другое».
aliteralmind 10 апр. 2014, в 01:05
1

Этот вопрос был добавлен в FAQ по регулярному выражению переполнения стека в разделе «Escape-последовательности».
aliteralmind 10 апр. 2014, в 02:28
0

см. также \Q ... \E Escape. \Qhello?\E соответствует "привет?" но не "ад" или "привет". Работает как минимум в PCRE / PHP / Perl / Go
Neil McGuigan 23 март 2017, в 00:15

Показать ещё 5 комментариев

Теги:

regex

8 ответов

34

Современные ароматы RegEx (PCRE)

^{Включает C, С++, Delphi, EditPad, Java, JavaScript, Perl, PHP (preg), PostgreSQL, PowerGREP, PowerShell, Python, REALbasic, Real Studio, Ruby, TCL, VB.Net, VBScript, wxWidgets, XML Schema, Xojo, XRegExp.
Совместимость с PCRE может варьироваться}

Anywhere: . ^ $ * + - ? ( ) [ ] { } \ |

Legacy RegEx Flavors (BRE/ERE)

^{Включает awk, ed, egrep, emacs, GNUlib, grep, PHP (ereg), MySQL, Oracle, R, sed.
Поддержка PCRE может быть включена в более поздних версиях или с использованием расширений}

ERE/AWK//Emacs задать расширенное

Вне класса символов: . ^ $ * + ? ( ) [ { } \ |
внутри класса символов: ^ - [ ]

BRE/Под ред/Grep/СЭД

Вне класса символов: . ^ $ * [ \
внутри класса символов: ^ - [ ]
Для литералов не убегайте: + ? ( ) { } |
Для стандартного поведения регулярных выражений escape: \+ \?  \{ \} \|

Примечания

Если вы не уверены в конкретном символе, он может быть экранирован как \xFF
Буквенно-цифровые символы не могут быть экранированы с помощью обратного слэша
Произвольные символы могут быть экранированы с помощью обратного слэша в PCRE, но не BRE/ERE (при необходимости они должны быть экранированы). Для PCRE ] - требуется только экранирование в классе символов, но я просто сохранил их в одном списке
Строки цитируемых выражений также должны иметь экранированные символы кавычек, а часто с двойным обратным слэшем (например, "(\")(/)(\\.)" по сравнению с /(")(\/)(\.)/ в JavaScript)
Помимо экранов, различные реализации регулярных выражений могут поддерживать различные модификаторы, классы символов, якоря, кванторы и другие функции. Для получения более подробной информации ознакомьтесь с regular-expressions.info или используйте regex101.com проверить свои выражения в режиме реального времени

Beejor 25 авг. 2015, в 19:27

0

В вашем ответе много ошибок, включая, но не ограничиваясь: ни один из ваших «современных» вариантов не требует - или ] экранирования вне классов персонажей. POSIX (BRE / ERE) не имеет escape-символа внутри классов символов. Аромат регулярных выражений в RTL Delphi фактически основан на PCRE. Python, Ruby и XML имеют свои собственные разновидности, которые ближе к PCRE, чем к POSIX.
Jan Goyvaerts 23 фев. 2017, в 08:05
0

@JanGoyvaerts Спасибо за исправление. Упоминаемые вами ароматы действительно ближе к PCRE. Что касается побегов, я сохранил их так для простоты; легче вспомнить, чтобы просто убежать везде, чем несколько исключений. Опытные пользователи будут знать, что случилось, если они хотят избежать нескольких обратных слешей. В любом случае, я обновил свой ответ несколькими разъяснениями, которые, надеюсь, касаются некоторых из этих вещей.
Beejor 07 март 2017, в 03:15

18

К сожалению, на самом деле нет установленного набора escape-кодов, поскольку он зависит от языка, который вы используете.

Однако, сохраняя страницу, подобную странице инструментов регулярных выражений или Regular Cheatsheet может пройти долгий путь, чтобы помочь вам быстро отфильтровать вещи.

Dillie-O 29 дек. 2008, в 23:46

1

Шпаргалка Addedbytes сильно упрощена и содержит некоторые грубые ошибки. Например, он говорит, что \< и \> являются границами слов, что является истинным (AFAIK) в библиотеке регулярных выражений Boost. Но в других местах написано, что < и > являются метасимволами и должны быть экранированы (в \< и \> ), чтобы буквально соответствовать им, что не соответствует действительности.
Alan Moore 07 март 2017, в 05:00

3

POSIX распознает несколько вариантов регулярных выражений - основных регулярных выражений (BRE) и расширенных регулярных выражений (ERE). И даже тогда есть причуды из-за исторических реализаций утилит, стандартизированных POSIX.

Нет простого правила для использования какой-либо нотации или даже той нотации, которую использует данная команда.

Отъезд Jeff Friedl Книга "Освоение регулярных выражений" .

Jonathan Leffler 30 дек. 2008, в 01:19

2

К сожалению, значение таких вещей, как (и\(меняются между регулярными выражениями стиля Emacs и большинством других стилей). Поэтому, если вы попытаетесь избежать этого, вы можете делать противоположное тому, что вы хотите.

Итак, вам действительно нужно знать, какой стиль вы пытаетесь процитировать.

Darron 30 дек. 2008, в 01:00

2

Иногда с указанными вами символами невозможно простое экранирование. Например, использование обратной косой черты для выхода из скобки не будет работать в левой части строки подстановки в sed, а именно

sed -e 's/foo\(bar/something_else/'

Я обычно использую просто определение класса символов, поэтому вышеприведенное выражение становится

sed -e 's/foo[(]bar/something_else/'

который я нахожу, работает для большинства реализаций регекса.

Кстати. Классы символов - это довольно ванильные компоненты регулярного выражения, поэтому они, как правило, работают в большинстве ситуаций, когда вам нужны экранированные символы в регулярных выражениях.

Изменить: После комментария ниже, просто подумал, что я бы упомянул о том, что вам также нужно учитывать разницу между автоматами конечного состояния и автоматами не конечного состояния при рассмотрении поведения регулярного выражения оценка.

Вам может понравиться смотреть "блестящую книгу с шариками", а также "Эффективный Perl" (санированная ссылка Amazon), в частности главу о регулярных выражениях, чтобы почувствовать разницу в типах оценки двигателя regexp.

Не во всем мире PCRE!

В любом случае regexp настолько неуклюжий по сравнению с SNOBOL! Теперь , который был интересным курсом программирования! Наряду с одним на Simula.

А радости обучения в UNSW в конце 70-х! (-:

Rob Wells 30 дек. 2008, в 00:41

0

'sed' - это команда, для которой обычный '(' не является особенным, но '\ (' является особенным; напротив, PCRE меняет смысл, поэтому '(' является особенным, но '\ (' - нет. Это именно то, что ОП спрашивает о.
Jonathan Leffler 30 дек. 2008, в 08:43
0

sed - это утилита * nix, которая использует один из самых примитивных наборов оценки регулярных выражений. PCRE не входит в ситуацию, которую я описываю, поскольку он включает в себя другой класс (не) конечных автоматов с тем, как он оценивает регулярные выражения. Я думаю, что мое предложение для минимального набора синтаксиса регулярных выражений все еще остается в силе.
Rob Wells 31 дек. 2008, в 01:32
1

В POSIX-совместимой системе sed использует POSIX BRE, о чем я расскажу в своем ответе. Версия GNU в современной системе Linux использует POSIX BRE с несколькими расширениями.
Jan Goyvaerts 31 дек. 2008, в 07:30

Показать ещё 1 комментарий

1

Действительно, нет. существует около полумиллиона различных синтаксисов регулярных выражений; они, похоже, доходят до Perl, EMACS/GNU и AT & T в целом, но я всегда удивляюсь.

Charlie Martin 30 дек. 2008, в 00:38

0

Для PHP, "всегда безопасно предшествовать не буквенно-цифровому с" \ ", чтобы указать, что он обозначает себя". - http://php.net/manual/en/regexp.reference.escape.php.

За исключением случаев, когда это "или".:/

Чтобы избежать переменных шаблона регулярного выражения (или частичных переменных) в PHP, используйте preg_quote()

zylstra 01 окт. 2013, в 11:49

Ещё вопросы

Хорошие библиотеки регулярных выражений имеют функции, такие как escape() позволяющие использовать произвольные строки в качестве частей регулярных выражений.
Вы можете использовать онлайн-выражения Regex, такие как gskinner.com/RegExr (это бесплатно). (Введите, затем наведите курсор мыши на введенное вами регулярное выражение)
В PHP вы можете использовать php.net/preg_quote
Избегайте всех не алфавитно-цифровых символов. период.
Этот вопрос был добавлен в FAQ по регулярному выражению переполнения стека в разделе «Другое».
Этот вопрос был добавлен в FAQ по регулярному выражению переполнения стека в разделе «Escape-последовательности».
см. также \Q ... \E Escape. \Qhello?\E соответствует "привет?" но не "ад" или "привет". Работает как минимум в PCRE / PHP / Perl / Go
В вашем ответе много ошибок, включая, но не ограничиваясь: ни один из ваших «современных» вариантов не требует - или ] экранирования вне классов персонажей. POSIX (BRE / ERE) не имеет escape-символа внутри классов символов. Аромат регулярных выражений в RTL Delphi фактически основан на PCRE. Python, Ruby и XML имеют свои собственные разновидности, которые ближе к PCRE, чем к POSIX.
@JanGoyvaerts Спасибо за исправление. Упоминаемые вами ароматы действительно ближе к PCRE. Что касается побегов, я сохранил их так для простоты; легче вспомнить, чтобы просто убежать везде, чем несколько исключений. Опытные пользователи будут знать, что случилось, если они хотят избежать нескольких обратных слешей. В любом случае, я обновил свой ответ несколькими разъяснениями, которые, надеюсь, касаются некоторых из этих вещей.
Шпаргалка Addedbytes сильно упрощена и содержит некоторые грубые ошибки. Например, он говорит, что \< и \> являются границами слов, что является истинным (AFAIK) в библиотеке регулярных выражений Boost. Но в других местах написано, что < и > являются метасимволами и должны быть экранированы (в \< и \> ), чтобы буквально соответствовать им, что не соответствует действительности.
'sed' - это команда, для которой обычный '(' не является особенным, но '\ (' является особенным; напротив, PCRE меняет смысл, поэтому '(' является особенным, но '\ (' - нет. Это именно то, что ОП спрашивает о.
sed - это утилита * nix, которая использует один из самых примитивных наборов оценки регулярных выражений. PCRE не входит в ситуацию, которую я описываю, поскольку он включает в себя другой класс (не) конечных автоматов с тем, как он оценивает регулярные выражения. Я думаю, что мое предложение для минимального набора синтаксиса регулярных выражений все еще остается в силе.
В POSIX-совместимой системе sed использует POSIX BRE, о чем я расскажу в своем ответе. Версия GNU в современной системе Linux использует POSIX BRE с несколькими расширениями.

Jan Goyvaerts · Accepted Answer · 2008-12-30T15-41-00.000Z

Какими персонажами вы должны и которые вы не должны убежать, действительно зависит от вашего регулярного эффекта, с которым вы работаете.

Для PCRE и большинства других так называемых Perl-совместимых ароматов избегайте этих внешних классов символов:

.^$*+?()[{\|

и эти внутренние классы символов:

^-]\

Для расширенных регулярных выражений POSIX (ERE), избегайте этих внешних классов символов (таких же, как PCRE):

.^$*+?()[{\|

Выход из любого другого символа - ошибка с POSIX ERE.

Внутри классов символов обратная косая черта является буквальным символом в регулярных выражениях POSIX. Вы не можете использовать его, чтобы избежать чего-либо. Вы должны использовать "умное размещение", если хотите включить метасимволы класса символов в виде литералов. Поместите ^ в любом месте, кроме как в начале, в начале, а в начале или в конце класса символов, чтобы они соответствовали буквально, например:

[]^-]

В базовых регулярных выражениях POSIX (BRE) это метасимволы, которые вам нужно избежать, чтобы подавить их смысл:

.^$*

В скользящих скобках и фигурных скобках в BRE задается особый смысл, который их неописуемые версии имеют в ERE. Некоторые реализации (например, GNU) также придают особое значение другим символам при экранировании, например \? и+. Выключение символа, отличного от. ^ $*() {}, Как правило, является ошибкой с BRE.

Внутри классов символов BRE следуют тому же правилу, что и ERE.

Если все это заставляет вашу голову вращаться, возьмите копию RegexBuddy. На вкладке "Создать" нажмите "Вставить маркер", а затем "Литерал". При необходимости RegexBuddy добавит экраны.

Мне кажется, вы забыли "/", который также должен быть экранирован вне класса.
/ не является метасимволом ни в одном из упомянутых мною вариантов регулярного выражения, поэтому синтаксис регулярного выражения не требует его экранирования. Когда регулярное выражение цитируется как литерал на языке программирования, то строка или регулярных выражений правил форматирования этого языка может потребоваться / или " или ' быть экранированы, и может даже потребовать `\` , чтобы быть вдвойне убежали.
как насчет двоеточия, ":"? Должен ли он быть экранирован как внутри классов персонажей, так и снаружи? en.wikipedia.org/wiki/Perl_Compatible_Regular_Expressions говорит, что «PCRE имеет последовательные экранирующие правила: любой не алфавитно-цифровой символ может быть экранирован для обозначения его литерального значения [...]»
МОЖЕТ быть спасено не то же самое, что ДОЛЖНО быть спасено. Синтаксис PCRE никогда не требует экранирования буквального двоеточия, поэтому экранирование буквальных двоеточий только затрудняет чтение вашего регулярного выражения.
Для не POSIX ERE (которое я использую чаще всего, потому что это то, что реализовано в Tcl), экранирование других вещей не приводит к ошибкам.
Если вы ставите дефис в начале класса символов, он не нуждается в экранировании.
Теперь я должен избегать каких-либо символов внутри классов символов или нет? В верхней части вы говорите, что я должен, позже вы говорите, что я не должен. Или вы имеете в виду «Эти персонажи имеют особое значение внутри классов персонажей». Это не то же самое, что "нужно сбежать", или это так?
@AndreKR: первая часть моего ответа говорит о PCRE, который позволяет вам экранировать специальные символы в классах символов с обратной косой чертой и требует экранирования обратной косой черты внутри классов символов. Вторая часть моего ответа говорит о POSIX, который обрабатывает обратную косую черту как литерал в классах символов, требуя от вас использовать «умное размещение» символов со специальным значением в классах символов. Умное размещение также работает с PCRE для всех специальных символов внутри классов символов, кроме обратной косой черты.
@jackthehipster, я тоже застрял, думая, что "/" не хватает, потому что я временно забыл, что sed может использовать разделители, отличные от косой черты.
Для разработчиков JavaScript : const escapePCRE = string => string.replace(/[.*+?^${}()|[\]\\]/g, "\\$&"); из сети разработчиков Mozilla .
Вне символьного класса, с PCRE и другими Perl-подобными регулярными выражениями, если флаг x активирован, вы также должны экранировать # (потому что он вводит комментарий). Внутри класса персонажей это не нужно.
" и ' не являются метасимволами ни в одном из известных мне регулярных выражений. Не путайте экранирующие метасимволы в регулярном выражении (о котором идет речь в этом вопросе) с экранирующими разделителями при форматировании регулярного выражения в виде строки в исходном коде (который добавляет второй набор Правила побега).
Нет, я не забыл } . Это не должно быть экранировано ни в одном из ароматов, упомянутых в моем ответе. Очень немногие ароматы требуют, чтобы он избежал.