Transformation BBCode en HTML - Page 2

non le XHTML n'est plus, le HTML5 n'est pas basé sur le XML, mais sur le bon vieux HTML4 qui est du SGML

Il existe aussi le XHTML5, mais pas grand monde ne l'utilise. Et le HTML5 n'est plus du SGML, il définit son propre SGML/XML-like qui tente d'être rétrocompatible avec le SGML, mais ne contient pas toutes ses particularités.

./23 : je ne comprends pas ta condition if (balise.index < candidat.index), elle est toujours fausse puisque les balises sont parcourues par ordre croissant d'offset, du coup la balise en cours de traitement aura toujours un index supérieur à tous les candidats vus jusqu'ici ? Peut-être que je ne comprends pas trop ce que tu as voulu dire, mais juste pour la précision "candidat" est une séquence candidate, c'est à dire une liste de balises compatibles entre elles (chacune ayant son index).

Voilà comment je l'avais compris :

• Le script récupère toutes les balises d'un texte.
• Chaque balise est examinée individuellement.
• Si une balise n'est pas ouvrante, on cherche des candidats de balises fermantes (candidats qui correspondent à toutes les balises du texte qui n'ont pas encore été ajoutées en séquence)
• Si la balise est fermante (et là on entre dans ma version), on vérifie si le candidat actuel n'est pas situé plus loin que la balise actuelle dans l'index des balises présentes dans le texte : une balise fermante a besoin d'être examinée par les balises qui la précèdent, pas qui la suivent.
• Tant qu'on n'a pas dépassé l'index de la balise fermante, tout candidat "ouvrant" est le candidat valide pour la balise fermante en cours d'examen. On cherche la séquence ouverture/fermeture la plus courte possible parmi les balises encore non-validées.

Dans l'idée, cela reste d'essayer de trouver pour une balise fermante trouvée, la balise ouvrante la plus proche.

Hmm je crois que je ne comprends toujours pas, désolé

Ça veut dire quoi "on vérifie si le candidat actuel n'est pas situé plus loin que la balise actuelle" ? La balise actuelle je vois laquelle c'est, mais dans ma version initiale un "candidat" c'est une collection de plusieurs balises, donc il n'a pas d'index (enfin plus exactement il y en a plusieurs) : il peut être situé simultanément devant et derrière une balise, ou bien la chevaucher. En revanche comme les balises sont parcourues dans l'ordre de leur index, on est certain que la balise actuelle a toujours un index supérieur à ceux de toutes les balises de toutes les séquences formées jusqu'ici. Du coup je ne comprends pas bien ton opération qui consiste à comparer l'index de la balise actuelle avec l'index d'un candidat : d'une part parce que ce que j'appelle un candidat possède plusieurs index, d'autre part parce qu'on sait déjà qu'ils sont tous inférieurs à ceux de la balise actuelle.

En revanche si j'essaie de comprendre l'algo d'après ta dernière phrase, tu veux dire qu'on part des balises fermantes et qu'on essaie de trouver des correspondances en remontant dans la chaine jusqu'à trouver la balise ouvrante la plus proche ? Ça veut dire que dans toto[a]tutu[a]titi[/a] ce sont les deux dernière balises (en rouge) qu'on va remplacer, je me serais plutôt attendu à ce qu'on remplace la première et la dernière, mais à la limite ça n'est pas bien grave. Si c'est bien ça, c'est peut-être une bonne idée en effet, j'essaierai cette version

Suite à ton explication, mon algo est foireux, mais pour le raisonnement final c'est bien cela. C'est, je pense, la meilleure (ou la plus simple) façon d'éviter le chevauchement de balises qui ne le supporteraient pas.

Bon, je viens d'essayer et ça coince sur des cas que j'ai passé sous silence dans ma question, comme quoi je ne sais toujours pas comment simplifier un problème quand je pose une question

Je voulais éviter de fermer la possibilité de passer à des balises un peu plus "wiki-like" un jour (sans retirer le support pour les balises actuelles, rassure-toi 0² !). Ça implique de généraliser un peu plus mon histoire de balises [table][^] et [^] qui sont contenues l'une dans l'autre : les balises avec plusieurs significations selon le contexte.

Par exemple, une liste pourrait être formée avec ce type de syntaxe :

* Premier point
* Deuxième point
* Troisième point

Ce qui signifie que la balise * peut débuter une liste (premier point) ou la continuer (deuxième et troisième points). Avec l'algo du message ./14 ça fonctionne, mais avec celui de ./23 - ./34 - ./35 ça ne marche plus, la priorité est donnée au troisième point qui se met à former une liste tout seul.

Autre chose qui n'est plus géré et que j'aurais bien aimé conserver (même si j'ai également oublié d'en parler, je m'en rends compte uniquement grâce aux tests qui échouent) : les balises qui sont une sous-chaines d'une autre balise. Par exemple je pensais qu'il serait pratique de pouvoir utiliser des underscores pour _mettre en italique_ et des doubles underscores pour __souligner__, ou une configuration équivalente, je n'y ai pas encore vraiment réfléchi mais beaucoup de markups proposent ce type de syntaxe aujourd'hui (Slack, What's App, etc.) qui fait gagner pas mal de temps à l'écriture. Pour l'instant ça fonctionne avec l'algo ./14 à condition de s'interdire de résoudre un autre candidat que le 1er, c'est à dire remplacer foreach (candidat in candidats) par candidat = candidats[0] et parcourir une seule fois la liste de tous les candidats après avoir trouvé toutes les balises.

Dans les deux cas ce sont des choses que j'ai oubliées de mentionner dans ma question, donc désolé Meowcate ton idée était bonne et fonctionne correctement, j'ai simplement mal posé la question. Je pense que mes deux problèmes restants peuvent être résolus en retardant le remplacement des balises tant qu'il reste une ambiguïté, c'est à dire tant qu'elles sont superposées à d'autres balises dont on ne sait pas encore si elles font partie d'un candidat complet ou non.

Je vais voir comment écrire ça, merci encore d'avoir pris le temps de faire des suggestions, à force de combiner toutes les idées je devais m'en sortir

Je sais pas si c'est une bonne idée de melanger plusieurs type de markup, qu'on puisse choisir ok, mais les melanger tu va te trouver dans une situation difficile a gere..

Oui c'est sûr, ils ne seront pas actifs en même temps, si jamais ça devient disponible un jour ça sera via une option dans le profil !kick Folco :D

(je ne suis pas sur non plus qu'un parseur "universel" qui supporte tous les types de markup soit vraiment possible il y auras toujours des cas spéciaux supporté que pour l'un ou que pour l'autre.

Je peux me tromper, ma tete est un peu vide actuellement mais je suis sur qu'il y a des spécificité qui ne sont que pour l'un ou pour l'autre qui sont difficilement generalisable

()

On ne peit pas mélanger les deux en effet, ne serait ce qu'avec l'exemple des listes.
Soit on laisse le choix à l'utilisateur à l'édition du message (voire dans son profil), soit on passe strictement de l'un à l'autre. L'éditeur de message peut faire en sorte que les messages écrits avant la date D utilise l'ancien markup, et ceux d'après le nouveau.

Ou alors devoir convertir en db tous les messages poir un remplacement des markups enregistrés. Très hasardeux, et même pas sûr de comment yN enregistre les messages.

./40 : en effet ça ne sera pas universel, il y a des markups trop différents pour tout traiter d'un coup, mais j'aimerais bien au moins pouvoir proposer une syntaxe Wiki en plus de l'actuelle
./42 : ça en revanche ça ne devrait pas être un problème, les messages sont enregistrés sous forme pré-traitée et ils sont convertis dans le markup de l'utilisateur quand on les édite (c'est déjà le cas sauf qu'il n'y a qu'un seul markup disponible : bbcode ^^)

[edit] Bon j'ai retourné le problème plusieurs fois sans solution donc j'ai fini par suivre la suggestion de 0² et perdre le support des tableaux imbriqués jusqu'à ce qu'un nouveau jeu de balises moins compliqué soit trouvé