Какая поддержка для PCRE (Perl Compatible Regular Expressions) на общих языках?

Меня интересует мощь PCRE (совместимые с Perl регулярные выражения) и задаются вопросом, могут ли они стать де-факто подходом на всех основных языках (меня интересует Java). Я готов при необходимости использовать библиотеку.

Я также не смог найти хорошую страницу в SO, описывающую плюсы и минусы PCRE, поэтому, если этого не существует, было бы полезно включить это в ответы

EDIT Я заинтересован в мощности за пределами Java 1.6 regex, особенно названных групп захвата

Ответы

Ответ 1

Похоже, что более обычные языки фактически используют собственную реализацию "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.

Синтаксис regex Python также основан на Perl 5, с не-жадными квантификаторами, большинство конструкций (?...), включая группы, не захватывающие, прогнозные/отстающие и условные шаблоны, а также названные группы захвата (но с другой синтаксис, чем Perl или PCRE). Группы без обратного слежения и "обладающие" квантификаторы (насколько я могу видеть) отсутствуют, а также классы символов \p и \p Unicode, хотя стандартные классы \d, \s и \w Unicode-aware, если требуется.

Ответ 2

Я... задаюсь вопросом, могут ли они [PCRE] стать фактическим подходом на всех основных языках (меня интересует Java).

Это требует спекуляции, но я думаю, что ответ No... в случае Java. Я основываю это на том, что я не могу найти какую-либо достойную реализацию PCRE для Java. (Кроме java.util.regex, конечно.)

Если бы была настоящая потребность/требование для PCRE в Java, я бы ожидал, что там будет больше библиотек.

Ответ 3

Попробуйте сделать отрыв этого совпадения:

(?:
  (?:'[\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" (если необходимо).

Пример

Ответ 4

Это звучит так же, как "Is X One True Way!?" вид вопросов. PCRE имеет много недостатков, наиболее очевидным из которых является сложность и сомнительная полезность. Редко существует один True Way для чего-либо, и в области библиотек регулярных выражений PCRE, безусловно, не так.

Регулярные выражения Perl являются, по-моему, полным нежелательным. Когда вы получите намного больше возможностей, предлагаемых расширенными регулярными выражениями POSIX (ERE), вы можете использовать что-то вроде реализации PEG. Единственная причина, по которой PCRE широко используется, - это то, что людям легко решить проблему, просто отбросив библиотеку.