¿Qué soporte hay para PCRE (expresiones regulares compatibles con Perl) en idiomas comunes?

Question

Estoy interesado en el poder de PCRE (Perl Compatible Regular Expressions) y me pregunto si es probable que se conviertan en un enfoque de facto en todos los idiomas principales (estoy interesado en Java). Estoy preparado para usar una biblioteca si es necesario.

Tampoco podía encontrar una buena página en la descripción por lo que los pros y los contras de PCRE por lo que si esto no existe, podría ser útil incluir esto en respuestas

EDITAR Estoy interesado en el poder más allá de Java 1.6 regex, particularmente grupos de captura nombrados

Answer 1

Parece que los lenguajes más comunes en realidad usan su propia implementación de expresiones regulares "similares a Perl" que las que realmente usan libpcre. Los idiomas que entran en esta clase incluyen (al menos) Java, JavaScript y Python.

java.util.regex la biblioteca de Java utiliza una sintaxis que está muy fuertemente basada en Perl (aprox. Versión 5.8) expresiones regulares, incluyendo las reglas para escapar, los \p y \P clases Unicode, no codiciosos y cuantificadores "posesivos", referencias hacia atrás, \Q. .\E citando, y varias de las construcciones (?...) incluyendo grupos que no capturan, búsqueda anticipada de ancho cero/detrás, y grupos que no retroceden. De hecho, las expresiones regulares de Java parecen tener más en común con las expresiones regulares de Perl que las de libpcre. :)

El lenguaje JavaScript también usa expresiones regulares que se derivan de Perl; Están ausentes las clases Unicode, look-behind, los cuantificadores posesivos y los grupos sin retroceso, pero el resto de lo que mencioné para Java también está presente en JS.

La sintaxis de expresiones regulares de Python también se basa en Perl 5, con cuantificadores no codiciosos, la mayoría de los constructos (?...) incluyendo grupos no capturadores, patrones anticipados/posteriores y condicionales, así como grupos de captura con nombre (pero con un sintaxis diferente de Perl o PCRE). Los grupos sin retroceso y los cuantificadores "posesivos" están ausentes (hasta donde puedo ver), como lo son las clases de caracteres Unicode \p y \P, aunque las clases estándar \d, \s y \w son aptas para Unicode si así lo solicita.

Answer 2

Me pregunto si [PCRE] es probable que se convierta en un enfoque de facto en todos los idiomas principales (estoy interesado en Java).

Esto llama a la especulación, pero creo que la respuesta es No ... en el caso de Java. Basé esto en el hecho de que no puedo encontrar ninguna implementación de PCRE válida para Java. (Aparte de java.util.regex por supuesto.)

Si había una verdadera necesidad/demanda de PCRE en Java, me hubiera esperado que haya más bibliotecas por ahí.

Answer 3

Esto suena muy parecido a "¿Es X la única manera verdadera?" tipo de pregunta. PCRE tiene muchos defectos, el más obvio de los cuales es su complejidad y utilidad cuestionable. Rara vez existe un One True Way para nada, y en el ámbito de las bibliotecas de expresiones regulares, PCRE ciertamente no lo es.

Las expresiones regulares de Perl son absolutamente basura en mi opinión. Una vez que haya superado con creces el conjunto de características ofrecido por las expresiones regulares extendidas de POSIX (ERE), también puede utilizar algo así como una implementación de PEG.La única razón por la que se utiliza PCRE es porque es fácil para las personas resolver un problema simplemente ingresando en una biblioteca.

Answer 4

trate de hacer una división fuera de este partido:

(?: 
    (?:'[\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 

Asegúrese de utilizar el e 'g' 'x' (si es necesario) modificador (s).

Example