Какова поддержка PCRE (совместимых с Perl регулярных выражений) на общих языках? - PullRequest
8 голосов
/ 19 сентября 2009

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

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

РЕДАКТИРОВАТЬ Меня интересуют возможности, выходящие за рамки Java 1.6 regex, в частности именованные группы захвата

Ответы [ 4 ]

10 голосов
/ 19 сентября 2009

Похоже, что больше распространенных языков фактически используют свою собственную реализацию "Perl-подобных" регулярных выражений, чем фактически использует libpcre. Языки, попадающие в этот класс, включают (как минимум) Java, JavaScript и Python.

Библиотека Java java.util.regex использует синтаксис, который очень сильно основан на регулярных выражениях Perl (около версии 5.8), включая правила экранирования, классы Unicode \p и \P, нежадные и "притяжательные" квантификаторы обратные ссылки, цитирование \Q .. \E и несколько конструкций (?...), включая группы без захвата, группы просмотра вперед / назад нулевой ширины и группы без возврата. На самом деле, регулярные выражения Java имеют больше общего с регулярными выражениями Perl, чем libpcre. :)

Язык JavaScript также использует регулярные выражения, полученные из Perl; Классы Unicode, lookbehind, собственнические квантификаторы и группы без возврата отслеживания отсутствуют, но остальная часть того, что я упомянул для Java, также присутствует в JS.

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

0 голосов
/ 11 августа 2015

Попробуйте сделать отрыв этого матча:

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

Пример

0 голосов
/ 13 декабря 2013

Это звучит очень похоже на "Является ли Х Единый Истинный Путь !?" такой вопрос У PCRE есть много недостатков, наиболее очевидным из которых является его сложность и сомнительная полезность. Редко существует Единый Истинный Путь для чего-либо, и в области библиотек регулярных выражений PCRE наверняка не таков.

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

0 голосов
/ 06 августа 2013

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

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

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

...