Какая поддержка существует для PCRE (Perl-совместимых регулярных выражений) на распространенных языках?
-
11-09-2019 - |
Вопрос
Меня интересует мощь PCRE (регулярные выражения, совместимые с Perl) и интересно, могут ли они стать фактическим подходом на всех основных языках (меня интересует Java).Я готов воспользоваться библиотекой, если это необходимо.
Я также не смог найти хорошую страницу в SO, описывающую плюсы и минусы PCRE, поэтому, если этого не существует, было бы полезно включить это в ответы
Редактировать Меня интересуют возможности, выходящие за рамки регулярных выражений Java 1.6, в частности именованные группы захвата
Решение
Похоже, что более распространенные языки на самом деле используют свою собственную реализацию "Perl-подобных" регулярных выражений, чем на самом деле используют libpcre.Языки, которые попадают в этот класс, включают (как минимум) Java, JavaScript и Python.
Java-х java.util.regex
библиотека использует синтаксис, который в значительной степени основан на Perl (прим.версия 5.8) регулярные выражения, включая правила экранирования, \p
и \P
Классы Unicode, нежадные и "притяжательные" кванторы, обратные ссылки, \Q
..\E
цитируя, и некоторые из (?...)
конструкции, включающие группы без захвата, просмотры вперед / назад нулевой ширины и группы без обратного отслеживания.На самом деле регулярные выражения Java, похоже, имеют больше общего с регулярными выражениями Perl, чем libpcre.:)
Язык JavaScript также использует регулярные выражения , которые являются производными от Perl;Классы Unicode, lookbehind, притяжательные квантификаторы и группы без обратного отслеживания отсутствуют, но остальная часть того, что я упомянул для Java, также присутствует в JS.
Синтаксис регулярных выражений Python также основан на Perl 5 с нежадными квантификаторами, большая часть (?...)
конструкции, включающие группы без захвата, просмотр вперед / назад и условные шаблоны, а также именованные группы захвата (но с синтаксисом, отличным от Perl или PCRE).Группы без обратного отслеживания и "притяжательные" квантификаторы (насколько я могу видеть) отсутствуют, как и \p
и \P
Классы символов Юникода, хотя стандартный \d
, \s
, и \w
классы поддерживают Unicode, если требуется.
Другие советы
Я...интересно, могут ли они [PCRE] стать фактическим подходом на всех основных языках (меня интересует Java).
Это вызывает предположения, но я думаю, что ответ будет отрицательным ...в случае Java.Я основываю это на том факте, что я не могу найти Любой стоящая реализация PCRE для Java.(Помимо java.util.regex
конечно.)
Если бы существовал реальный потребность / demand в PCRE на Java, я бы ожидал, что там будет больше библиотек.
Попробуйте сделать разделение этого матча:
(?:
(?:'[\S\s]*?(?<!\\)') # Consume characters inside of a quoted string
|(?:\/\*[\S\s]*?\*\/) # Consume multi-line comments
|(?m:\/{2}[^\n]*$\n) # Consume single-line comments
)(*SKIP)(*F) # Fail match if any of the previous matches were found
|(?<=;) # Capture position right after semicolon
Обязательно используйте модификаторы 'x' и 'g' (при необходимости).
Это очень похоже на вопрос типа "Является ли X Единственным истинным путем!?".PCRE имеет много недостатков, наиболее очевидными из которых являются его сложность и сомнительная полезность.Редко существует Единственный Верный способ для чего-либо, и в области библиотек регулярных выражений PCRE, безусловно, им не является.
Регулярные выражения Perl, на мой взгляд, - это полный мусор.Как только вы выйдете далеко за рамки набора функций, предлагаемого POSIX extended regexps (ERE), вы также можете использовать что-то вроде реализации PEG.Единственная причина, по которой PCRE используется так широко, заключается в том, что людям легко решить проблему, просто зайдя в библиотеку.