Je suis intéressé par le pouvoir de PCRE (expressions régulières compatibles PERL) et je me demande si elles sont susceptibles de devenir une approche de facto dans toutes les langues principales (je suis intéressé par Java). Je suis prêt à utiliser une bibliothèque si nécessaire.
Je n'ai pas non plus trouvé de bonne page en décrivant ainsi les avantages et les inconvénients de PCRE, donc si cela n'existe pas, il pourrait être utile d'inclure cela dans les réponses
edit Je suis intéressé par le pouvoir au-delà de Java 1.6 Regex, en particulier des groupes de capture nommés
5 Réponses :
Il semble que davantage de langues ordinaires utilisent réellement leur propre mise en œuvre de regexnes "de type Perl" que d'utiliser réellement libpcre. Les langues qui tombent dans cette classe comprennent (au moins) Java, JavaScript et Python.
La langue javascript utilise également des regex dérivés de Perl; Les classes Unicode, les points de vue, les quantificateurs possessifs et les groupes non-retourcissants sont absents, mais le reste de ce que j'ai mentionné pour Java est présent également dans JS.
La syntaxe de la regex de Python est également basée sur Perl 5, avec des quantificateurs non gourmands, la plupart des JAVA.UTIL.REGEX La bibliothèque utilise une syntaxe très fortement basée sur Perl (env. Version 5.8) Regex, y compris les règles d'échappement, le \ p et \ p classes unicode, quantifiers non gourmands et "possessifs", arrière-plan, \ q .. \ e citant et plusieurs des (? ...) Constructs, y compris des groupes non capturants, des regards lookahead zéro-largeur / derrière et des groupes non-retournant. En fait, Java Regex semble avoir plus en commun avec Perl Regexes que libpcre. :)
(? ...) Constructs, y compris des groupes non capturants, des modèles d'aspect / derrière et de motif conditionnel , ainsi que des groupes de capture nommés (mais avec une syntaxe différente de la Perl ou PCRE). Les groupes non rétro-écaillants et les quantifiers «possessifs» sont (autant que je puisse le voir) absent, de même que les \ p et \ p classes de caractères Unicode, bien que le code standard \ d , \ s et \ w Les classes sont au courant de l'Unicode si demandé.
Merci. J'ai clarifié ma question à montrer que je suis intéressé par les fonctionnalités que Java 1.6 ne prend pas en charge
Perl, Python, .Net, libpcre. Ce sont les seules implémentations que je connaisse de ce soutien aux groupes de capture nommés.
En fait de nombreuses extensions de Python travailleront sur les Perl modernes.
Je ... je me demande si [PCRE] est susceptible de devenir une approche de facto dans toutes les langues principales (je suis intéressé par Java).
Cela appelle à la spéculation, mais je pense que la réponse est "non" ... dans le cas de Java. Je fond sur le fait que je ne pouvais pas trouver aucun la mise en œuvre PCRE pour Java.
S'il y avait un réel besoin / demande de pcre dans Java, j'aurais attendu qu'il y ait plus de bibliothèques là-bas.
mise à jour Depuis que j'ai écrit la réponse originale, plus de personnes / groupes ont mis en œuvre des bibliothèques Java qui fournissent (ou prétendent fournir) les regex compatibles PCRE.
Et évidemment, l'équipe Java peut (et a) Ajoutez des fonctionnalités de PERL au soutien de Java's Regex au fil du temps. Par exemple, des groupes de capture nommés ont été ajoutés dans Java 7.
Mais la compatibilité PCRE complète ne semble pas être un objectif de haute priorité pour l'équipe Java. Par exemple:
- https://bugs.openjdk.java.net/browse/jdk-8027651
- https://bugs.java.com/bugdatabase/view_bug.do ? bug_id = 8258119
et étant donné que la compatibilité complète briserait probablement un sous-ensemble d'applications Java existantes, je pense toujours que la réponse est non.
Cela semble beaucoup comme un "est x la seule voie vraie !?" genre de question. PCRE a de nombreuses lacunes, dont la plus évidente est la complexité et l'utilité douteuse. Est-ce rarement existant une seule façon vraie pour quoi que ce soit, et dans le domaine des bibliothèques réégygogènes, PCRE ne l'est certainement pas.
Perl Les expressions régulières sont des déchets absolus à mon avis. Une fois que vous avez beaucoup au-delà de l'ensemble de fonctionnalités proposé par Posix Extended Regexps (ERE), vous pouvez également utiliser quelque chose comme une implémentation de PEG. La seule raison pour laquelle PCRE est utilisé si largement utilisé est qu'il est facile pour les gens de résoudre un problème en laissant tomber dans une bibliothèque.
Essayez de faire une scission de cette correspondance:
(?:
(?:'[\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
Vous pouvez ajouter le drapeau / x à l'intérieur du Re en le démarrant avec (? X:
C'est une question ancienne, mais pour le mettre à jour, Java 7 a ajouté des groupes de capture nommés.