split et paragraphes séparés par un double saut de ligne
5 réponses
gvdmoort
Bonjour =E0 tous,
Soit un formulaire web avec une <textarea>. Les utilisateurs y entrent
un texte assez long avec des sauts de lignes ind=E9sirables en fin
d'=E9cran, et des doubles sauts de ligne pour s=E9parer les =ABvrais=BB
paragraphes.
Le texte transmis ainsi au script CGI est r=E9cup=E9r=E9 dans une variable
$texte, que je voudrais donc reformatter proprement en
- =E9liminant tous les sauts de ligne isol=E9s;
- rempla=E7ant les sauts de lignes multiples (2 ou plus) par des sauts
de lignes uniques;
- splittant sur base des sauts de lignes en r=E9sultant,
de mani=E8re =E0 ce que chaque sous-cha=EEne ainsi extraite puisse =EAtre
reformatt=E9e en quelque chose comme
<p>$substring</p>
pour =EAtre r=E9inject=E9e dans une page html.
Pour l'instant, j'ai
$texte=3Dparam("texte");
# =C9liminer tous les retours =E0 la ligne qui sont pr=E9c=E9d=E9s d'un
non-espace
$texte =3D~ s+(\S)\r\n+$1 +g;
@texte =3D split /\r\n/,$texte;
foreach $subtext (@texte) {
chomp $subtext;
$subtext=3D"<p>$subtext</p>";
push @newtext,$subtext;
}
Mais je crois qu'il y a un probl=E8me de portabilit=E9 li=E9 au \r\n qui
serait propre =E0 windows, et cela conserve les sauts de lignes
r=E9p=E9t=E9s plus de deux fois.
Donc, si vous pouviez me conseiller quelque chose de meilleur, ce
serait bienvenu.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Nicolas George
wrote in message :
- éliminant tous les sauts de ligne isolés; - remplaçant les sauts de lignes multiples (2 ou plus) par des sauts de lignes uniques; - splittant sur base des sauts de lignes en résultant,
Il vaudrait largement mieux faire dans l'ordre inverse :
J'espère que c'était un exemple simplifié, et que dans le vrai résultat, le soin sera pris de protéger les caractères spéciaux du HTML. Personnellement, je recommande volontiers de construire la page web sous forme d'un arbre XML DOM (avec XML::DOM ou XML::LibXML), la bibliothèque se chargeant alors de tout le travail sordide d'échappement.
gvdmoort@skynet.be wrote in message
<1139499113.634362.289520@g47g2000cwa.googlegroups.com>:
- éliminant tous les sauts de ligne isolés;
- remplaçant les sauts de lignes multiples (2 ou plus) par des sauts
de lignes uniques;
- splittant sur base des sauts de lignes en résultant,
Il vaudrait largement mieux faire dans l'ordre inverse :
J'espère que c'était un exemple simplifié, et que dans le vrai résultat, le
soin sera pris de protéger les caractères spéciaux du HTML. Personnellement,
je recommande volontiers de construire la page web sous forme d'un arbre XML
DOM (avec XML::DOM ou XML::LibXML), la bibliothèque se chargeant alors de
tout le travail sordide d'échappement.
- éliminant tous les sauts de ligne isolés; - remplaçant les sauts de lignes multiples (2 ou plus) par des sauts de lignes uniques; - splittant sur base des sauts de lignes en résultant,
Il vaudrait largement mieux faire dans l'ordre inverse :
J'espère que c'était un exemple simplifié, et que dans le vrai résultat, le soin sera pris de protéger les caractères spéciaux du HTML. Personnellement, je recommande volontiers de construire la page web sous forme d'un arbre XML DOM (avec XML::DOM ou XML::LibXML), la bibliothèque se chargeant alors de tout le travail sordide d'échappement.
Paul Gaborit
À (at) 9 Feb 2006 07:31:53 -0800, écrivait (wrote):
Mais je crois qu'il y a un problème de portabilité lié au rn qui serait propre à windows, et cela conserve les sauts de lignes répétés plus de deux fois.
Outre les bonnes remarques de Nicolas Georges, j'ajouterais ceci :
En théorie, si votre formulaire est bien conçu (il indique le(s) jeu(x) de caractères accepté(s), il utilise la méthode 'post', etc.) et si le navigateur respecte les normes, ça ne devrait poser aucun problème.
En pratique, la natures des passages à la ligne des données que vous recevrez (ainsi que leur encodage en général) dépendra à la fois de la plateforme et du navigateur utilisés par le client.
Pour les passages à la ligne, on peut s'en sortir en utilisant l'expression rationnelle suivante pour matcher un passage à la ligne :
(:? 15 12| 15| 12)
Le 15 12 permet de reconnaître le CR LF officiel (de manière indépendante de la plateforme). Les deux autres possibilités gère les mauvais encodages des fins de lignes (Mac ou Unix).
Pour l'encodage (des accents en particulier), cela dépend malheureusement du navigateur et il n'y pas de méthodes fiables à 100% pour reconnaître de manière sûre l'encodage utilisé... Heureusement pour vous, la plupart des navigateurs récents respectent l'encodage demandé (si vous en demandez un!).
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) 9 Feb 2006 07:31:53 -0800,
gvdmoort@skynet.be écrivait (wrote):
Mais je crois qu'il y a un problème de portabilité lié au rn qui
serait propre à windows, et cela conserve les sauts de lignes
répétés plus de deux fois.
Outre les bonnes remarques de Nicolas Georges, j'ajouterais ceci :
En théorie, si votre formulaire est bien conçu (il indique le(s)
jeu(x) de caractères accepté(s), il utilise la méthode 'post', etc.)
et si le navigateur respecte les normes, ça ne devrait poser aucun
problème.
En pratique, la natures des passages à la ligne des données que vous
recevrez (ainsi que leur encodage en général) dépendra à la fois de la
plateforme et du navigateur utilisés par le client.
Pour les passages à la ligne, on peut s'en sortir en utilisant
l'expression rationnelle suivante pour matcher un passage à la ligne :
(:? 15 12| 15| 12)
Le 15 12 permet de reconnaître le CR LF officiel (de manière
indépendante de la plateforme). Les deux autres possibilités gère les
mauvais encodages des fins de lignes (Mac ou Unix).
Pour l'encodage (des accents en particulier), cela dépend
malheureusement du navigateur et il n'y pas de méthodes fiables à 100%
pour reconnaître de manière sûre l'encodage utilisé... Heureusement
pour vous, la plupart des navigateurs récents respectent l'encodage
demandé (si vous en demandez un!).
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) 9 Feb 2006 07:31:53 -0800, écrivait (wrote):
Mais je crois qu'il y a un problème de portabilité lié au rn qui serait propre à windows, et cela conserve les sauts de lignes répétés plus de deux fois.
Outre les bonnes remarques de Nicolas Georges, j'ajouterais ceci :
En théorie, si votre formulaire est bien conçu (il indique le(s) jeu(x) de caractères accepté(s), il utilise la méthode 'post', etc.) et si le navigateur respecte les normes, ça ne devrait poser aucun problème.
En pratique, la natures des passages à la ligne des données que vous recevrez (ainsi que leur encodage en général) dépendra à la fois de la plateforme et du navigateur utilisés par le client.
Pour les passages à la ligne, on peut s'en sortir en utilisant l'expression rationnelle suivante pour matcher un passage à la ligne :
(:? 15 12| 15| 12)
Le 15 12 permet de reconnaître le CR LF officiel (de manière indépendante de la plateforme). Les deux autres possibilités gère les mauvais encodages des fins de lignes (Mac ou Unix).
Pour l'encodage (des accents en particulier), cela dépend malheureusement du navigateur et il n'y pas de méthodes fiables à 100% pour reconnaître de manière sûre l'encodage utilisé... Heureusement pour vous, la plupart des navigateurs récents respectent l'encodage demandé (si vous en demandez un!).
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
gvdmoort
Merci à vous deux pour ces indications. Petit détail, la détection des sauts de lignes multiples dans le message de Nicolas était /n{2,}/ au lieu de /n{,2}, mais par contre je ne comprend pas le rôle du
:? en début de (:? 15 12| 15| 12)
dans celui de Paul.
G.
Merci à vous deux pour ces indications. Petit détail, la détection
des sauts de lignes multiples dans le message de Nicolas était
/n{2,}/ au lieu de /n{,2}, mais par contre je ne comprend pas le
rôle du
Merci à vous deux pour ces indications. Petit détail, la détection des sauts de lignes multiples dans le message de Nicolas était /n{2,}/ au lieu de /n{,2}, mais par contre je ne comprend pas le rôle du
:? en début de (:? 15 12| 15| 12)
dans celui de Paul.
G.
Paul Gaborit
À (at) 13 Feb 2006 03:06:28 -0800, écrivait (wrote):
Merci à vous deux pour ces indications. Petit détail, la détection des sauts de lignes multiples dans le message de Nicolas était /n{2,}/ au lieu de /n{,2}, mais par contre je ne comprend pas le rôle du
:? en début de (:? 15 12| 15| 12)
dans celui de Paul.
C'est une faute de frappe. La bonne syntaxe est :
(?: 15 12| 15| 12)
Un groupe (entre parenthèse) qui commence par ?: n'est pas mémorisé.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) 13 Feb 2006 03:06:28 -0800,
gvdmoort@skynet.be écrivait (wrote):
Merci à vous deux pour ces indications. Petit détail, la détection
des sauts de lignes multiples dans le message de Nicolas était
/n{2,}/ au lieu de /n{,2}, mais par contre je ne comprend pas le
rôle du
:? en début de (:? 15 12| 15| 12)
dans celui de Paul.
C'est une faute de frappe. La bonne syntaxe est :
(?: 15 12| 15| 12)
Un groupe (entre parenthèse) qui commence par ?: n'est pas mémorisé.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) 13 Feb 2006 03:06:28 -0800, écrivait (wrote):
Merci à vous deux pour ces indications. Petit détail, la détection des sauts de lignes multiples dans le message de Nicolas était /n{2,}/ au lieu de /n{,2}, mais par contre je ne comprend pas le rôle du
:? en début de (:? 15 12| 15| 12)
dans celui de Paul.
C'est une faute de frappe. La bonne syntaxe est :
(?: 15 12| 15| 12)
Un groupe (entre parenthèse) qui commence par ?: n'est pas mémorisé.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Nicolas George
wrote in message :
Merci à vous deux pour ces indications. Petit détail, la détection des sauts de lignes multiples dans le message de Nicolas était /n{2,}/ au lieu de /n{,2},
Effectivement, au temps pour moi.
mais par contre je ne comprend pas le rôle du
:? en début de (:? 15 12| 15| 12)
dans celui de Paul.
(?: ... ) a un effet similaire à simplement ( ... ) au niveau du groupage : ça délimite la portée du | ou d'un + qui viendrait après. La différence est que les parenthèses seules ont en plus l'effet de capturer leur contenu dans les variables $1, $2, etc. Dans le cadre d'un split, c'est encore pire, puisque tout groupe capturant dans le délimiteur est en plus envoyé dans la liste résultante.
gvdmoort@skynet.be wrote in message
<1139828788.890060.29890@g43g2000cwa.googlegroups.com>:
Merci à vous deux pour ces indications. Petit détail, la détection
des sauts de lignes multiples dans le message de Nicolas était
/n{2,}/ au lieu de /n{,2},
Effectivement, au temps pour moi.
mais par contre je ne comprend pas le
rôle du
:? en début de (:? 15 12| 15| 12)
dans celui de Paul.
(?: ... ) a un effet similaire à simplement ( ... ) au niveau du groupage :
ça délimite la portée du | ou d'un + qui viendrait après. La différence est
que les parenthèses seules ont en plus l'effet de capturer leur contenu dans
les variables $1, $2, etc. Dans le cadre d'un split, c'est encore pire,
puisque tout groupe capturant dans le délimiteur est en plus envoyé dans la
liste résultante.
Merci à vous deux pour ces indications. Petit détail, la détection des sauts de lignes multiples dans le message de Nicolas était /n{2,}/ au lieu de /n{,2},
Effectivement, au temps pour moi.
mais par contre je ne comprend pas le rôle du
:? en début de (:? 15 12| 15| 12)
dans celui de Paul.
(?: ... ) a un effet similaire à simplement ( ... ) au niveau du groupage : ça délimite la portée du | ou d'un + qui viendrait après. La différence est que les parenthèses seules ont en plus l'effet de capturer leur contenu dans les variables $1, $2, etc. Dans le cadre d'un split, c'est encore pire, puisque tout groupe capturant dans le délimiteur est en plus envoyé dans la liste résultante.
