Aide Expression régulière

Bonjour,

J'ai un problème avec une expression régulière.

Je voudrait récupérer une balise html "<a>". Voici la chaine qui me sert pour mon test unitaire :

Citation:

---

String html = "coucou <a xxxxxxxxxaxxxxxxxxx /a> fdsfldsjfdlsk";

---

Voici mon pattern :

Citation:

---

this.patternALink = Pattern.compile("<a [^(/a>)]+");

---

Voici le résultat qui m'est retourné :

Citation:

---

<a xxxxxxxxx

---

Le programme est bloqué par le premier "a", Je n'arrive pas à trouver l'expression régulière pour "prend tous les caractère suivante sauf si c'est suivi de / puis de a puis de >" . (il fait un OU)

Merci !
Stéphane

Tout simplement ceci, devrait marcher

Code:

---

<a(.*?)/a>

---

La signification de l'expression régulière est : "Capture ce qui commence par '<a ' et les caractères qui se suivent sauf l'un des suivants '(', '/', 'a', '>' ou ')'

Je tenterai un truc du genre

Code:

---

Pattern.compile("<\\s*a(.+?)<\\s*/\\s*a\\s*>")

---

EDIT : Comme je me suis fait griller j'améliore :p

J'ai testé les deux fonctionnent .
Tu t'es fait griller, mais tu gère les espaces donc c'est encore mieux :)
Merci à tout les deux .

pour info, il est interdit de mettre un espace entre < et a justement. pareil entre le / et le a. Par contre, effectivement, on peux en mettre un entre a et > :mouarf:

Donc je corrige aussi

Code:

---

Pattern.compile("<a(.+?)</a\\s*>")

---

En effet tchize_, ta solution est meilleurs !

Je vous avoue, j'ai du mal à comprendre le sens du point d'interrogation.

Merci beaucoup !
Stéphane

mis derrière un + ou un *, cela signifie qu'on fait un capture réticente. On prend le moins de caractère possible. Ca évite d'englober /a> dans le ".+". Si on ne l'avais pas mis, et qu'on avait

Code:

---

<a href="blabla">blabla</a><a href="blibli">blibli</a>

---

le .+ correspondrais à

Code:

---

href="blabla">blabla</a><a href="blibli">blibli<

---

alors qu'avec le .+? ca correspond à

Code:

---

href="blabla">blabla<

---

et

Code:

---

href="blibli">blibli<

---

Merci ! :)

Je profites de ce sujet pour demander quel est le comportement exact du "Possessive quantifier" ?

Idem pour

Code:

---

1 2 3 4 5 6 7

Special constructs (non-capturing) (?=X) X, via zero-width positive lookahead (?!X) X, via zero-width negative lookahead (?<=X) X, via zero-width positive lookbehind (?<!X) X, via zero-width negative lookbehind (?>X) X, as an independent, non-capturing group

---

Ces quatre expressions ne capturent pas X et en plus laissent X disponibles pour la suite du matche (zero-width). Il y a parfois un équivalent plus simple a écrire, mais qui ne laisse pas X disponible, et que je met à coté
Y(?=X) recherche les Y qui sont suivi de X :arrow: YX
Y(?!X) recherche les Y qui ne sont pas suivi de X
(?<=X)Y recherche les Y immédiatement précédés de X :arrow: XY
(?<!X)Y recherche les Y non immédiatement précédé de X



(?>X) est un peu plus compliqué à expliqué. Concrètement il est "indépendant", ca veux dire "atomique", ca veux dire qu'une fois sorti de ce groupe les informations de backtracking sont perdues. Copncretement ça veux dire que la regexp ne peux pas revenir en arrière, diminuer la taille d'une capture de type Z* ou Z+ par exemple ou essayer une alternative. Exemple concret tiré de ce site

soit les expressions régulières a(bc|b)c et a(?>bc|b)c. Les deux vont matcher "abcc" mais la deuxième ne matchera pas "abc". Explication

a(bc|b)c a(?>bc|b)c abc abc
a(bc|b)c a(?>bc|b)c abc abc
a(bc|b)c a(?>bc|b)c abc abc
a(bc|b)c a(?>bc|b)c abc abc
Là personne ne peux plus matcher. L'atomique est coincé (il ne libèrera pas bc), donc on fini ainsi. L'autre va revenir en arrière pour essayer l'alternative
a(bc|b)c a(?>bc|b)c abc abc
a(bc|b)c a(?>bc|b)c abc abc

L'utilisation de ce genre de chose est de fait assez rare :aie:

Ok merci pour cette explication même s'il va falloir que passe quelques minutes à lire ^_^
En tout cas j'ai bien fait de poser la question car j'ai déjà eu des problèmes à matcher certaines chaînes justement car il me manquait ce genre d'opérateurs (enfin disons que j'ai réussi mais je veux pas être celui qui devra débugger l'expression régulière).

Je posterai peut-être un sujet sur un problème qu'on nous a demandé de régler via une expression régulière mais celle que j'ai écrite bug dans des cas précis.

Citation:

---

Envoyé par Nemek

je veux pas être celui qui devra débugger l'expression régulière

---

Je crois que personne n'aime débugge les expression régulières, c'est un peu comme le perl :mouarf: