Welche Unterstützung gibt es für PCRE (Perl Compatible Regular Expressions) in gängigen Sprachen?

Question

Ich interessiere mich für die Leistungsfähigkeit von PCRE (Perl Compatible Regular Expressions) und frage mich, ob sie wahrscheinlich in allen wichtigen Sprachen zu einem De-facto-Ansatz werden (ich bin an Java interessiert). Ich bin bereit, bei Bedarf eine Bibliothek zu benutzen.

ich so auch nicht eine gute Seite in SO beschreibt die Vor- und Nachteile von PCRE finden könnte, wenn diese nicht vorhanden ist sinnvoll sein, könnte dies in den Antworten enthalten

EDIT ich über Java in Kraft interessiert bin 1.6 Regex, besonders benannte Capture-Gruppen

Answer 1

Es scheint, dass mehr Mainstream-Sprachen tatsächlich ihre eigene Implementierung von "Perl-like" Regexes verwenden, als tatsächlich libpcre verwenden. Zu den Sprachen, die in diese Klasse fallen, gehören (mindestens) Java, JavaScript und Python.

Java java.util.regex Bibliothek verwendet eine Syntax, die auf Perl sehr stark basiert (ca.. Version 5.8) Regexes, einschließlich der Vorschriften für die Flucht, die \p und \P Unicode-Klassen, nicht gierig und "besitzergreifend" quantifiers, Rückreferenzierungen, \Q. . \E zitiert, und mehrere der (?...) Konstrukte einschließlich non-Capturing-Gruppen, Lookahead/hinten Null-Breite und nicht-Backtracking-Gruppen. Tatsächlich scheinen Java-Regexes mehr mit Perl-Regexes zu gemein zu haben als libpcre. :)

Die JavaScript-Sprache verwendet auch Regexes, die von Perl abgeleitet sind; Unicode-Klassen, Lookbehind, Possessiv-Quantoren und Nicht-Backtracking-Gruppen fehlen, aber der Rest von dem, was ich für Java erwähnt habe, ist auch in JS vorhanden.

Python Regex-Syntax basiert auch auf Perl 5, mit nicht-gierigen Quantifikatoren, die meisten der (?...) Konstrukte einschließlich non-Capturing-Gruppen, Look-Ahead/hinter und bedingten Mustern, sowie benannte Capture-Gruppen (aber mit a andere Syntax als Perl oder PCRE). Non-Backtracking-Gruppen und 'Possessiv'-Quantifizierer sind (soweit ich sehen kann) abwesend, wie auch \p und \P Unicode-Zeichenklassen, obwohl die Klassen \d, und \w auf Anfrage Unicode-fähig sind.

Answer 2

Ich ... frage mich, ob sie [PCRE] wahrscheinlich in allen wichtigen Sprachen zu einem De-facto-Ansatz werden (ich interessiere mich für Java).

Dies erfordert Spekulationen, aber ich denke, dass die Antwort Nein ist ... im Fall von Java. Ich basiere dies auf der Tatsache, dass ich keine lohnende PCRE-Implementierung für Java finden kann. (Abgesehen von java.util.regex natürlich.)

Wenn es eine echten Bedarf/Nachfrage nach PCRE in Java, würde ich es erwartet habe mehr Bibliotheken da draußen zu sein.

Answer 3

Das klingt viel wie ein "Ist X der Eine wahre Weg !?" Art von Frage. PCRE hat viele Mängel, von denen die Komplexität und der fragliche Nutzen am offensichtlichsten sind. Selten gibt es einen One True Way für irgendetwas, und im Bereich der Regexp-Bibliotheken ist es PCRE ganz sicher nicht.

Perl reguläre Ausdrücke sind meiner Meinung nach völliger Müll. Wenn Sie das Feature-Set von POSIX extended regexps (ERE) nicht mehr benötigen, können Sie auch etwas wie eine PEG-Implementierung verwenden.Der einzige Grund, warum PCRE so häufig verwendet wird, ist, dass es für Leute einfach ist, ein Problem zu lösen, indem sie einfach in eine Bibliothek fallen lassen.

Answer 4

Versuchen Sie, eine Split-off dieses Spiels zu tun:

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

Seien Sie sicher, dass die 'x' und 'g' verwenden (falls erforderlich) Modifikator (en).

Example