Ça me semble bien. Ma proposition utilisait des assertions qui ne « consomment » pas les caractères avant et après le test, la tienne les consomme mais les replace ensuite avec $1, $2 et $3.
Ça me semble bien. Ma proposition utilisait des assertions qui ne
« consomment » pas les caractères avant et après le test, la tienne
les consomme mais les replace ensuite avec $1, $2 et $3.
Ça me semble bien. Ma proposition utilisait des assertions qui ne « consomment » pas les caractères avant et après le test, la tienne les consomme mais les replace ensuite avec $1, $2 et $3.
Elegie
Olivier Miakinen wrote:
Hello,
Ça me semble bien. Ma proposition utilisait des assertions qui ne « consomment » pas les caractères avant et après le test, la tienne les consomme mais les replace ensuite avec $1, $2 et $3.
J'avoue ne jamais utiliser ce genre d'assertions, pour des raisons de compatibilité avec les anciennes versions javascript qui en sont dépourvues. Mais lorsque leur emploi est sûr, alors elles peuvent très souvent simplifier la vie du compositeur de regexps, notamment en induisant un raisonnement plus "naturel" dans la construction de l'expression.
En revanche, je crains que vous ne surestimiez quelque peu les capacités du moteur regexp de javascript: seuls (?:), (?=) et (?!) sont supportés par ECMAScript 262/3Ed.
Cheers, Elegie.
Olivier Miakinen wrote:
Hello,
Ça me semble bien. Ma proposition utilisait des assertions qui ne
« consomment » pas les caractères avant et après le test, la tienne
les consomme mais les replace ensuite avec $1, $2 et $3.
J'avoue ne jamais utiliser ce genre d'assertions, pour des raisons de
compatibilité avec les anciennes versions javascript qui en sont
dépourvues. Mais lorsque leur emploi est sûr, alors elles peuvent très
souvent simplifier la vie du compositeur de regexps, notamment en
induisant un raisonnement plus "naturel" dans la construction de
l'expression.
En revanche, je crains que vous ne surestimiez quelque peu les capacités
du moteur regexp de javascript: seuls (?:), (?=) et (?!) sont
supportés par ECMAScript 262/3Ed.
Ça me semble bien. Ma proposition utilisait des assertions qui ne « consomment » pas les caractères avant et après le test, la tienne les consomme mais les replace ensuite avec $1, $2 et $3.
J'avoue ne jamais utiliser ce genre d'assertions, pour des raisons de compatibilité avec les anciennes versions javascript qui en sont dépourvues. Mais lorsque leur emploi est sûr, alors elles peuvent très souvent simplifier la vie du compositeur de regexps, notamment en induisant un raisonnement plus "naturel" dans la construction de l'expression.
En revanche, je crains que vous ne surestimiez quelque peu les capacités du moteur regexp de javascript: seuls (?:), (?=) et (?!) sont supportés par ECMAScript 262/3Ed.
Non, ça ne m'intéresse pas, j'ai déjà trouvé un truc en 2 temps. (assez simple et s'appliquant à ce cas particulier) L'idée est d'arriver à le faire en une seule fois. L'idéal : en un minimum de code.
La première expression permet de normaliser le saut de ligne à un seul caractère (IE utilise rn, ce qui est problématique pour l'emploi du 'multiline').
Je faisais (n|nr|r) comme çà tous les cas sont prévus mais si IE fait encore autrement ... ça va rallonger l'bazar ! mais si rn peut satisfaire tout le monde tant mieux :-)
Néanmoins, pourquoi retrouve t-on ce rn dans le 2ième replace() puisqu'on ne devrait plus n'avoir que des n
La seconde expression insère les <BR>;
Je m'en doutais :-) Bien que ... on peut aussi utiliser des regexp de ce côté ? Il faudrait m'expliquer ce "$1$2<br>$3" Ha! je crois comprendre ! et c'est sioux cette possibilité. Ça pourrait résoudre le pb rencontré avec : t = t.replace(/[^>](n|r|nr|rn)[^<]/g,'$1<br>$3'); en faisant : t = t.replace(/([^>])(n|r|nr|rn)([^<])/g,'$1<br>$3'); Oui ! ça marche ! Oh ! pas s'il y a des espaces qui traînent :-(
u0020 est la valeur code Unicode pour le caractère espace;
OK (je vais devoir rajouter ça) On ne peut pas mettre directement un espace (un blanc) ? ( *)
la propriété 'multiline' (caractère 'm' juste après le corps de la regexp) signifie que les assertions '^' et '$' sont désormais valables pour chaque ligne de la chaîne, et non plus pour la chaîne entière.
Ha oui ! pas bête !
et ça là : (^|[^>]) que veut-ce dire ?
Je lis : (accent circonflexe) ou (n'est pas un >) ... je n'ai sans doute pas les bonnes lunettes ?
HTH,
ça commence, ça commence :-) On va peut-être arriver à ce que ça me plaise et m'amuse :-)
ATH
-- Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Non, ça ne m'intéresse pas, j'ai déjà trouvé un truc en 2 temps.
(assez simple et s'appliquant à ce cas particulier)
L'idée est d'arriver à le faire en une seule fois.
L'idéal : en un minimum de code.
La première expression permet de normaliser le saut de ligne à un seul
caractère (IE utilise rn, ce qui est problématique pour l'emploi du
'multiline').
Je faisais (n|nr|r) comme çà tous les cas sont prévus
mais si IE fait encore autrement ... ça va rallonger l'bazar !
mais si rn peut satisfaire tout le monde tant mieux :-)
Néanmoins, pourquoi retrouve t-on ce rn dans le 2ième replace()
puisqu'on ne devrait plus n'avoir que des n
La seconde expression insère les <BR>;
Je m'en doutais :-)
Bien que ... on peut aussi utiliser des regexp de ce côté ?
Il faudrait m'expliquer ce "$1$2<br>$3"
Ha! je crois comprendre ! et c'est sioux cette possibilité.
Ça pourrait résoudre le pb rencontré avec :
t = t.replace(/[^>](n|r|nr|rn)[^<]/g,'$1<br>$3');
en faisant :
t = t.replace(/([^>])(n|r|nr|rn)([^<])/g,'$1<br>$3');
Oui ! ça marche !
Oh ! pas s'il y a des espaces qui traînent :-(
u0020 est la valeur code Unicode pour le caractère espace;
OK (je vais devoir rajouter ça)
On ne peut pas mettre directement un espace (un blanc) ? ( *)
la propriété 'multiline' (caractère 'm' juste
après le corps de la regexp) signifie que les assertions '^' et '$' sont
désormais valables pour chaque ligne de la chaîne, et non plus pour la
chaîne entière.
Ha oui ! pas bête !
et ça là : (^|[^>])
que veut-ce dire ?
Je lis : (accent circonflexe) ou (n'est pas un >)
... je n'ai sans doute pas les bonnes lunettes ?
HTH,
ça commence, ça commence :-)
On va peut-être arriver à ce que ça me plaise et m'amuse :-)
ATH
--
Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Non, ça ne m'intéresse pas, j'ai déjà trouvé un truc en 2 temps. (assez simple et s'appliquant à ce cas particulier) L'idée est d'arriver à le faire en une seule fois. L'idéal : en un minimum de code.
La première expression permet de normaliser le saut de ligne à un seul caractère (IE utilise rn, ce qui est problématique pour l'emploi du 'multiline').
Je faisais (n|nr|r) comme çà tous les cas sont prévus mais si IE fait encore autrement ... ça va rallonger l'bazar ! mais si rn peut satisfaire tout le monde tant mieux :-)
Néanmoins, pourquoi retrouve t-on ce rn dans le 2ième replace() puisqu'on ne devrait plus n'avoir que des n
La seconde expression insère les <BR>;
Je m'en doutais :-) Bien que ... on peut aussi utiliser des regexp de ce côté ? Il faudrait m'expliquer ce "$1$2<br>$3" Ha! je crois comprendre ! et c'est sioux cette possibilité. Ça pourrait résoudre le pb rencontré avec : t = t.replace(/[^>](n|r|nr|rn)[^<]/g,'$1<br>$3'); en faisant : t = t.replace(/([^>])(n|r|nr|rn)([^<])/g,'$1<br>$3'); Oui ! ça marche ! Oh ! pas s'il y a des espaces qui traînent :-(
u0020 est la valeur code Unicode pour le caractère espace;
OK (je vais devoir rajouter ça) On ne peut pas mettre directement un espace (un blanc) ? ( *)
la propriété 'multiline' (caractère 'm' juste après le corps de la regexp) signifie que les assertions '^' et '$' sont désormais valables pour chaque ligne de la chaîne, et non plus pour la chaîne entière.
Ha oui ! pas bête !
et ça là : (^|[^>]) que veut-ce dire ?
Je lis : (accent circonflexe) ou (n'est pas un >) ... je n'ai sans doute pas les bonnes lunettes ?
HTH,
ça commence, ça commence :-) On va peut-être arriver à ce que ça me plaise et m'amuse :-)
ATH
-- Stephane Moriaux et son (moins) vieux Mac déjà dépassé
-- Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Elegie
ASM wrote:
<snip>
Néanmoins, pourquoi retrouve t-on ce rn dans le 2ième replace() puisqu'on ne devrait plus n'avoir que des n
Non; dans le premier cas seule la séquence "rn" a été modifiée; les 'r' non suivis d'un 'n' ont été gardés. "[rn]", une classe de caractères contenant 'r' *et* 'n', est différent de "rn", une séquence constituée d'un 'r' *suivi* d'un 'n'.
En fait, le caractère de nouvelle ligne est normalement 'n'; IE utilise 'rn'; et je crois me souvenir qu'un autre système (Mac) utilise 'r'. En éliminant IE, on se retrouve avec un seul caractère de nouvelle ligne (soit 'n', soit 'r').
Cette élimination est rendue nécessaire par l'emploi du multiline: dans le cas d'un "rn", le multiline considère qu'il y a deux lignes et non une seule (la première se terminant avec le 'r', et la seconde étant délimitée entre le 'r' et le 'n') - et ce, paradoxalement, même sous IE.
<snip>
On ne peut pas mettre directement un espace (un blanc) ? ( *)
On peut effectivement, mais plus l'expression devient complexe, plus la lisibilité (et donc la maintenance) s'en ressent : un programmeur avec de mauvais yeux pourra ne pas voir l'espace, suivant la police utilisée; et s'il le voit, il pourra douter de sa légitimité. L'emploi d'une valeur code Unicode rend les choses plus claires.
et ça là : (^|[^>]) que veut-ce dire ?
Le chapeau "^" est une assertion signifiant : "au début de la ligne". La classe de caractère "[^>]" signifie: "tout caractère, sauf '>'".
L'expression régulière doit permettre de matcher deux situations: une ligne vide ou blanche (i.e. constituée d'espaces uniquement), ou bien une ligne se terminant par un '>', potentiellement suivi d'espaces.
Ces deux conditions peuvent se décomposer en trois parties: - soit un début de ligne, soit un caractère différent de '>', - (u0020*), qui factorise les espaces, - [rn], qui factorise le caractère de nouvelle ligne.
A noter une subtilité : [^>] peut également matcher un caractère de nouvelle ligne! La nature du moteur RegExp javascript (moteur NFA), toutefois, conduira à la recherche de la plus longue chaîne. Si [^>] matche une nouvelle ligne, alors [rn] ne pourra plus matcher, donc l'expression échouera; le moteur choisira donc la solution où [^>] ne matche pas la nouvelle ligne mais le caractère la précédant (en tenant compte des espaces potentiels), et où [rn] matche la nouvelle ligne.
ça commence, ça commence :-) On va peut-être arriver à ce que ça me plaise et m'amuse :-)
Le sujet, une fois qu'on s'y est plongé, est vraiment intéressant. Je vous recommande, si l'occasion se présente, la lecture du livre de Jeff Friedl sur le sujet, "Mastering Regular Expressions", extrêmement instructif !
Cheers, Elegie.
ASM wrote:
<snip>
Néanmoins, pourquoi retrouve t-on ce rn dans le 2ième replace()
puisqu'on ne devrait plus n'avoir que des n
Non; dans le premier cas seule la séquence "rn" a été modifiée; les
'r' non suivis d'un 'n' ont été gardés. "[rn]", une classe de
caractères contenant 'r' *et* 'n', est différent de "rn", une
séquence constituée d'un 'r' *suivi* d'un 'n'.
En fait, le caractère de nouvelle ligne est normalement 'n'; IE utilise
'rn'; et je crois me souvenir qu'un autre système (Mac) utilise 'r'.
En éliminant IE, on se retrouve avec un seul caractère de nouvelle ligne
(soit 'n', soit 'r').
Cette élimination est rendue nécessaire par l'emploi du multiline: dans
le cas d'un "rn", le multiline considère qu'il y a deux lignes et non
une seule (la première se terminant avec le 'r', et la seconde étant
délimitée entre le 'r' et le 'n') - et ce, paradoxalement, même sous IE.
<snip>
On ne peut pas mettre directement un espace (un blanc) ? ( *)
On peut effectivement, mais plus l'expression devient complexe, plus la
lisibilité (et donc la maintenance) s'en ressent : un programmeur avec
de mauvais yeux pourra ne pas voir l'espace, suivant la police utilisée;
et s'il le voit, il pourra douter de sa légitimité. L'emploi d'une
valeur code Unicode rend les choses plus claires.
et ça là : (^|[^>])
que veut-ce dire ?
Le chapeau "^" est une assertion signifiant : "au début de la ligne".
La classe de caractère "[^>]" signifie: "tout caractère, sauf '>'".
L'expression régulière doit permettre de matcher deux situations: une
ligne vide ou blanche (i.e. constituée d'espaces uniquement), ou bien
une ligne se terminant par un '>', potentiellement suivi d'espaces.
Ces deux conditions peuvent se décomposer en trois parties:
- soit un début de ligne, soit un caractère différent de '>',
- (u0020*), qui factorise les espaces,
- [rn], qui factorise le caractère de nouvelle ligne.
A noter une subtilité : [^>] peut également matcher un caractère de
nouvelle ligne! La nature du moteur RegExp javascript (moteur NFA),
toutefois, conduira à la recherche de la plus longue chaîne. Si [^>]
matche une nouvelle ligne, alors [rn] ne pourra plus matcher, donc
l'expression échouera; le moteur choisira donc la solution où [^>] ne
matche pas la nouvelle ligne mais le caractère la précédant (en tenant
compte des espaces potentiels), et où [rn] matche la nouvelle ligne.
ça commence, ça commence :-)
On va peut-être arriver à ce que ça me plaise et m'amuse :-)
Le sujet, une fois qu'on s'y est plongé, est vraiment intéressant. Je
vous recommande, si l'occasion se présente, la lecture du livre de Jeff
Friedl sur le sujet, "Mastering Regular Expressions", extrêmement
instructif !
Néanmoins, pourquoi retrouve t-on ce rn dans le 2ième replace() puisqu'on ne devrait plus n'avoir que des n
Non; dans le premier cas seule la séquence "rn" a été modifiée; les 'r' non suivis d'un 'n' ont été gardés. "[rn]", une classe de caractères contenant 'r' *et* 'n', est différent de "rn", une séquence constituée d'un 'r' *suivi* d'un 'n'.
En fait, le caractère de nouvelle ligne est normalement 'n'; IE utilise 'rn'; et je crois me souvenir qu'un autre système (Mac) utilise 'r'. En éliminant IE, on se retrouve avec un seul caractère de nouvelle ligne (soit 'n', soit 'r').
Cette élimination est rendue nécessaire par l'emploi du multiline: dans le cas d'un "rn", le multiline considère qu'il y a deux lignes et non une seule (la première se terminant avec le 'r', et la seconde étant délimitée entre le 'r' et le 'n') - et ce, paradoxalement, même sous IE.
<snip>
On ne peut pas mettre directement un espace (un blanc) ? ( *)
On peut effectivement, mais plus l'expression devient complexe, plus la lisibilité (et donc la maintenance) s'en ressent : un programmeur avec de mauvais yeux pourra ne pas voir l'espace, suivant la police utilisée; et s'il le voit, il pourra douter de sa légitimité. L'emploi d'une valeur code Unicode rend les choses plus claires.
et ça là : (^|[^>]) que veut-ce dire ?
Le chapeau "^" est une assertion signifiant : "au début de la ligne". La classe de caractère "[^>]" signifie: "tout caractère, sauf '>'".
L'expression régulière doit permettre de matcher deux situations: une ligne vide ou blanche (i.e. constituée d'espaces uniquement), ou bien une ligne se terminant par un '>', potentiellement suivi d'espaces.
Ces deux conditions peuvent se décomposer en trois parties: - soit un début de ligne, soit un caractère différent de '>', - (u0020*), qui factorise les espaces, - [rn], qui factorise le caractère de nouvelle ligne.
A noter une subtilité : [^>] peut également matcher un caractère de nouvelle ligne! La nature du moteur RegExp javascript (moteur NFA), toutefois, conduira à la recherche de la plus longue chaîne. Si [^>] matche une nouvelle ligne, alors [rn] ne pourra plus matcher, donc l'expression échouera; le moteur choisira donc la solution où [^>] ne matche pas la nouvelle ligne mais le caractère la précédant (en tenant compte des espaces potentiels), et où [rn] matche la nouvelle ligne.
ça commence, ça commence :-) On va peut-être arriver à ce que ça me plaise et m'amuse :-)
Le sujet, une fois qu'on s'y est plongé, est vraiment intéressant. Je vous recommande, si l'occasion se présente, la lecture du livre de Jeff Friedl sur le sujet, "Mastering Regular Expressions", extrêmement instructif !
