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 ?
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.
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.
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.
Bof, bof, bof. Quelle que soit la question, xml n'est jamais la bonne reponse. La reponse facile, oui. Mais la bonne, non.
Nicolas George
Marc Espie wrote in message <i0t5q7$12rp$:
Bof, bof, bof. Quelle que soit la question, xml n'est jamais la bonne reponse. La reponse facile, oui. Mais la bonne, non.
La bonne réponse est souvent la réponse facile, pourtant.
XML a l'avantage d'avoir un mécanisme d'échappement complet, fiable et régulier pour les chaînes de caractères (donc on ne se demande pas s'il faut écrire ", ou '' ou que sais-je), c'est déjà un plus considérable par rapport à la plupart des formats bricolés vite fait.
Marc Espie wrote in message <i0t5q7$12rp$1@saria.nerim.net>:
Bof, bof, bof. Quelle que soit la question, xml n'est jamais la bonne reponse.
La reponse facile, oui. Mais la bonne, non.
La bonne réponse est souvent la réponse facile, pourtant.
XML a l'avantage d'avoir un mécanisme d'échappement complet, fiable et
régulier pour les chaînes de caractères (donc on ne se demande pas s'il faut
écrire ", ou '' ou que sais-je), c'est déjà un plus considérable par
rapport à la plupart des formats bricolés vite fait.
Bof, bof, bof. Quelle que soit la question, xml n'est jamais la bonne reponse. La reponse facile, oui. Mais la bonne, non.
La bonne réponse est souvent la réponse facile, pourtant.
XML a l'avantage d'avoir un mécanisme d'échappement complet, fiable et régulier pour les chaînes de caractères (donc on ne se demande pas s'il faut écrire ", ou '' ou que sais-je), c'est déjà un plus considérable par rapport à la plupart des formats bricolés vite fait.
Olivier Miakinen
Le 05/07/2010 19:15, Jerome Quelin a écrit :
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.
Comme te l'a répondu Xavier, ça sent le vécu. ;-)
Mais...
d'autre part, sur du markup avec des <>, la plupart du temps c'est du xml.
... comme l'a écrit Nicolas, ce n'est pas du XML bien formé.
Pour que c'en soit, au lieu de : <Auteur><Larry Wall><Developpeurs><The Perl Foundation> il aurait fallu par exemple : <Auteur>Larry Wall</Auteur><Developpeurs>The Perl Foundation</Developpeurs>
Et dans ce cas, tu peux être certain que j'aurais déconseillé les regexp.
Cordialement, -- Olivier Miakinen
Le 05/07/2010 19:15, Jerome Quelin a écrit :
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.
Comme te l'a répondu Xavier, ça sent le vécu. ;-)
Mais...
d'autre part, sur du markup avec des <>, la plupart du temps c'est du xml.
... comme l'a écrit Nicolas, ce n'est pas du XML bien formé.
Pour que c'en soit, au lieu de :
<Auteur><Larry Wall><Developpeurs><The Perl Foundation>
il aurait fallu par exemple :
<Auteur>Larry Wall</Auteur><Developpeurs>The Perl
Foundation</Developpeurs>
Et dans ce cas, tu peux être certain que j'aurais déconseillé les regexp.
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.
Comme te l'a répondu Xavier, ça sent le vécu. ;-)
Mais...
d'autre part, sur du markup avec des <>, la plupart du temps c'est du xml.
... comme l'a écrit Nicolas, ce n'est pas du XML bien formé.
Pour que c'en soit, au lieu de : <Auteur><Larry Wall><Developpeurs><The Perl Foundation> il aurait fallu par exemple : <Auteur>Larry Wall</Auteur><Developpeurs>The Perl Foundation</Developpeurs>
Et dans ce cas, tu peux être certain que j'aurais déconseillé les regexp.
