gestion des raccourcis

Le 09/01/2009 16:58, SAM a écrit :

<http://stephane.moriaux.pagesperso-orange.fr/truc/js_regexp_test>

Tu avais écrit :
(?:>)[ w_.:+,;0-9]+(?:<)

Oui.

On peut déjà commencer par virer les inutiles :
(?:>)[ w_.:+,;0-9]+(?:<)

Je croyais que le point remplaçait n'importe quel caractère !
Comment se fait-ce qu'il ne faille pas l'échapper ici ?

Le point remplace n'importe quel caractère (sauf les sauts de
ligne quand on n'a pas mis l'option /s) *en dehors d'une classe
de caractères*.

Dans une classe de caractères, les seuls caractères spéciaux sont :
(comme d'hab)
^ (seulement si c'est le premier caractère)
- (sauf au début ou à la fin)
[ (seulement s'il est suivi par une syntaxe POSIX du style [:alpha:])
] (sauf au début)

Il est donc parfaitement inutile d'échapper un . (ou un +).

Remplaçons le test non capturant du début par une assertion positive
arrière :
(?<=>)[ w_.:+,;0-9]+(?=<)
Résultat :
(vide)

Eh oui !
(ne figure pas ici
:<https://developer.mozilla.org/index.php?title=Fr/R%C3%A9f%C3%A9rence_de_JavaScript_1.5_Core:Objets_globaux:RegExp>
)

Pourtant, le standard ECMA-262 spécifie que les RegExp de JavaScript
sont basées sur Perl 5, lequel supporte aussi bien les assertions en
arrière que les assertions en avant.

Mais je viens de trouver ceci :
<http://www.regular-expressions.info/lookaround.html#limitbehind>
Finally, flavors like JavaScript, Ruby and Tcl do not support lookbehind
at all, even though they do support lookahead.
</>

Et alors, pour finir, qu'est-ce qu'un test "non capturant" ?
puisque : (?:>)
conserve le >

Eh bien (?:xxx) est strictement identique à xxx, dans la mesure où il ne
met rien dans RegExp.$1, RegExp.$2, etc. Je précisais « non capturant »
parce que par défaut les parenthèses sont caputurantes : (xxx).

on peut faire plus malin :
[^<>]*w[^<>]*(?=<)

Boudiou !
Outre que j'ai cherché depuis mon postage sans trouver ce sioux là,
je n'ai pas réussi à faire fonctionner le "Regulator"
et ... quoi? quoi? quoi ?
- je commence pas ne pas vouloir < ni > (0 fois ou plus)
je m'étais contenté de [^s>]
- puis je veux tous les alphanumériques et le _
bon, ok
- ensuite je ne reveux pas < ni >
ben non! pour sûr (mais, à mon idée ça ne sert à rien puisque suite)
- le tout à condition de ne pas être suivi par un <
J'ai beau arriver à lire (du moins pense-je) je ne vois pas ce que c'est
censé faire (même si je vois ce que ça fait)

Le test ci-dessus est censé récupérer toute chaîne de caractères ne
contenant ni < ni > mais contenant au moins une lettre, et suivie
par un caractère < (lequel ne sera pas retourné). Pour supprimer la
condition « contenant au moins une lettre », il suffit d'écrire :
[^<>]*(?=<)
Ou bien (si on veut ignorer les chaînes vides) :
[^<>]+(?=<)

Résultat :
Pour les programmeurs
Version 0.6

tu arrives comme ça à attraper 'test_06.zip' qui m'échappait
mais les ligne-retours et tabulations sont conservées
Je n'arrive pas à les supprimer, ça me tue ! :-(

Voyons voir.

On veut donc une chaîne qui commence et qui finit par un caractère autre
qu'un chevron ou une espace :
[^<>s]

Cette chaîne peut contenir autant de caractères que l'on veut autres que
des chevrons, mais pouvant être des espaces :
[^<>]*

Cela donne donc :
[^<>s][^<>]*[^<>s]

Pour faire bonne mesure, on veut s'assurer que, éventuellement après des
espaces, on trouvera forcément un chevron ouvrant :
(?=s*<)

Au final, cela donne :
[^<>s][^<>]*[^<>s](?=s*<)
Résultat :
Pour les programmeurs
Version 0.6
Quelques +, pour voir : + + ++++ +
Sources version 0.6:
test_06.zip
(59 Kb)
Sources version 0.7:
test_07.zip
(59 Kb)
Sources version 0.8:
test_08.zip
(259 Kb)

C'est déjà pas mal, mais ce test n'est pas parfait, car si une chaîne
est constituée d'un seul caractère non blanc elle ne sera pas trouvée.

Pour corriger ce bug, on va dire que la séquence « [^<>]*[^<>s] » est
optionnelle :
([^<>]*[^<>s])?
Donc :
[^<>s]([^<>]*[^<>s])?(?=s*<)

Et comme on n'a pas besoin que les parenthèses ajoutées soient
capturantes, on peut remplacer « ( » par « (?: » :
[^<>s](?:[^<>]*[^<>s])?(?=s*<)

Ça te plaît ? ;-)

Mais en revanche je ne suis pas sûr que l'expression qui suit ne
pourrait pas accepter un « » au lieu d'un « + » :

6) var re = /^[+]$/;

ça donne 'null' sur ma démo

Ha! Ben ? normal, le string de test n'était pas '+' tout seul :-(

Oui, bien sûr. Mais comme tu as laissé la possibilité de modifié la
chaîne de test, j'en ai profité pour tester « + » tout seul ainsi que
« » tout seul. C'est exactement le genre de programme test que je
voulais faire mais que je n'ai pas fait faute de temps.

Sur ma démo mise à '+' cette fois,
y fonctionnent :
^[+]$
ou (ton équivalence) :
^[+]$

... ce qui prouve bien que le est inutile dans [+].

ou même directement :
^+$

Oui. Et là, le est indispensable.

Le 09/01/2009 18:29, je répondais à SAM :

mais les ligne-retours et tabulations sont conservées
Je n'arrive pas à les supprimer, ça me tue ! :-(

[...]

[^<>s](?:[^<>]*[^<>s])?(?=s*<)

Yeah ! Yeah ! Yeah ! Je viens de trouver une expression plus simple et
plus courte pour faire la même chose !

Je pars d'une expression dans laquelle j'ai supprimé le test que le
premier caractère est différent d'un chevron ou d'un blanc. Du coup,
le test des autres caractères n'est plus optionnel :
[^<>]*[^<>s](?=s*<)
Résultat :
Pour les programmeurs
Version 0.6
Quelques +, pour voir : + + ++++ +
a
Sources version 0.6:

test_06.zip
(59 Kb)
Sources version 0.7:
test_07.zip
(59 Kb)
Sources version 0.8:
test_08.zip
(259 Kb)

Maintenant, il ne me reste plus qu'à ajouter une assertion négative pour
interdire au premier caractère d'être un blanc :
(?!s)
Donc :
(?!s)[^<>]*[^<>s](?=s*<)
Résultat :
Pour les programmeurs
Version 0.6
Quelques +, pour voir : + + ++++ +
a
Sources version 0.6:
test_06.zip
(59 Kb)
Sources version 0.7:
test_07.zip
(59 Kb)
Sources version 0.8:
test_08.zip
(259 Kb)

Joli, non ? Et si les assertions en arrière étaient permises dans
JavaScript on pourrait même écrire :
(?!s)[^<>]+(?<!s)(?=s*<)
ou :
(?!s)[^<>]+(?=s*<)(?<!s)

Le 1/9/09 6:29 PM, Olivier Miakinen a écrit :

Le 09/01/2009 16:58, SAM a écrit :

<http://stephane.moriaux.pagesperso-orange.fr/truc/js_regexp_test>

Tu avais écrit :
(?:>)[ w_.:+,;0-9]+(?:<)

Oui.

On peut déjà commencer par virer les inutiles :
(?:>)[ w_.:+,;0-9]+(?:<)

Je croyais que le point remplaçait n'importe quel caractère !
Comment se fait-ce qu'il ne faille pas l'échapper ici ?

Le point remplace n'importe quel caractère (sauf les sauts de
ligne quand on n'a pas mis l'option /s) *en dehors d'une classe
de caractères*.

Mékesskecé ça une "classe de caractères" ?

Dans une classe de caractères, les seuls caractères spéciaux sont :

je comprends que c'est ce qu'il y a entre [ et ]
banania ?

(comme d'hab)
^ (seulement si c'est le premier caractère)
- (sauf au début ou à la fin)
[ (seulement s'il est suivi par une syntaxe POSIX du style [:alpha:])
] (sauf au début)

Il est donc parfaitement inutile d'échapper un . (ou un +).

(...)

Pourtant, le standard ECMA-262 spécifie que les RegExp de JavaScript
sont basées sur Perl 5, lequel supporte aussi bien les assertions en
arrière que les assertions en avant.

Mais je viens de trouver ceci :
<http://www.regular-expressions.info/lookaround.html#limitbehind>

Il a l'air bien ce site, j'y ai trouvé ce qu'est une classe :
<http://www.regular-expressions.info/charclass.html>
dommage qu'il ne cause pas français.

Finally, flavors like JavaScript, Ruby and Tcl do not support lookbehind
at all, even though they do support lookahead.
</>

Et alors, pour finir, qu'est-ce qu'un test "non capturant" ?
puisque : (?:>)
conserve le >

Eh bien (?:xxx) est strictement identique à xxx, dans la mesure où il ne
met rien dans RegExp.$1, RegExp.$2, etc.

Ha? ça se joue comme ça ?
Médonc, si on ne précise rien, on ne devrait récupérer que le 2ième
groupe de (), non ?

javascript:'trucmuche'.replace(/(?:m)(w+)/,'oche')
-> trucmoche non? ...
non : trucoche :-(

En fait on capture bien le 'm' mais on ne le garde pas et même on le
jette aux orties.
C'est un peu tordu comme appellation ça "non capturant"
Moi je voyais que puisqu'on ne le gardait pas (capturait pas), il
restait à sa place.

Je précisais « non capturant »

tt le monde semble appeler ça comme ça, sauf que là, à mon idée, ça ne
fonctionne pas comme ça laisse l'entendre.

javascript:'trucmuche'.match(/(?:m)w+/)
-> muche, uche
donc c'est gardé oui, gardé non ... ?

alors je dois faire :
javascript:with('trucmuche'){replace(match(/(?:m)w+/)[1],'oche')}
pour enfin obtenir : 'trucmoche'
:-(

[^<>]*w[^<>]*(?=<)

Boudiou !
J'ai beau arriver à lire (du moins pense-je) je ne vois pas ce que c'est
censé faire (même si je vois ce que ça fait)

Le test ci-dessus est censé récupérer toute chaîne de caractères ne
contenant ni < ni > mais contenant au moins une lettre, et suivie
par un caractère < (lequel ne sera pas retourné). Pour supprimer la
condition « contenant au moins une lettre », il suffit d'écrire :
[^<>]*(?=<)
Ou bien (si on veut ignorer les chaînes vides) :
[^<>]+(?=<)

Là je vois mieux (et d'ailleurs le résultat n'est pas si mauvais)

Voyons voir.

On veut donc une chaîne qui commence et qui finit

Où ça : commence et finit ?

par un caractère autre qu'un chevron ou une espace :
[^<>s]

Cette chaîne peut contenir autant de caractères que l'on veut autres que
des chevrons, mais pouvant être des espaces :
[^<>]*

Cela donne donc :
[^<>s][^<>]*[^<>s]

ha! voilà les début et fin

Pour faire bonne mesure, on veut s'assurer que, éventuellement après des
espaces, on trouvera forcément un chevron ouvrant :
(?=s*<)

Au final, cela donne :
[^<>s][^<>]*[^<>s](?=s*<)

(...)

C'est déjà pas mal, mais ce test n'est pas parfait, car si une chaîne
est constituée d'un seul caractère non blanc elle ne sera pas trouvée.

Peut-être ? c'est toi qui voit ;-) moi, j'essaie seulement de suivre !
Perso, pour un caractère ... ma foi ... j'aurais fait l'impasse.
Surtout que je n'ai pas vu qu'un seul caractère n'était pas possible :-(

Pour corriger ce bug, on va dire que la séquence « [^<>]*[^<>s] » est
optionnelle :

J'ai déjà oublié ce que faisait cette séquence !

([^<>]*[^<>s])?
Donc :
[^<>s]([^<>]*[^<>s])?(?=s*<)

Et comme on n'a pas besoin que les parenthèses ajoutées soient
capturantes, on peut remplacer « ( » par « (?: » :
[^<>s](?:[^<>]*[^<>s])?(?=s*<)

Ça te plaît ? ;-)

:-)

C'est exactement le genre de programme test que je
voulais faire mais que je n'ai pas fait faute de temps.

Tiens, je l'ai un peu complété :
<http://stephane.moriaux.pagesperso-orange.fr/truc/js_regexp_testeur>
et y ai mis l'expression que tu donnes dans ton post suivant.


--
sm

Salut !

Je ne réponds pas aux questions que tu t'es posées avant de trouver
toi-même la réponse : si cela peut te rassurer, oui, tu as bien tout
compris.

Je répondrai juste à la question de ce que sont les parenthèses
capturantes en prenant l'exemple de <http://www.pcre.org/pcre.txt>
(sous le titre SUBPATTERNS), à savoir la règle suivante :
/the ((red|white) (king|queen))/

Cette règle valide chacune des quatre chaînes suivantes :
"the red king"
"the red queen"
"the white king"
"the white queen"

Supposons que la chaîne soit :
"the red king"

L'expression rationnelle retourne non seulement le résultat complet
"the red king", mais aussi trois « subpatterns » correspondant à chacune
des paires de parenthèses. En l'occurrence, il s'agit de :
$1 = "red king"
$2 = "red"
$3 = "king"

Supposons maintenant que l'on change l'expression pour la suivante :
/the ((?:red|white) (king|queen))/

Le résultat global sera toujours exactement le même :
"the red king"

En revanche, les « subpatterns » seront :
$1 = "red king"
$2 = "king"

On peut compliquer le résultat à loisir :
/((t)(?:h)(e)) (?:(?:red|white)( ((king|queen))))/

Ici, les « subpatterns » seront :
$1 = "the"
$2 = "t"
$3 = "e"
$4 = " king"
$5 = "king"
$6 = "king"

Et pourtant, le résultat global sera toujours, invariablement :
"the red king"

Ceci devrait répondre à tes questions à propos des replace(), dans
lesquels tu croyais que les parenthèses capturantes devaient capturer
ou non des caractères dans le résultat global : non, ça ne change
strictement rien au motif validé par l'expression rationnelle complète.

---------------------------------------------------------------------

Pendant qu'on y est, je signale que ces parenthèses capturantes peuvent
être très pratiques grâce aux « références arrières ». Je m'explique.
Supposons qu'on veuille reconnaître l'une des deux chaînes suivantes :
soit "the red king and the red queen" ;
soit "the white king and the white queen" ;
et *aucune* autre.

L'expression /the (red|white) king and the (red|white) queen/ ne
fonctionne pas, car elle trouvera aussi la chaîne suivante, dont on
ne veut pas :
"the red king and the white queen"

En revanche, l'expression suivante fonctionne :
/the (red|white) king and the 1 queen/

En effet, le 1 prend comme valeur le contenu de la première paire de
parenthèses capturantes (et la seule dans cet exemple).

Je remets ton lien pour tester :
http://stephane.moriaux.pagesperso-orange.fr/truc/js_regexp_testeur

---------------------------------------------------------------------

Exercice pour le lecteur : quelles sont les chaînes reconnues par
l'expression suivante ?
/the (red|white) king and the (?!1)(red|white) queen/

Le 1/10/09 10:57 PM, Olivier Miakinen a écrit :

Je remets ton lien pour tester :
http://stephane.moriaux.pagesperso-orange.fr/truc/js_regexp_testeur

En voilà un autre (en plus du PHP déjà donné) :
<http://toutjavascript.com/service/regexp.php>

--
sm

Le 11/01/2009 01:48, SAM a écrit :

<http://toutjavascript.com/service/regexp.php>

C'est très bien. Pour comprendre les parenthèses capturantes, essaye-le
avec l'option « match » (celle en haut à droite, car l'autre fait en
réalité un « search »), et en décochant « recherche globale ».

Le Fri, 09 Jan 2009 14:24:38 +0100, SAM a écrit:

Salut, je profite de ce que tu en parles, j'ai téléchargé un fichier php
d'analyse de regexpr qui utilise aussi le JS :
<http://jack.r.free.fr/download/php/regexp_view.zip> et j'ai finalement
réussi à en faire un peu qque chose.

Oups, en lisant votre fil, je viens de me rendre compte que le fichier
avait pris des vacances lors du changement de moteur du site. Je viens
donc de le remettre et de lui faire une page
http://jack.r.free.fr/index.php?lng=fr&page=regexpview

Si il peut rendre des services à d'autres personnes ...
--
Jack.R

Le 1/10/09 10:57 PM, Olivier Miakinen a écrit :

Salut !

Je ne réponds pas aux questions que tu t'es posées avant de trouver
toi-même la réponse : si cela peut te rassurer, oui, tu as bien tout
compris.

Je répondrai juste à la question de ce que sont les parenthèses

(snip ... le rouge roi)

Ceci devrait répondre à tes questions à propos des replace(), dans
lesquels tu croyais que les parenthèses capturantes devaient capturer
ou non des caractères dans le résultat global : non, ça ne change
strictement rien au motif validé par l'expression rationnelle complète.

Bon et alors comment faire un replace avec le $2 ?
comme pour :
javascript:with('trucmuche'){replace(match(/(?:m)(w+)/)[1],'oche')}

javascript:'trucmuche'.match(/(?:m)(w+)/)
-> muche,uche

javascript:alert('trucmuche'.replace(/(?:m)(w+)/,$2'oche'))
javascript:alert('trucmuche'.replace(/(?:m)(w+)/,'$1 oche'))
-> trucuche oche ???

On me dit qque part (MDC) que les $n ne sont pas acceptés avec les non
capturantes :-(
C'est malin !

---------------------------------------------------------------------

Pendant qu'on y est, je signale que ces parenthèses capturantes peuvent
être très pratiques grâce aux « références arrières ». Je m'explique.
Supposons qu'on veuille reconnaître l'une des deux chaînes suivantes :
soit "the red king and the red queen" ;
soit "the white king and the white queen" ;
et *aucune* autre.

L'expression /the (red|white) king and the (red|white) queen/ ne
fonctionne pas, car elle trouvera aussi la chaîne suivante, dont on
ne veut pas :
"the red king and the white queen"

En revanche, l'expression suivante fonctionne :
/the (red|white) king and the 1 queen/

En effet, le 1 prend comme valeur le contenu de la première paire de
parenthèses capturantes (et la seule dans cet exemple).

Mézoudonc as-tu trouvé cette astuce ?

Je remets ton lien pour tester :
http://stephane.moriaux.pagesperso-orange.fr/truc/js_regexp_testeur

Le "testeur" a encore un peu évolué.

super :
the red kingdom
the white kingdom
the red king and the white queen
avec "the $1 kingdom" en chaine de remplacement

---------------------------------------------------------------------

Exercice pour le lecteur : quelles sont les chaînes reconnues par
l'expression suivante ?
/the (red|white) king and the (?!1)(red|white) queen/

Trop dur !

alors ... on trouve 'red' c'est tout bon
donc 'the red king and the ' seulement si ce n'est pas suivi de 'red'
reste à la ligne 1 : 'red queen' donc pas good
kifkif pour ligne 2 'white' -> 'white queen' -> pas good non plus
je vote pour la ligne 3


Va m'falloir ajouter tous ces exos à ma liste de demos :-/

Si jamais qqu'un visite cette page et me pose des questions je te le
renverrai.
Nota : à faire -> rajouter un lien vers Olivier pour tte question ;-)



--
sm

Le 1/11/09 2:04 AM, Olivier Miakinen a écrit :

Le 11/01/2009 01:48, SAM a écrit :

<http://toutjavascript.com/service/regexp.php>

C'est très bien. Pour comprendre les parenthèses capturantes, essaye-le
avec l'option « match » (celle en haut à droite, car l'autre fait en
réalité un « search »), et en décochant « recherche globale ».

Je pense que j'y arrive avec les capturantes.
Ce sont les non capturantes qui à mon sens ne font pas ce qu'il faut.

J'ai d'ailleurs le même pb avec b (limite de mot)
-> pour moi la limite du mot est le blanc à côté et non pas la lettre
d'extrémité. (ce qui, à la réflexion est assez idiot, mébon)

--
sm

Le Sun, 11 Jan 2009 16:35:39 +0100, SAM a écrit:

Le 1/11/09 12:21 PM, Jack.R a écrit :

Le Fri, 09 Jan 2009 14:24:38 +0100, SAM a écrit:

Salut, je profite de ce que tu en parles, j'ai téléchargé un fichier
php d'analyse de regexpr qui utilise aussi le JS :

En fait ... non, ça se passe bien côté serveur donc analysé en php.

Oui, je l'ai écris pour tester ces *!# de regexp afin de les utiliser
dans un script PHP.

http://jack.r.free.fr/index.php?lng=fr&page=regexpview

Si il peut rendre des services à d'autres personnes ...

Il ne manque plus que le consulter en ligne (ce me semble ?).

Comme indiqué sur le site, cela a été codé plutôt façon goret. Il n'y a
par exemple aucun contrôle sur ce qui est récupéré par le formulaire,
d'où la porte ouvert a beaucoup de problèmes sur un serveur publique.

Pour l'exercice proposé par Olivier :

source :
the red king and the red queen
the white king and the white queen
the red king and the white queen

patterns ;
-1: /the (red|white) king and the 1 queen/
-2: /the (red|white) king
and the (?!1)(red|white) queen/

Ça a l'air de fonctionner si l'on met les / d'enfermement, cependant les
1 et (?!1)(red|white) ne sont pas mis en relief ni dans le pattern
result
ni dans le string result

C'est normal, ce qui est mis en évidence correspond aux éléments
capturés. Le 1 correspond à la réutilisation d'une capture précédente
mais n'est pas capturé. Si on le veut aussi, il faut (1).

Il faudra que je rajoute l'affichage de ce qui est récupéré par la regexp.

--
Jack.R
http://jack.r.free.fr