Transformation BBCode en HTML - Page 1

Hello !

J'aimerais mettre à jour le code qui permet de rendre le bbcode de yAronet pour corriger principalement deux défauts, dont l'un est la complexité du code causée par certaines balises comme [pre] qui doit empêcher l'interprétation de toutes les autres balises (sauf [/pre]). J'ai une version qui fonctionne quasiment, mais il me reste un problème de priorité pour lequel je n'ai pas trouvé de solution satisfaisante.

Les balises sont reconnues en suivant une règle très simple :

- On commence par repérer les balises dans le texte, sachant qu'une balise correspond à n'importe quelle suite de caractères qui peut donner lieu à une inteprétation (par exemple [b]), puis on les regroupe en séquences de balises compatibles (par exemple la balise [b] suivie de [/b] plus loin dans le texte forment une séquence de balises compatibles).
- Une fois formées les séquences de balises sont résolues dans le sens de lecture, c'est à dire qu'une séquence qui commence avant une autre a la priorité. Autrement dit, [b]machin[b]truc[/b] donne <b>machin[b]truc</b> : la première balise [b] a priorité sur la seconde, c'est donc elle qui est retenue pour faire partie de la séquence.
- La même règle s'applique dans le cas de balises qui se superposent, par exemple on trouve trois balises dans [url=http://www.google.fr]google[/url] : [url=http://www.google.fr], http://www.google.fr (puisque les URLs sont reconnues automatiquement) et [/url]. Les deux premières balises sont superposées et c'est la première qui va avoir la priorité (en revanche sans la balise fermante [/url] la première balise ne ferait plus partie d'une séquence complète et c'est la seconde qui serait alors prise en compte).

Cette règle permet d'éliminer une grosse lourdeur dans le code pour les balises [pre] et [code] : jusqu'ici j'utilisais une notion de contexte pour définir quand une balise est valide ou non. En l'occurrence, [pre] définit un contexte dans lequel aucune autre balise que [/pre] n'est reconnue. Mais cette gestion de contextes complexifie pas mal le code pour gérer seulement deux cas particuliers, et elle peut être remplacée par une solution bien plus simple : plutôt que deux balises distinctes (une ouvrante et une fermante), [pre] devient une seule balise dont l'expression régulière est [pre].*[/pre] (avec un "*" non glouton). Une fois reconnue cette balise superpose toutes les éventuelles balises prises dans le .*, et comme elle les précède elle a la priorité, ce qui les empêche d'être reconnues.

En bonus, c'est une règle qui permet de tout traiter en une passe et s'implémente facilement. Jusqu'ici tout va bien.

Maintenant, un problème se pose pour les tableaux qui ont un jeu de balises compliqué et assez peu logique. Pour des raisons historiques, un tableau ressemble à ça : [table] [^] En-tête 1 [^] En-tête 2 [-] [|] Ligne 1 [|] Ligne 2 [/table]. On pourrait croire qu'il commence par deux balises [table] [^], mais en réalité il s'agit d'une seule balise de la forme [table]\s*[^] : le [^] est obligatoire pour indiquer qu'on veut ouvrir une cellule d'en-tête (et non une cellule simple) et il ne peut pas y avoir de texte entre [table] et [^] (il n'apparaîtrait pas dans le tableau puisqu'il se trouve avant le premier [^] qui déclare le début de la toute première cellule). Il en est de même pour [-]\s*[^] qui termine une ligne et déclare la première cellule de la ligne suivante. C'est comparable à ce qu'on trouve en HTML : bien qu'il faille écrire <table> <tr> <td> pour débuter un tableau, insérer du contenu entre ces trois balises est invalide. En revanche ici il existe bien des balises [^] et [|] qui permettent de terminer une cellule et de passer à la suivante. Si je résume, un tableau est formé par une combinaison de ces balises :

- [table]\s*[^] : démarrer un tableau en commençant par une cellule d'en-tête
- [table]\s*[|] : démarrer un tableau en commençant par une cellule normale
- [-]\s*[^] : terminer la ligne et commencer une cellule d'en-tête
- [-]\s*[|] : terminer la ligne et commencer une cellule normale
- [^] : terminer la cellule en cours et commencer une cellule d'en-tête
- [|] : terminer la cellule en cours et commencer une cellule normale
- [/table] : terminer le tableau

Avec ce joyeux bazar, supposons que je veuille insérer un tableau à l'intérieur d'un autre tableau. Voilà ce que je vais avoir envie écrire :

[table]
[^] Titi
[-]
[|] [table][^] Sous-tableau [/table]
[-]
[|] Toto
[/table]

Bon, aujourd'hui ça fonctionne plus ou moins, mais vous ne voulez vraiment pas savoir comment. Malheureusement avec les règles définies plus haut, ça ne va plus fonctionner comme je m'y attends. Voilà deux des séquences de balises qui vont être trouvées (je vous épargne toute la combinatoire) :

   [table] [^] Titi [-] [|] [table][^] Sous-tableau [/table] [-] [|] Toto[/table]
1: <--------->      <----->        <->                       <----->     <------>
2:                          <-------->              <------>

En suivant toujours la même règle, la séquence 1 va être prise en priorité et manger le second [^] qui aurait pu permettre d'ouvrir un second tableau avec la séquence 2. Le problème vient du fait que les balises des tableaux sont ambiguës, et ici j'ai deux balises superposées qui donnent lieu à deux interprétations différentes.

J'aimerais trouver une règle pour corriger ce problème, si possible simple, mais qui n'entre en conflit avec aucun des autres cas cités plus haut. Si je remplace ma règle par "on commence à trouver les séquences par la droite", ou "on commence à trouver les séquences par l'intérieur", non seulement je vais rendre le code sensiblement plus complexe mais surtout la balise [pre] telle que je la décrivais plus haut ne fonctionnera plus, pas plus que [url=http://bidule]chose[/url].

Une autre façon de résoudre le problème serait de choisir des balises non ambiguës pour les tableaux, mais ça voudrait dire casser la sacro-sainte rétro-compatibilité et 0² m'en voudrait .

Avez-vous des idées ?

Plutôt que de permettre des "tableaux dans des tableaux", peut-être est-il possible d'implémenter quelque chose qui ressemble à rowspan et colspan?

[EDIT] Mais ça casse la rétrocompatibilité... à moins de bricoler une requête SQL qui modifie les messages en BDD ? ^o)

C'est un peu contourner le problème ^^

Pour le moment colspan existe déjà (j'ai un peu simplifié la question), rowspan non, mais ça n'est pas tout à fait équivalent... J'aimerais bien garder la possibilité d'imbriquer n'importe quoi dans n'importe quoi

Zeph (./1) :
Une autre façon de résoudre le problème serait de choisir des balises non ambiguës pour les tableaux, mais ça voudrait dire casser la sacro-sainte rétro-compatibilité et 0² m'en voudrait .

Je confirme

Mais bon, visiblement c'est un sacré sac de nœuds. S'il n'y a pas de solution possible (désolé, j'ai pas le courage de me plonger dans la réflexion aujourd'hui), je serais plutôt d'avis d'utiliser ta nouvelle solution et de ne pas supporter l'imbrication des tableaux. Conceptuellement c'est vrai que c'est un peu dommage, mais à choisir ça me semble nettement mieux de privilégier le combo solution plus propre + rétrocompatibilité plutôt qu'une possibilité qui ne sera quasiment jamais utilisée : déjà que les posts à tableaux sont rares, les tableaux imbriqués doivent se compter sur les doigts d'une main (je ne savais même pas que c'était supporté, et je ne me souviens pas avoir vu de post qui l'utilisait).

En second choix, je serais pas contre changer les balises pour les tableaux, j'ai toujours trouvé que la syntaxe actuelle était assez pénible et pas intuitive. Par contre, dans ce cas merci d'implémenter la moulinette : les posts à tableaux sont souvent ceux sur lesquels on a passé beaucoup de temps à rassembler des données et à se battre avec la mise en forme

Question pragmatique : c'est utilisé souvent, les tableaux de tableaux ?
Si c'est pas le cas, ça vaut vraiment le coup de se faire suer ?

Comme il s'agit de 2 balises différentes (la composite [table][^] vs. [^]), pas moyen d'implémenter des priorités ([table][^] est prioritaire sur [^] si les deux matchent)?

./4 : Bien sûr, quelle que soit la solution je mettrai à jour les anciens messages pour que le rendu ne change pas

Mais OK, je note la suggestion (doublée par Folco) "on s'en fout personne ne l'utilise", c'est vrai que ça simplifie le problème

./5 : Oui c'est exactement ça, mais c'est justement là-dessus que je coince. Les priorités ne s'appliquent pas entre les balises mais entre les séquences complète de balises (car il faut considérer tout le texte pour savoir quelles sont les balises éligibles, un [b] tout seul sera ignoré s'il n'y a pas le [/b] correspondant par exemple). J'essaie de savoir comment gérer ces priorités mais je n'ai pas trouvé de solution qui fonctionne pour tous les cas que je résume dans le message ./1 (et encore j'ai un peu simplifié, j'espère n'en avoir oublié aucun).

Je ne sais pas comment tu fais la recherche et le remplacement, mais si tu tiens à lire les séquences ainsi dans l'ordre, je serais d'avis qu'en entrant dans un [table], tu récupères les balises internes individuellement, mais qu'en arrivant à un nouveau [table], l'interprétation du contenu soit ignoré jusqu'au prochain [/table] (et en cas d'imbrications successives, continuer de compter les ouvertures/fermetures). Tu passes après à la séquence 2 pour le contenu du [table] ignoré, et ainsi de suite.

Je vote aussi pour la solution simple qui ignore les tableaux imbriqués

As-tu regardé s'il y avait le moindre message utilisant cette fonction ?

./8 : je ne suis pas sûr de comprendre la suggestion, tu veux dire un traitement particulier juste pour la balise [table] ? (j'aimerais éviter d'introduire des cas particuliers par balise, jusqu'à présent ça n'a pas été nécessaire, mais c'est vrai que je n'ai pas précisé ça dans le premier message)
./9 : hmm... celui-ci compte ? (c'est mon message de test pour la moulinette de conversion ^^)

C'est bien pour éviter un cas particulier que je propose de rattacher une priorité à chaque balise, pour départager en cas de conflit entre 2 balises différentes. Tu mettrais une priorité 0 à quasiment tout et 1 à [table][^] et [table][|] et c'est bon.

Oui, mais je ne comprends pas à quel moment tu veux appliquer cette priorité ? Avant d'avoir trouvé des séquences complètes je ne peux pas, puisque je ne sais pas encore s'il s'agit bien de balises ou juste de texte qui ne peut pas être transformé. Pour reprendre l'exemple du message ./1 il arrivera un moment où je vais trouver [/table] et je vais avoir le choix entre compléter une séquence qui utilise le [^] de [table][^], ou bien j'attends un peu plus longtemps pour voir s'il n'y a pas une autre séquence qui pourrait utiliser ce [table][^]. On pourrait le considérer de plus haute priorité ici, mais à quel moment ça joue ? Quand puis-je prendre la décision de l'ignorer ou d'attendre encore plus ? Ou bien je termine d'analyser toute la chaine et je ne peux prendre ma décision qu'une fois toutes les balises trouvées, et alors seulement j'essaie de prendre celles qui maximisent la priorité ? C'est sacrément moins efficace, mais à la limite tant pis. En revanche même là, il va falloir que je tranche entre deux règles contradictoires "la première séquence qui commence gagne" et "la séquence qui a la plus haute priorité gagne", le choix ne me semble pas évident ?

Peut-être que poser la question avec des mots n'était pas suffisant, je peux peut-être poster un pseudo-algo de la solution actuelle, ça me permettra de le faire évoluer avec ce que je comprends de vos propositions. J'essaie de faire ça demain

Je pense pourtant que tu dois faire un cas particulier. La plupart de tes balises imbriquées (en gras par exemple) ne posent pas de problèmes si elles sont à l'intérieure d'elles-même. D'autres (comme la balise image) ne fonctionnerait pas, mais ce serait normal.
Le tableau est un cas particulier où tu peux avoir une structure dans une structure. Ce n'est pas la seule (la balise quote le fait aussi par exemple), mais c'est une structure dont dépend d'autres éléments (les balises de ligne et de colonne ne servent pas en dehors d'une table).
Je ne pense pas que pour ta façon de structurer le bbcode, tout en voulant assurer une rétro-compatibilité, tu puisses te passer d'un cas particulier.

Dans le doute, tu peux bien aller voir du bbcode open-source comme sur phpBB pour voir comment ils résolvent ce genre de problème.

Cependant, une analyse préliminaire peut être utile aussi : ta première table deviendrait [table1], puis [table2], etc, puis les fermetures seraient en sens inverse de récupération, [/table2], puis [/table1]... Tu aurais ainsi (potentiellement) plusieurs table1 dans un post, puis les sous-niveaux présents table2 (dont plusieurs table2 possibles par table1), d'éventuels table3 imbriqués dans table2... avec ces numéros de priorité, tu peux gérer les ouvertures/fermetures.

Meowcate (./13) :
Je ne pense pas que pour ta façon de structurer le bbcode, tout en voulant assurer une rétro-compatibilité, tu puisses te passer d'un cas particulier.

Je me trompe peut-être mais j'espère encore que si

Meowcate (./13) :
Dans le doute, tu peux bien aller voir du bbcode open-source comme sur phpBB pour voir comment ils résolvent ce genre de problème.

J'ai regardé pas mal de solutions de balises dans des projets open-source, mais c'est souvent assez rudimentaire par rapport à ce que propose yAronet (et ça ne date pas de moi, le jeu de balises n'a quasiment pas changé depuis que je m'en occupe) : pas de balises autres que ouverture/fermeture, pas de séquence d'échappement, génération de code HTML invalide dès que les balises sont mal utilisées, ou bien balises non reconnues quand elles sont entrecroisées, etc. Le code de phpBB traite les balises en 25 passes d'analyse sur la chaine et du code custom (y compris des requêtes SQL !) pour à peu près toutes les balises, ce que j'aimerais doublement éviter :/

Voilà donc le pseudo-code de traitement des balises qui correspond au post ./1, en espérant que ce soit un peu plus clair que ma tentative d'explication :function remplace_balises(texte) { candidats = []; // Liste des séquences encore incomplètes en cours de construction sequences = []; // Liste des séquences complètes (qui possèdent une balise ouvrante, une fermante et éventuellement des balises intermédiaires entre les deux) // Première passe : repérage des séquences de balises foreach (balise in trouve_balises(texte)) // Simple recherche lexicale de toutes les balises, ordonnées par offset, avec une grosse regexp ou équivalent { if (balise.est_ouvrante) // Balise ouvrante : démarre peut-être une nouvelle séquence { sequence = new Sequence(); sequence.append(balise); candidats.ajoute(sequence); // L'ordre des séquences candidates suit celui des balises ouvrantes, elles sont donc naturellement triées par l'index de leur première balise } else // Balise non-ouvrante : peut continuer n'importe quelle séquence qui contient des balises compatibles (par exemple [*] est compatible avec [table]) { foreach (candidat in candidats) { if (candidat.est_compatible_avec(balise)) { candidat.ajoute(balise); if (balise.est_fermante) // On vient d'ajouter une balise fermante à une séquence, elle est donc complète { candidats.supprime(candidat); // Supprimer la séquence actuelle des candidats potentiels sequences.ajoute(candidat); // Ajouter la séquence actuelle aux séquences complètes annuler_balises_superposees(candidats, candidat); // Supprimer des candidats toutes les balises faisant partie de la séquence actuelle, puisqu'elles sont utilisées et ne peuvent plus faire partie d'une autre séquence break; // Notre balise fermante vient de compléter une séquence, pas besoin de chercher plus loin } } } } } // Deuxième passe : suppression des séquences complètes foreach (sequence in sequences) { foreach (balise in sequence) texte.supprime(balise.offset, balise.length); // Incorrect : les offets deviennent potentiellement invalides dès qu'on commence à changer le texte, mais en pratique il suffit de les corriger ou de les retirer en partant par la fin pour contourner ce souci } return (texte, sequences); // Récupération du texte brut (sans les balises) d'un côté, et de la liste des balises groupées par séquence d'un autre }

C'est con mais tu es en train de te poser les question d'un compilateur, tu as regardé pour utiliser des methodes similaires ? (parsing, grammaire, arbre syntaxique & co)

Soucis, il faut une grammaire claire que le bbcode n'est pas spécialement..

Tu veux pas convertir yN en C ? ;-)


Sinon c'est la solution classique de rendu pour les texte "riches", tu as un etat pour chaque type de balise qui changent un etat (genre B, I, PRE, etc..) les autre sont des balises qui ajoutent un element particulier, tu compte pour chaque le niveau, et quand tu arrive a la fin du poste pour que ca soit "propre" tu ferme par rapport au chaque niveau.

A vrai dire j'ai peur que tu tombe dans des regexp super compliqué qui vont foirer dans des cas marginaux (ou pas), le match de paires de balises a coup de regexp est une pente tres glissante... (regarde l'horreur que ca peu etre en C un regexp qui marche les commentaires, et c'est un cas d'école..)

Ouais enfin, je suis pas sûr d'avoir envie de me taper des pages entières de messages d'erreur parce que j'ai oublié un crochet dans une balise, perso

int repondre(void)
{
printf("Rholalala \n");
return SUCCESS;
}

(et je ne parle même pas des balises qui ont un effet indéfini !)

[commentca]des balises aux effets indéfinis?[/commentca]

Sinon apriori certains on fait ca en LISP: https://github.com/Ralith/quest/blob/master/src/bbcode-grammar.lisp ??

./15 : ça serait techniquement possible de pondre une grammaire pour les balises de yAronet, elle est clairement LL(1) donc n'importe quel Bison ou autre devrait la manger sans problème, mais je ne suis pas parti dans cette direction pour deux raisons (ceci dit je peux me tromper sur les deux, d'où ce sujet ^^) :

- La première c'est que ça me semble pas tellement adapté au problème car la syntaxe bbcode est assez triviale, c'est un arbre quasiment plat avec seulement des règles de priorité (celles que j'essaie justement de résoudre, en partant du principe que tout le reste de la logique est très simple et correspond à l'algo du post ./14)
- La seconde est plus gênante, c'est que je n'ai trouvé aucun outil correct pour générer du PHP à partir d'une grammaire. Il y a Jison qui possède un convertisseur PHP, mais c'est une horreur qui part du code JS et essaie de produire du PHP à grands renforts de str_replace, j'ai joué un peu avec et de façon attendue il génère du code invalide dès qu'on sort des cas d'école. J'ai aussi regardé cet autre projet mais c'est une grammaire PEG et non BNF (à la limite tant pis mais j'aurais bien aimé quelque chose de plus courant) et le dernier commit a 3 ans donc je ne suis pas super chaud pour partir dessus

Sinon non effectivement, les regexps c'est une très mauvaise solution ici

Je sais que c'est overkill, c'était un peu une blague
Meme si je pense que c'est dans la majorité des cas la meilleur (et plus souple) des solutions..

Par contre oué, ok PHP n'est pas vraiment un language adapté pour faire un compilateur... mais c'est dommage qu'il n'y a ai pas de tel outils (ou pas? je pense pas tres avoir envie de voir arriver des compilateurs écrit en PHP.. )

Apres c'est toujours le bon vieux probleme des parsers, certaines solutions sont moche mais marchent, d'autre sont elegantes, mais souvent un peu trop overkill pour les besoins, et aucune des deux solutions n'est parfaite/reponds a tous les besoin. Et pourtant ca fais plusieurs décades que des gens se penchent dessus sans trouver LA solution

La première chose qu'on m 'a appris en cours de compil c'est les regex

Et la deuxième c'est que récusivité => regex out.

Ce n'est jamais à faire.

Sinon pour ton code, ma suggestion est effectivement qu'à toute fermeture rencontrée, tu prends la dernière ouverture antérieure non-traitée encore possible.
Voilà ma suggestion dans ton else :foreach (candidat in candidats) { if (candidat.est_compatible_avec(balise)) { candidat.ajoute(balise); if (balise.est_fermante) { if (balise.index < candidat.index) { candidat_compatible = candidat; /* * Je ne suis pas sûr de ton langage et comment l'on récupère les * index. En somme, le candidat compatible (donc ouvrant) doit être * la dernière balise ouvrante compatible entre le début du post et * la balise fermante actuellement traitée. */ } else { // On a fini les candidats compatibles jusqu'à la balise, pas besoin // de vérifier les suivants break; } } } } if (isset(candidat_compatible)) { // Maintenant qu'on a le candidat compatible, on peut traiter la séquence candidats.supprime(candidat_compatible); sequences.ajoute(candidat_compatible); annuler_balises_superposees(candidats, candidat_compatible); unset(candidat_compatible); // On supprime la variable pour les prochaines séquences }

J'avais oublié cette réponse mythique

"HTML and regex go together like love, marriage, and ritual infanticide."

Ne pas oublier que le HMTL permet d'imbriquer les tags, <b><i></b></i> est valide, je sais pas si trop se faire chier est vraiment la peine..

Zeph parle de cas complexes.
En règle général d'ailleurs (pseudo-héritage de XHTML), ce que tu proposes n'est pas valide. Imbriquer des tags, d'accord (<strong>Contenu<em>Contenu</em>Contenu</strong>).

Les faire se chevaucher (<strong>Contenu1<em>Contenu2</strong>Contenu3</em>) n'est pas valide pour autant que j'en sache, même si les navigateurs peuvent l'interpréter.
En fait, la façon correcte serait alors <strong>Contenu1<em>Contenu2</em></strong><em>Contenu3</em>

Je viens de tester : sur Firefox, un table à cheval sur un autre est aussitôt fermé.

./25 C'est peut-être admis par la plupart des browsers mais je me réserve d'énormes doutes sur la validité du point de vue de la spec. Ce genre de truc ça suffisait à démarrer un mode Quirks sur IE à l'époque

Va lire la doc du SGML tu va être surpris..

est-ce encore vrai pour le HTML5 ?

oui, c'est pas ca la différence avec le XHTML?