j'en appel à votre aide car je me casse les dents sur StringRegExp j'ai du mal avec les filtres
je cherche à relever toutes les options possibles dans une cascade de maniere générale
par exemple
#include <IE.au3>
#include <String.au3>
#include <Array.au3>
$osource = BinaryToString(InetGet("http://www.meetic.fr/"))
Local $nOffset = 1
Local $array
While 1
$array=StringRegExp($osource,'<option value="(.+?)">(?s) "qui cherche" (?s)</option>',1)
If @error = 0 Then
$nOffset = @extended
Else
ExitLoop
EndIf
For $i = 0 To UBound($array) - 1
MsgBox(0,$i, $array[$i])
Next
WEnd
En fait je souhaites récupérer le 21 le 12 le 22 et le 11 qui sont les values respectives de "une femme qui cherche un homme" ; "un homme qui cherche ..."
PS le script n'a aucun rapport avec meetic : la pub vient juste de passer à la tv c'est pour ça je me suis dit (ah sur ce site il doit y avoir des cascades!
je ne comprend pas trop les (?s) et (.+?) ... c'est surement la ?
Il y a plusieurs exemples de découpe de code-source au regex sur le forum
Le dernier en date est là http://www.autoitscript.fr/forum/viewto ... 503#p79503
Mais il est quand même vivement conseillé d'apprendre un minimum de bases de regex avant de s'y attaquer
Le problème avec le html est que le contenu est terriblement dynamique de nos jours. Certains gros sites sont incapables de fournir deux fois de suite la même page et je ne parle pas ici des pubs aléatoires. Des sites dont le load-balancing est mal goupillé servent des pages fonctionnellement équivalentes mais au contenu distinct.
J'ai connu des sites qui balançaient des tabs, CR, LF et autre palanquées d'espaces à peu près n'importe quand entre les éléments. Comme HTML ignore la plupart des espacements (H et V) ça ne gêne pas l'opération mais les regexps plantent allègrement.
De plus, au moindre changement d'un attribut secondaire (ou de l'ordre des attributs) ça part en vrille...
_IE
La cryptographie d'aujourd'hui c'est le taquin plus l'électricité.
Tout ça est vrai mais reste que si tu veux faire par exemple un test régulier sur une page, _IE c'est terriblement lourd et bandwidthophage ^^
Cela dit si le site est si dynamique que ça les fonctions _IE peuvent aussi avoir des soucis
" L'échec est le fondement de la réussite. " (Lao-Tseu ) " Plus ça rate, plus on a de chances que ça marche " (les Shadoks )
ça a l'air impeccable on est d'accord que [^<]+ considère n'importe quel groupe qu'il contienne des espaces virgules lettres chiffres tirets(-) parenthèses ?
parce que d'après l'aide je conclurais que le ^ ne permet pas de considerer les chiffres, quant au < dans les crochets je n'ai rien trouvé dans l'aide la dessus
Effectivement il faut etre extrement rigoureux mais la syntaxe n'est pas facile a assimiler. Merci de ta patience!
Il y a souvent plusieurs possibilités de syntaxe, certaines meilleures que d'autres ([^<]+) signifie "prend 1 ou plusieurs caractères consécutifs qui ne sont pas <" (s'arrête donc au 1er < rencontré)
Dans ce cas précis c'est donc équivalent à (.+?)< "prend tout jusqu'au 1er < rencontré"
Si tu lis l'anglais tu devrais regarder ce tutoriel : http://www.asiteaboutnothing.net/regex/
" L'échec est le fondement de la réussite. " (Lao-Tseu ) " Plus ça rate, plus on a de chances que ça marche " (les Shadoks )
mikell a écrit :([^<]+) signifie "prend 1 ou plusieurs caractères consécutifs qui ne sont pas <" (s'arrête donc au 1er < rencontré)
Dans ce cas précis c'est donc équivalent à(.+?)< "prend tout jusqu'au 1er < rencontré"
Pas exactement : ils s'agit de faux jumeaux !
([^<]+) s'arrête avant le 1er < ou la fin du sujet. Ici < peut très bien ne pas figurer dans le sujet. (.+?)< s'arrête avant le 1er < (qui doit figurer dans le sujet).
L'identité des résultats n'est garantie ici qu'à la condition qu'il n'y ait pas de fin de ligne dans la valeur capturée. Même si pour ce cas de figure précis on peut penser que cette condition est remplie, il n'en va évidemment pas toujours ainsi.
C'est la sémantique (ce qu'on veut exprimer) qui doit être d'une précision absolue ; la syntaxe n'en est qu'une conséquence.
La cryptographie d'aujourd'hui c'est le taquin plus l'électricité.
mikell a écrit :Dans ce cas précis c'est donc équivalent à ...
Cette précision était of course une mise en garde contre une généralisation de cette expression
Ici l'absence nécessaire de fin de ligne dans la capture est inscrite en filigrane dans l'expression, qui aurait bien sûr demandé d'être tout à fait différente dans un cas contraire
Mais mea culpa effectivement j'aurais dû le préciser, et aussi que le 1er type est plus rapide et économe que le second (bien que ce ne soit pas réellement significatif sur des petits tests comme ça)
" L'échec est le fondement de la réussite. " (Lao-Tseu ) " Plus ça rate, plus on a de chances que ça marche " (les Shadoks )