regexpr "variables" ?

Le
kurtz_le_pirate
bonjour,


soit la ligne de donnees :
<Auteur><Larry Wall><Developpeurs><The Perl Foundation>

la regexpr /<(.*?)><(.*?)><(.*?)><(.*?)>/ capture bien les 4 "elements".
la regexpr /<(.*?)><(.*?)><(.*?)>/ capture bien les 3 "elements".
donc s'il y a moins de mofifs de recheche que de donnees, cela fonctionne.


à l'inverse, si on applique 5 motifs /<(.*?)><(.*?)><(.*?)><(.*?)><(.*?)>/
et qui n'y a que 4 elements dans les donnees, je pensais que les $1 à $4
seraient remplis et que $5 serait à vide, ou undef, ou mais non, il n'y
a *aucune* capture.


je rève peut être, mais existe-t-il un moyen pour avoir un nombre "variable"
de motifs ?


--
klp
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
luc2
Le #22321321
Le 02-07-2010, kurtz_le_pirate
je pensais que les $1 à $4 seraient remplis et que $5 serait à vide,
ou undef, ou ... mais non, il n'y a *aucune* capture.



crame !

je rève peut être, mais existe-t-il un moyen pour avoir un nombre
"variable" de motifs ?



la botte supreme de la grande ourse :

my @captures = $la_chaine =~ /<([^>]*)>/g;
espie
Le #22321841
In article luc2
Le 02-07-2010, kurtz_le_pirate
je pensais que les $1 à $4 seraient remplis et que $5 serait à vide,
ou undef, ou ... mais non, il n'y a *aucune* capture.



crame !

je rève peut être, mais existe-t-il un moyen pour avoir un nombre
"variable" de motifs ?



la botte supreme de la grande ourse :

my @captures = $la_chaine =~ /<([^>]*)>/g;



Visiblement, tu ne connais pas *?
De ce point de vue, c'est une regression par rapport au post initial.

Visiblement egalement, aucun de vous n'a lu en detail la doc des regexp,
qui pourtant explique bien que n'importe quel caractere bizarre peut
(aujourd'hui ou demain) avoir une semantique particuliere, et donc qu'il
*faut* user abondamment de ...

my @captures = $la_chaine =~ /
Notons que c'est pas forcement genial parce que tout ce qui traine au milieu
va etre ignore, genre: bruit<valeur>bruit<valeur2>bruit

Mais ca par contre, je ne vois pas de facon simple de gerer avec juste de la
regexp...

On peut facilement couper avec split:
my @captures = split /(?<=>)(?=<)/, $chaine;
et ensuite verifier que chaque capture marche.
@captures = map {/^<([^>]*)>$/ or die "Badly formed string: $chaine ($_)"; $1; } @captures;
luc2
Le #22322121
Le 02-07-2010, Marc Espie
Visiblement, tu ne connais pas *?
...

Visiblement egalement, aucun de vous n'a lu en detail la doc des regexp,
...



visiblement, tu t'prends pas pour la moitie d'un naze toi :)
Olivier Miakinen
Le #22322151
Bonjour,

Je fais suivre ta question et ma réponse vers fr.comp.lang.regexp car
elles devraient intéresser tous les utilisateurs des regexp et pas
seulement ceux de Perl.

Le 02/07/2010 09:07, kurtz_le_pirate a écrit :

soit la ligne de donnees :
<Auteur><Larry Wall><Developpeurs><The Perl Foundation>

la regexpr / la regexpr / donc s'il y a moins de mofifs de recheche que de donnees, cela fonctionne.

à l'inverse, si on applique 5 motifs / et qui n'y a que 4 elements dans les donnees, je pensais que les $1 à $4
seraient remplis et que $5 serait à vide, ou undef, ou ... mais non, il n'y
a *aucune* capture.



Dans PCRE il existe une option PCRE_PARTIAL permettant de vérifier une
regexp sur une chaîne incomplète, mais celle-ci n'existe pas dans Perl.

je rève peut être, mais existe-t-il un moyen pour avoir un nombre "variable"
de motifs ?



Oui : /
Maintenant, si tu veux que ça soit variable à l'infini (un truc qui
créerait autant de $n que nécessaire), je ne crois pas que ça soit
possible.

Cordialement,
--
Olivier Miakinen
Olivier Miakinen
Le #22322301
Le 02/07/2010 12:11, Marc Espie a écrit :

my @captures = $la_chaine =~ /<([^>]*)>/g;



Visiblement, tu ne connais pas *?
De ce point de vue, c'est une regression par rapport au post initial.

Visiblement egalement, aucun de vous n'a lu en detail la doc des regexp,
qui pourtant explique bien que n'importe quel caractere bizarre peut
(aujourd'hui ou demain) avoir une semantique particuliere, et donc qu'il
*faut* user abondamment de ...

my @captures = $la_chaine =~ /


Ça aussi ça me semble être une régression : j'aurais préféré que les
options à venir se contentent de constructions du style (?#...) (où
« # » représente un caractère non encore utilisé), ou bien justement
utilisent le pour les nouvelles constructions.

Mébon, c'est comme ça, il faut faire avec.

Notons que c'est pas forcement genial parce que tout ce qui traine au milieu
va etre ignore, genre: bruit<valeur>bruit<valeur2>bruit

Mais ca par contre, je ne vois pas de facon simple de gerer avec juste de la
regexp...



Peut-être en deux étapes.

Commencer par récupérer la plus longue chaîne possible sans bruit :
/< ( [^<>] | >< )* >/x

Puis appliquer la regexp simple sur le résultat :
/
Jerome Quelin
Le #22325591
Marc Espie wrote:
Visiblement egalement, aucun de vous n'a lu en detail la doc des regexp,



visiblement surtout, aucun de vous ne sait qu'il ne faut pas utiliser les
regexp pour parser du xml.

perldoc -q xml

jérôme
--

espie
Le #22325911
In article Jerome Quelin
Marc Espie wrote:
Visiblement egalement, aucun de vous n'a lu en detail la doc des regexp,



visiblement surtout, aucun de vous ne sait qu'il ne faut pas utiliser les
regexp pour parser du xml.

perldoc -q xml



L'exemple donné n'est pas techniquement du xml... aucun tag de fin, par
exemple.

L'air de rien, c'est une des debilites de la tendance "tout xml" des neuneus
bouffeurs de java: faut des outils specifiques, ca se parse pas a coups de
regexps... et toutes les bibliotheques existantes sont trouees, de facon
plus ou moins subtiles (la plupart supposent que les fichiers consideres
sont "gentils", et donc ne prennent pas de precaution particuliere pour
limiter les niveaux de recursion, quand c'est pas carrement la partie utf8
qui cree des buffer overflows...)
Olivier Miakinen
Le #22326201
Bonjour,

Le 03/07/2010 17:23, Jerome Quelin a écrit :

visiblement surtout, aucun de vous ne sait qu'il ne faut pas utiliser les
regexp pour parser du xml.



Je suis le premier à dire que les regexp ne peuvent pas tout, et qu'il
faut savoir utiliser un vrai parseur dès que ça devient un tant soit peu
complexe.

Mais je ne vois pas ce qui te fait dire, à partir de la seule ligne de
données « <Auteur><Larry Wall><Developpeurs><The Perl Foundation> »,
qu'il s'agirait d'un document XML -- sans même parler de complexité.

Cordialement,
--
Olivier Miakinen
Jerome Quelin
Le #22330851
Olivier Miakinen wrote:

Le 03/07/2010 17:23, Jerome Quelin a écrit :
visiblement surtout, aucun de vous ne sait qu'il ne faut pas utiliser les
regexp pour parser du xml.



Je suis le premier à dire que les regexp ne peuvent pas tout, et qu'il
faut savoir utiliser un vrai parseur dès que ça devient un tant soit peu
complexe.

Mais je ne vois pas ce qui te fait dire, à partir de la seule ligne de
données « <Auteur><Larry Wall><Developpeurs><The Perl Foundation> »,
qu'il s'agirait d'un document XML -- sans même parler de complexité.



parce que tout code monstrueux n'est qu'un petit script qui n'a pas-besoin-
d'un-vrai-parser-parce-que-regarde-les-données-sont-super-simples-et-promis-
ce-ne-sera-jamais-plus-compliqué-que-cela qui a évolué et accumulé des tas
de modifs pour prendre en compte de nouveaux cas dans les données en entrée.

et quand on se rend compte que le script est monstrueux, il est trop tard
pour le reprendre sainement, car on aura peur de tout casser et qu'après
tout, ça marche comme ça.

d'autre part, sur du markup avec des <>, la plupart du temps c'est du xml.
si c'est juste des valeurs comme ça sur une seule ligne, le standard c'est
csv. donc je ne pense pas trop m'avancer en disant que l'exemple original
est tiré d'un document xml.

jérôme
--

xavier
Le #22330911
Jerome Quelin
parce que tout code monstrueux n'est qu'un petit script qui n'a pas-besoin-
d'un-vrai-parser-parce-que-regarde-les-données-sont-super-simples-et-promis-
ce-ne-sera-jamais-plus-compliqué-que-cela qui a évolué et accumulé des tas
de modifs pour prendre en compte de nouveaux cas dans les données en entrée.

et quand on se rend compte que le script est monstrueux, il est trop tard
pour le reprendre sainement, car on aura peur de tout casser et qu'après
tout, ça marche comme ça.



Ca sent le vécu :-) Mais je crois qu'on a tous vécu ça à un moment où à
un autre...

--
XAv - recasé
Publicité
Poster une réponse
Anonyme