[RegExp] BBCode en JS, et regExp complexe.. [Résolu]

[WibiMaster]

Bonjour à tous !

Suite à la création d'un module de BBCode, je voulais permettre une prévisualisation avant envoi, donc en JS. J'aurais aimé éviter une requête Ajax pour faire passer le tout dans du PHP, donc au final, il me faut décoder mon BBCode en full JS... C'est là le soucis.

Déjà, contrairement à preg_replace en PHP, le string.replace de JavaScript ne "boucle" pas. Ça explique les quelques problèmes que je vais énoncer là.. Voilà l'topo :

Il y a deux style de balise BBCode qui me préoccupent actuellement. Le reste sera adaptable si j'arrive à regler ces deux problèmes. Le premier :

balise de type

Code :

[ B ][/B]

(bold -> gras).
Admettons la chaine suivante dans un textarea :

Code :

[ B ]Hello [ B ]World[/B][/B]

Deux idées pour remplacer mes

Code :

[ b ]...[/b]

par des

Code :

<b>...</b>

en JS :

Code :

str = str.replace(/\[B\](.*)\[\/B\]/gi, '<b>$1</b>');

Résultat :

Code :

<b>Hello [ b ]World[/b]</b>

Ceux autour du mot "World" ne sont pas pris en compte.

Autre idée :

Code :

str = str.replace(/\[B\](([^[](?!\B]))*)\[\/B\]/gi, '<b>$1</b>');

Résultat :

Code :

[ b ]Hello <b>World</b>[/b]

Soit l'inverse de précédemment, mais ça ne va toujours pas...

Donc, si quelqu'un sait comment résoudre ce problème déjà

Le second problème est un chouilla plus complexe.
J'ai, dans mes BBCodes, la possibilité d'ajouter la balise :

Code :

[code lang=php][/ code]

Côté décodage, cette balise sera en gros, remplacé par une balise PRE.
L'inconvénient (ou l'avantage au choix) de cette balise PRE, c'est que les \n correspondent à des sauts de ligne, mais que les BR sont affichés tels quels.
Partout ailleurs, les \n provenant du textarea doivent être remplacé par des BR.

Donc le code ci-dessous :

Code :

str = str.replace(/\n/g, '<br />');

va bien me remplacer mes \n par des BR dans mon texte, mais aussi entre mes balises "code lang=php".
J'aurai aimé éviter des remplacements du type "dans les balises code, je remplace tous les \n par une chaine de folie, idem pour les br, je remplace les \n partout dans la page, et je remet mes \n et mes br que j'avais modifiés dans les balises codes".
Le but est de trouver LA regexp qui fera :
"Remplacer tous les \n par des <br />, SAUF ceux entre les balises codes".

Pour info, voilà comment la balise code est remplacé :

Code :

str = str.replace(/\[code lang=([a-zA-Z0-9]+)\](.*?)\[\/code\]/gi, '<div class="code"><pre class="brush: $1">$2</pre></div>');

Et voilà, mes deux soucis sont exposés, et je sèche... Merci à SpaceFrog qui y a mis du sien, mais je suis toujours bloqué

Si quelqu'un qui passe par là à une idée Je n'saurais plus comment le remercier si sa réponse fonctionne ^^

[SpaceFrog]

elle ne te convient pas cette solution là ?

Code :

1
2
3
4
5
6
7
8
9
10
 
chaine="ceci est un test\npour comprendre les regex\navec du bbcode\n[code lang=php]<?php\necho 'ici du php<br />';\n?>[/code]\nle PHP précédent sera mis en <pre>\nMerci Spaffy !";
 
 
bbcode=chaine.match(/\[code[^[]*\][^[]*\[\/code\]/g)
tempchaine=chaine.replace(/\[code[^[]*\][^[]*\[\/code\]/g,"###bbcode###")
tempchaine=tempchaine.replace(/\n/g,"<br/>")
chaine=tempchaine.replace(/###bbcode###/,bbcode)
 
alert(chaine)

[WibiMaster]

Ben non Spaffy, j'ai écris :

J'aurai aimé éviter des remplacements du type "dans les balises code, je remplace tous les \n par une chaine de folie, idem pour les br, je remplace les \n partout dans la page, et je remet mes \n et mes br que j'avais modifiés dans les balises codes".

J'te l'accorde c'est pas exactement ce que tu me propose, mais bon.. Ça rejoint le principe que j'aimerais éviter.

Le but, réellement, c'est d'avoir une regExp bien propre quoi.. A défaut, j'me contenterai d'une solution temporaire comme ça, mais réellement, c'est pas le mieux.
J'imagine qu'avec un nombre indéterminé de balise code, j'vais devoir m'amuser à boucler. ^^

Elle est si balaise que ça à construire cette regExp ?

[SpaceFrog]

ben c'est surtout au niveau des exclusions au sein des imbrication ..

pour la boucle c'est pas très compliqué ..

[WibiMaster]

Provisoirement, j'ai fais la boucle ; j'essaie toujours de faire la regExp, mais waow, compliqué...

Avec ton script et la boucle :

Code :

1
2
3
4
5
6
7
8
9
10
11
<script type="text/javascript">
var chaine='Voilà du texte\navec saut de ligne[code ]et du code\navec saut de ligne[/code ] et encore du texte\n avec saut de ligne [ code]et du code\navec saut de ligne v2[/code ]';
bbcode = chaine.match(/\[code[^[]*\][^[]*\[\/code\]/g);
tempchaine =chaine.replace(/\[code[^[]*\][^[]*\[\/code\]/g,"###bbcode###");
tempchaine =tempchaine.replace(/\n/g,"<br/>");
for(i=0;i<bbcode.length;i++){
	if(i == 0) chaine=tempchaine.replace(/###bbcode###/,bbcode[i]);
	else chaine=chaine.replace(/###bbcode###/,bbcode[i]);
}
alert(chaine);
</script>

Pour la regExp, j'essaie de me servir des assertions négatives avant / arrière, mais y a comme un soucis de longueur à prédéfinir ; par exemple :

Code :

('/((?<!\[code\])\n(?!\[\/code\]))/mi', '<br />', $txt);

Ca ne prendra que les \n directement entourés des balises Code, et je n'arrive pas à intégré le fait qu'il puisse y avoir n'importe quoi entre. Avec le "*", ça plante..

[Atomya Rise]

Comme vu sur le chat, je pose le code trouvé en php qui t'a plu :p

Code php :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
<?php
function format_urls($s){
	return preg_replace(
    "/(\A|[^=\]'\"a-zA-Z0-9])((http|ftp|https|ftps|irc):\/\/[^<>\s]+)/i", "\\1<a href=\\2 target=_blank>\\2</a>", $s);
}
 
function interpreter_pre($s) {
	$s = "<pre class=" . $s[1] . " style=\"margin:0; padding:0\">" . $s[2] . "</pre>";
	$s = str_replace("<br />", "\n" , $s);
	return $s;
}
 
function format_comment($text) {
	global $site_config, $smilies, $info_off;
 
	$s = $text;
	$s = format_urls($s);
	$s = preg_replace("/\[\*\]/i", "<li>", $s); //[*]Liste à puce
	$s = preg_replace("/\[b\]((\s|.)+?)\[\/b\]/i", "<b>$1</b>", $s); // [b]Gras[/b]
	$s = preg_replace("/\[i\]((\s|.)+?)\[\/i\]/i", "<i>$1</i>", $s); // [i]Italique[/i]
	$s = preg_replace("/\[u\]((\s|.)+?)\[\/u\]/i", "<u>$1</u>", $s); // [u]Souligner[/u]
	$s = preg_replace("/\[s\]((\s|.)+?)\[\/s\]/i", "<label style=\"text-decoration:line-through;\">$1</label>", $s); // [s]Barré[/s]
	$s = preg_replace("/\[size=([1-7])\]((\s|.)+?)\[\/size\]/i", "<font size=\"$1\">$2</font>", $s); // [size=4]Texte[/size]
	$s = preg_replace("/\[font=([a-zA-Z ,]+)\]((\s|.)+?)\[\/font\]/i", "<font face=\"$1\">$2</font>", $s); // [font=Arial]Texte[/font]
	$s = preg_replace("/\[center\]((\s|.)+?)\[\/center\]/i","<div style=\"text-align:center\">$1</div>", $s); //[center]text[/center]
	$s = preg_replace("/\[align=([a-zA-Z]+)\]((\s|.)+?)\[\/align\]/i","<div style=\"text-align:$1\">$2</div>", $s); //[align=(center|left|right|justify)]text[/align]
 
	// text en couleur [color=Couleur]x[/color] ET [color=#ffcc99]x[/color]
	$s = preg_replace("/\[color=([a-zA-Z]+)\]((\s|.)+?)\[\/color\]/i", "<font color=\"$1\">$2</font>", $s);
	$s = preg_replace("/\[color=(#[a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9])\]((\s|.)+?)\[\/color\]/i", "<font color=\"$1\">$2</font>", $s);
 
	// Les liens [url=Lien]Texte[/url] ET [url]Lien[/url]
	$s = preg_replace("/\[url=((http|ftp|https|ftps|irc):\/\/[^<>\s]+?)\]((\s|.)+?)\[\/url\]/i", "<a href=\"$1\" target=\"_blank\">$3</a>", $s);
	$s = preg_replace("/\[url\]((http|ftp|https|ftps|irc):\/\/[^<>\s]+?)\[\/url\]/i", "<a href=\"$1\" target=\"_blank\">$1</a>", $s);
 
	// Linebreaks
	$s = str_replace("\n", "<br />", $s);
 
	//$s = preg_replace_callback("/\[cd=([a-zA-Z]+)\]((\s|.)+?)\[\/cd\]/i", "<pre class=$1 style=\"margin:0; padding:0\">$2</pre>", $s); // [cd=texte]blabla[/cd]
	$s = preg_replace_callback("/\[cd=([a-zA-Z]+)\]((\s|.)+?)\[\/cd\]/i", "interpreter_pre", $s); // [cd=texte]blabla[/cd]
 
	// Maintain spacing
	$s = str_replace("  ", " &nbsp;", $s);
 
	return $s;
}
 
?>
<form method="post" action="?">
<textarea name="test" cols="60" rows="10"><?php print(isset($_POST["test"]) ? htmlspecialchars($_POST["test"]) : ""); ?></textarea>
<input type="submit" value="Premier test">
</form>
<?php
 
if (isset($_POST["test"]))
  print("<p><b>Interprétation des balises :</b></b><hr>" . format_comment(htmlspecialchars($_POST["test"])) . "<hr></p>\n");
 
?>

Te reste plus qu'a le passer en JS

Mais en javascript, je trouve ceci dangereux, je te conseille plus l'ajax...

[WibiMaster]

Merci Atomya de l'avoir mis =)
En JS dangereux ? C'est côté client, il fait ce qu'il veut, c'est qu'une preview... Je ne me sers pas de ce qu'il voit =) En Ajax par contre, ça part côté serveur

[ohnomorejmmings]

Envoyé par WibiMaster

Suite à la création d'un module de BBCode, je voulais permettre une prévisualisation avant envoi, donc en JS. J'aurais aimé éviter une requête Ajax pour faire passer le tout dans du PHP, donc au final, il me faut décoder mon BBCode en full JS... C'est là le soucis.

Tu veux que l'aperçu soit en temps réel ? Sinon un simple affichage après validation et donc traitement côté serveur suffit. C'est ce que j'avais fait pour mon module et ça fonctionnait parfaitement. Aucun intérêt à valider des deux côtés, client et serveur, dans le cas d'une prévisualisation juste avant l'envoi. C'est comme ça que l'éditeur qu'on utilise ici fonctionne d'ailleurs.

[WibiMaster]

Oui, le but c'était le temps réel, enfin surtout éviter le traitement côté serveur. Le but était de pomper uniquement sur le client, d'où le full JS. Sinon je suis d'accord avec toi, en toute simplicité, on fait la preview après envoi mais avant enregistrement, comme ici, en rechargeant la page.

Tout de même, je ne marque pas le sujet comme étant résolu, car si quelqu'un arrive à me sortir la bonne regExp, elle pourra me servir dans bien d'autres circonstances

[ohnomorejmmings]

Envoyé par WibiMaster

Oui, le but c'était le temps réel, enfin surtout éviter le traitement côté serveur. Le but était de pomper uniquement sur le client, d'où le full JS.

Si ta priorité c'est de déporter la charge du serveur Web chez le client alors tu fais fausse route. Le traitement côté serveur est inévitable, sécurité oblige, et la fonctionnalité "temps réel" n'est qu'une question d'ergonomie. De plus imagine le boulot pour le navigateur que de bouffer de l'expression régulière à chaque saisi d'un caractère !

Aussi n'oublie pas que le BBCode, et j'en sais quelque chose, c'est un peu "has been" depuis l'émergence des composants d'édition HTML WYSIWYG supportés par les différents navigateurs. Au final la leçon que j'avais retenu, et les utilisateurs aussi, c'est que ce pseudo-langage n'apporte aucun avantage et que des inconvénients. Est-ce plus simple d'écrire des crochets [] que des signes <> ? [b] ou <b> ça revient au même. Après c'est moins évident pour certaines balises un peu plus complexes comme celle de l'hyperlien mais bon… Voilà sans vouloir lancer un débat, juste une piste de réflexion qu'on peut poursuivre dans un autre sujet si besoin. Je veux éviter que les autres reproduisent la même erreur que moi même si j'admets que développer mon petit module a été très enrichissant. Mais ça l'aurait été tout autant en HTML et sans WYSIWYG évident, à la dure !

Envoyé par WibiMaster

Tout de même, je ne marque pas le sujet comme étant résolu, car si quelqu'un arrive à me sortir la bonne regExp, elle pourra me servir dans bien d'autres circonstances

Certes, certes, la Sainte Expression Régulière. Mais pourquoi cette quête ? C'est de la compression à ce niveau là de vouloir en utiliser une seule. Après oui c'est toujours un petite optimisation de plus mais à quel prix ? Faudrait savoir comment les fonctions de JS sont implémentées par les navigateurs en plus car à mon avis la regexp est transformée en une liste d'éléments donc au final ça revient à peu près au même que d'en boucler plusieurs soi-même. Donc perso je pense que c'est plus raisonnable de se reposer sur les modèles de données de langages comme HTML. Les éléments sont énumrés et décrits dans un fichier (DTD & Cie) puis ensuite un "parser" se charge de… boucler !

Bon j'arrête là je suis une vraie piplette mais tout ça me rappelle de bons souvenirs et aussi un paquet de prises de tête .

[javatwister]

Envoyé par ohnomorejmmings

Si ta priorité c'est de déporter la charge du serveur Web chez le client alors tu fais fausse route. Le traitement côté serveur est inévitable, sécurité oblige, et la fonctionnalité "temps réel" n'est qu'une question d'ergonomie. De plus imagine le boulot pour le navigateur que de bouffer de l'expression régulière à chaque saisi d'un caractère !

d'accord avec tout ça et le reste aussi

Dieu sait si je suis fan des regexp mais je ne les utilise presque jamais pour traiter ce qui au fond est du html, même si tu le déguises en bbcode; si tu travaillais directement sur du dom, tu n'aurais pas ces prises de tête;
donc, vois si tu ne peux pas faire un premier enregistrement en db pour donner l'aperçu: pas grand chose à perdre et un gain de neurones évident;

ça rejoint le fait d'utiliser des regexp pour gérer les dates...


[ceci dit, je me suis bien pris la tête pour trouver une soluce à ton exposé, la semaine dernière . Bilan: les regexp sont sympathiques en diable si on ne leur demande pas l'impossible;]

[WibiMaster]

Si ta priorité c'est de déporter la charge du serveur Web chez le client alors tu fais fausse route. Le traitement côté serveur est inévitable, sécurité oblige, et la fonctionnalité "temps réel" n'est qu'une question d'ergonomie. De plus imagine le boulot pour le navigateur que de bouffer de l'expression régulière à chaque saisi d'un caractère !

Gné ?
Là j'suis pas sûr de saisir.. Ici il est question de Preview uniquement, le traitement côté serveur est donc évitable (pas d'enregistrement ni rien), et niveau sécurité.. Le client agit sur lui même, donc j'vois pas trop le soucis.
En passant par de l'Ajax comme dit plus haut, je suis d'accord. En passant par du pur JS, vraiment, je vois pas. Si ça, c'est dangereux, alors une animation doit l'être aussi

Virer le côté "temps réel" et ajouter un bouton "preview" à la place, pourquoi pas. C'est plus light, et j'peux m'en contenter. Par contre, j'insiste sur le côté client uniquement, aucun intérêt de charger le serveur avec les fonctions de preview, il n'y a aucun enregistrement, donc autant que le client s'en charge.

Concernant le WYSIWYG : très bonne remarque ! la réponse est simple : les éditeurs actuels ne conviennent pas pour diverses raisons que j'ai franchement la flemme d'aborder ici Et dév' le mien, j'y ai songer. Mais c'est sacrément galère que de s'adapter à tout navigateur. Et puis un WYSIWYG BBCode, fiou... ^^

Est-ce plus simple d'écrire des crochets [] que des signes <> ?

Point intéressant également. Simplement, je refuse qu'un utilisateur lambda puisse écrire les balises qu'il souhaite. J'en aurai pour plus longtemps à vérifier ce qu'il écrit, qu'à simplement protéger la string en question. De plus, dans mon cas, j'autorise l'écriture de code, qui ne doit pas être interprété.
En terme de sécurité aussi, je trouve ça étrange que tu ais peur du full JS mais que tu me dise de laisser un quidam écrire des balises qui seront interprétées directement ensuite

Est-ce plus simple d'écrire [code lang=php] ou <div id="code"><pre class="brush: php"> ?

Très simplement, les [] n'ont pas de sens en HTML, tandis que les <> oui, et c'est là tout le problème.

Concernant les regExp, j'te met un gros +1
Pour y répondre, en 1er lieu il y a une grande part de curiosité. J'arrive pas à la faire, donc elle m'énerve, donc faut que je comprenne pourquoi
Ensuite, ça n'est pas que de la compression. En PHP, on pourra utiliser le callback du preg_replace. Mais en JavaScript ?
La manière de faire que SpaceFrog avait trouvé était intéressante, en alternative. Conserver en variable, traiter le reste, revenir dessus ensuite. M'enfin, quand on développe, on préfère toujours trouver LA ligne qui va effectuer l'action, que de faire tout un détour non ? Surtout qu'ici, il est question d'une seule balise. Imagine que je me retrouve avec un tas de balises diverses, je serais bien content de trouver la regExp qui fait cela. Pour ça que j'avais ajouté :

elle pourra me servir dans bien d'autres circonstances

C'est pas la 1e fois que j'essayais de faire ça ^^

Si tu fais ta pipelette, moi aussi

[WibiMaster]

Dieu sait si je suis fan des regexp mais je ne les utilise presque jamais pour traiter ce qui au fond est du html, même si tu le déguises en bbcode

Le BBCode n'est pas là uniquement pour déguiser le HTML, il est là pour restreindre le champ d'action. Et simplifier l'expérience user, aussi

[EDIT] J'crois avoir oublié de préciser le fond du truc depuis le début en fait aussi J'utilise SyntaxHighlighter, et il y avait aussi nécessité de l'intégrer dans la preview. Le WYSIWYG à ce niveau là, hardcore

[WibiMaster]

Bon, étant donné que la-dite regExp semble trop compliqué pour quiconque, j'ai finalement fait le WYSIWYG adapaté BBCode + balises type "code"...

J'en ai grave baver quand même, entre IE et ses P / BR, Google Chrome et ses DIV, etc.

Mais le résultat est là, un WYSIWYG au rendu identique sur les nav' que j'ai pu tester (IE7 / IE8 / FF3.6 / GC), reste plus qu'à lui ajouter toutes les balises voulues et à lui faire passer une période de test, histoire de voir si rien d'autre ne ressort.

Marrant quand même, d'ajouter ses propres balises sur un WYSIWYG. On voit qu'c'est pas fait pour

C'est avec regret que je marquerai ce topic comme étant résolu ; d'un côté j'ai une solution qui me convient, de l'autre, je n'ai pas eu la réponse escomptée. Mais bon, c'est l'web, 36000 manière d'aboutir au même résultat ^^
Quand même, cette regExp, si y en a un qui me la trouve... J'lui paie une

[javatwister]

Envoyé par WibiMaster

Quand même, cette regExp, si y en a un qui me la trouve... J'lui paie une

moi aussi à la rigueur;

mais vouloir traiter en une fois une chaîne comme ça n'est pas rationnel (pour le coup...)

[WibiMaster]

mais vouloir traiter en une fois une chaîne comme ça n'est pas rationnel (pour le coup...)

Tu entendrais par là que ça ne serait ni pratique, ni logique, ni fondé sur la raison ?

Ben si, c'est pratique, tout de même, avoir son résultat en une seule ligne.
Si, c'est logique, tout de même, utiliser une regExp (sens global) pour ce pour quoi elle a été créer.
Bon, fondé sur la raison, okay, j'y met un bémol, pour une seule raison : pourquoi chercher à faire de cette manière alors qu'il existe plus simple ailleurs
Mais ça ne serait qu'une suite d'argumentation / contre-argumentation sans fin.

Au passage, personne ne m'a répondu sur la "sécurité" mise en jeu ici
S'il y a un risque, j'aimerais le connaître...

[SpaceFrog]

Traiter en une fois est possible et pas prohibitif, mais avec deux regexp, il suffit de faire un traitement en callback dans le replace en utilisant la seconde regexp dans le callback.

Ce qui est nettement plus complexe, si toute fois c'est réalisable, est de vouloir traiter en une seule fois avec une seule regexp ...

[javatwister]

en fait, je parlais du sens propre de "regular" donc "rationnel";

[WibiMaster]

ScapeFrog> Les RegExp existent dans plusieurs langages, et le Callback n'est pas toujours possible directement (JS ^^)
Sinon ouais, j'commence à douter que ce soit possible. Si j'arrive à choper julp, faudrait que j'lui pose la colle

javatwister> Beh c'est quoi la différence ? J'ai un traitement à effectuer sur une chaîne de caractère selon un motif précis.. J'rentre bien dans la définition non ? J'ai un exemple assez bourrin et complexe ouais lol, mais je vois pas le problème avec le sens du mot "regular"..

[EDIT] 'tain le callback existe en JS Méa Culpa, dans ces conditions, j'm'y adapte, et j'ai ma solution full JS Ca m'empechera pas d'embêter julp, ça me stress de pas réussir à la construire

[Watilin]

Envoyé par WibiMaster

M'enfin, quand on développe, on préfère toujours trouver LA ligne qui va effectuer l'action, que de faire tout un détour non ?

Quand on débute Moi aussi au début, je raffolais des astuces et des raccourcis de code. … Et puis j'ai bossé en entreprise où je devais refiler mon code à mon patron une fois terminé. Et là crois-moi, j'ai appris à faire du code simple ! Pas moins efficace, mais facile à comprendre et à reprendre.

Envoyé par ohnomorejmmings

à mon avis la regexp est transformée en une liste d'éléments

Pas au mien (d’avis) : je n'ai pas de preuves de ce que je raconte, mais je pense que tous les moteurs de regex héritent plus ou moins du premier, qui doit être celui de Perl, du moins pour la famille des PCRE (Perl-Compatible Regular Expressions). Donc rien à voir avec JavaScript, ça doit être implémenté en « code natif ».

Cela dit, rien n'oblige une regex à être plus efficace qu'un bout de code JavaScript. Tout dépend si elle est bien construite…

Envoyé par WibiMaster

mais je vois pas le problème avec le sens du mot "regular"

Le terme officiel c'est expression rationnelle en français. Pour ceux que ça intéresse, ça fait partie de la théorie des langages rationnels, niveau 2 de la classification de Chomsky (oui, celui du film). Avec les automates finis et les automates à pile, qui sont des trucs assez chouettes. On trouve pas mal de docs précises là-dessus en fouillant sur le Web

Envoyé par WibiMaster

Au passage, personne ne m'a répondu sur la "sécurité" mise en jeu ici
S'il y a un risque, j'aimerais le connaître...

C'est simplement que si quelqu'un (exemple au hasard : un développeur web) est capable de trafiquer les données juste avant que le navigateur les envoie au serveur, alors ton serveur reçoit des données qui n'ont pas forcément été contrôlées comme tu le désires… Donc il faut contrôler aussi côté serveur.