Reprise du message précédent :
Bha c'est des outils assez puissant, mais à l'utilisation c'est simple et à la sortie ca te génère un fichier C à compiler, donc assez léger je pense aussi.
 
Jviens de faire un test juste avec flex :
 

/* BBcode parser */
%{
void imgprt(char*, char*);
char* user2img(char*);
%}
 
%%
\[:[[:alnum:] _-]+:\] imgprt(user2img(yytext), "user smiley" );
:pt1cable:            imgprt("pt1cab.gif", ":pt1cable:" );
:p                    imgprt("p.gif", ":p" );
\n                    puts("<br />" );
%%
 
/* transforme [:machin:] en machin.gif */
char* user2img(char* user)
{
   char *tmp, *img;
   sscanf(user, "[:%a[a-zA-Z0-9 _-]:]", &tmp);
   asprintf(&img, "%s.gif", tmp);
   free(tmp);
   return img;
}
 
/* affiche un smiley */
void imgprt(char* image, char* code)
{
   printf("<img src=\"%s\" alt=\"%s\" />", image, code);
}
 
/* le main */
int main(void)
{
   yylex();
}

(pour ceux qui veulent tester la commande de compil est "flex bbparse.yy &&  gcc lex.yy.c  -lfl -o bbparse" , avec bbparse.yy le fichier que je viens de citer)
 
Bon les 2 fonctions imgprt et user2img faut pas regarder, c'est tout laid comme code et ca leak a mort.
La partie intéressante, et la seule à bidouiller pour gérer les codes, c'est celle entre les %%, la suite des règles de replacement ( a chaque correspondance, le code C sur la même ligne est exécuté et pour le texte sans correspondance, il sort sur la sortie standard ), assez simple a employer il me semble, et avec ces règles totalement triviales ( sans bidouilles genre retour arrière et tout ca comme les regexp pour le ) j'ai jamais de conflit entre et c'est le bonheur

mais un il va pas être remplacé dans un http:// ?
 
(tient d'ailleurs y a des \ qui sont bouffés par geshi )

 
Non parceque le principe du parseur lexical c'est de découper la chaine de texte en élements atomiques (et il le fait en une seule passe d'ailleurs, donc cool pour les perfs), si http://kkchose.com est un élément de type "url" alors c'en est un et c'est tout il passe à la suite du texte directement, sachant qu'il prends en priorité les éléments les plus long ca évite aussi les pb avec les elements à préfixe commun ( et  )

et les nested tags il les gère comment ?
 
genre
 
[quote1]a[quote1]b[quote1]c[/quote1][/quote1][/quote1]

la gestion des nested et tout ca, ca serait plutot le role de bison après il me semble, mais je connais pas super bien, faudra que je regarde ca demain, la jdois bosser un peu ...

En effet c'est bison qui doit s'occuper de ça.
Quoi qu'il en soit, avec un outil comme flex, le résultat pour le parsing des smilies sera de toute façon bien plus rapide.
Flex c'est l'analyseur lexical, tu luis files tes regex pour déterminer que c'est un smiley_type_1 et [quote] un debut_quote
après tu utilises ces symbôles pour définir ta grammaire avec bison....

genre :

quote -> debut_quote bloc fin_quote ... et ainsi de suite. Tu peux faire des trucs super puissants et à priori plus rapides et faciles à gérer que les regexp qui doivent être bien dûres à gérer.

disons que les trucs les plus chiant à gérer c'est les trucs du type :
 
<span ...> test <span ...> test1 </span> </span>
 
faut pas qu'il pense que le premier </span> rencontré et celui qui ferme le premier <span ...>

 
Face à flex (qui n'est pas une usine à gaz forcément), ils doivent faire vraiment sales figures (pas besoin de yacc/bison pour des expressions régulières au passage).

 
C'est à toi de gérer ça, c'est de la grammaire, pas de la reconnaissance lexicale.  
 
A la limite, tu peux le gérer avec des "START CONDITIONS" (voir manuel, http://www.hmug.org/man/1/flex.php par exemple).
 

 
Ca tu t'en fous, c'est ton navigateur qui s'en occupe, si ton machin en flex remplace [ quote] par <span class="quote"> et [ /quote] par </span>
ca marchera tout seul.
 
Au pire ce qu'il faut c'est pour gérer les problèmes de nestage incorrect (au sens xml/ xhtml) et à ce moment la il suffit d'avoir 2 piles, une principale(1), et une temporaire(2)
- a chaque ouverture d'une balise, tu ajoute cette balise à la pile 1 ( [quote], [b], etc ... ) et tu affiche le code html correspondant.
- a chaque fermeture d'une balise, si celle-ci est est au sommet de la pile 1 tu l'enlève et tu affiche le code html. Si elle est pas au sommet, tu dépile jusqu'a le trouver, en empilant chaque élément dans la pile 2 et affichant le code de fermeture. Tu dépile ensuite l'élément que tu cherchais en affichant le code de fermeture, et ensuite tu vide ta pile 2 tout en rempilant les éléments dans la pile 1 en affichant le code d'ouverture. Si tu trouve pas du tout ton élément dans la pile 1, c'est qu'il y a un code de fermeture en trop donc tu l'ignore et l'affiche tel quel ou engueule l'utilisateur.
 
Avec un tel système tu dois pouvoir te passer de bison. (a mon avis avec bison ce serait chiant de gérer les trucs mal nestés de toute facon).

 
Surtout pas, sinon tu introduis des bug qui peuvent "casser" la présentation de toute la page (c'est déjà arrivé en plus )

 
J'ai du mal comprendre, mais les <span> c'est du coté "final" html, si t'as <span>machin<span>bidule</span>truc</span>, c'est lui qui s'occupe de faire la correspondance, pas toi.
 
Pour les balises BBcode mal nestés, qui effectivement peuvent poser pb, j'ai filé l'algo avec les 2 piles qui me semble correct.

Faut quand même préciser que bison (ou yacc) ne sont pas les seuls parseurs dispos (bon après en PHP je sais pas ce qu'on peut trouver, mais je sais qu'en python il y en a d'autres souvent plus simples à utiliser. bison est quand même orienté grammaires complexes type langages de proc).
 
Mais bon c'est quand même un peu de l'overkill, sortir un truc pareil pour du bbcode

Avec un parseur/analyseur lexical c'est trivial à parser ça

non, mon problème c'est que le WYSIWYG génère :
 
<span style="bold"> </span> pour le gras et <span style="italic"> </span> pour l'italic (c'est un exemple)
et moi je dois reparser ca en code BB
 
donc <span style="bold"> pouet <span style="italic"> plop </span> hop </span>
 
doit être converti en
 
pouet plop hop
 
le problème c'est que le forum converti ca en :
 
pouet plop hop

Clair c'est nettement plus simple

ox90, il faut utiliser un parseur, pas qu'un analyseur lexical

Avec un parseur, ça doit être très simple

oui mais à coup de preg_ ca devient tout de suite bcp plus chiant

D'où le fait qu'on te conseille de passer à autre chose

oué mais passer par un module externe en C, voila quoi, ca fait bizarre, d'autant qu'il faut réinjecter le résultat après parsing dans l'appli php, ca doit être coton

C'est pour ça que les gens te disent de passer à un parseur
 
J'ai pas dit que les parseurs/analiseurs c'était de l'overkill, j'ai dit que Bison/Yacc c'était de l'overkill pour parser du bbcode, mais un parseur solide et de qualitaÿ (chais pas si ça existe en PHP note, en Python ya des trucs genre SimpleParse qui roxxorz grave par contre) avec une bonne récupération des erreurs et le genre de problèmes que tu as avec preg/ereg n'existe même plus.
 
(ton problème devient de formaliser la grammaire et les cas d'erreur en fait )

Nan mais faut que tu trouves un parseur de qualitay pour PHP stou, avec un peu de bol ça existe... peut-être...

http://piif.lautre.net/DEV/placid/readme.html mais je sais pas ce que ça vaut

non mais si c'est fait avec php directement ca sera une usine à gaz c'est même pas la peine d'y penser, je préfère me faire chier avec des preg_

Aerf, j'avais pas pensé au WYSIWYG .... Effectivement dans ce cas il faut un analyseux syntaxique en plus du lexical, et effectivement doit y avoir autre chose que flex/bison, mais j'ai testé le 1er truc que j'avais sous la main et que je connaissais.
Cela dit, niveau intégration ca doit pas être si dur, c'est une fonction  
qui prends en argument un string et qui te ressort un autre string, et sinon pour un premier essai on peut aussi faire un cgi.
 
( je connais mal bison, c'est si gros/lourd que ca comme analyseur syntaxique ? )

Non, ça ne doit pas l'être . Disons que ça doit être trop puissant pour ce qu'il cherche à faire peut être. Mais je dois avouer que je ne connais pas les alternatives.

Pour les BBCode, j'utilises une astuce à la con.
Je fais un premier passage en modifiant les codes clés en rajoutant des caractéres intermédiaires et ensuite, je passe un second coup pour mettre la forme définitive.
J'ai fait comme ça pour pouvoir remettre les codes dans le "alt" de la balise image sans que ca soit retransformé par les codes suivants.

je vois qu'on fait la même chose pour les alt

Et si dans un message on tape les fameux caractères intermédiaires que tu rajoutes, ça risque pas de poser problème ?
 
Sinon, j'ai résolu mon problème de codes de smileys qui en contiennent d'autres. Je vous livre ma solution...
 
Comme tout le monde (je pense), j'ai une fonction bbcode($message) qui retourne le message qui contenait du bbcode après l'avoir transformé en html. Au début de cette fonction, avant tout autre remplacement, je commence par faire un appel à la fonction suivante :
 

 
Etant donné que les messages sont passés par un htmlspecialchars lorsqu'ils ont été postés, on est certain que les codes html rajoutés (et notamment les guillemets) n'étaient pas dans le message d'origine et donc les smileys dans des alt="..." et title="..." ignorés ici sont forcément des smileys qui viennent d'être rajoutés dans du code html donc ils ne seront pas retransformés.
 
$smileys est un array qui contient tous les smileys qui ont été extraits de ma base de données et chaque smiley est représenté par un array (l'ensemble fait donc un array à 2 dimensions) qui contient le code du smiley, le nom du fichier image du smiley et le code du smiley transformé de façon à ne poser aucun problème ni dans du code html ni dans un regex (cette dernière valeur est stockée uniquement pour ne pas avoir à refaire la conversion à chaque message...).
 
Et voici donc le gros morceau qui résoud mon problème et qui est exécuté à l'ouverture de la page de lecture d'un topic et qui ordonne les smileys au fur et à mesure qu'ils sont ajoutés dans l'array décrit ci-dessus de façon à ce que les smileys qui en contiennent d'autres (genre qui contient ) soient traités en premiers.
 

 
Bref, ça marche dans tous les cas auxquels j'ai pensé et que j'ai testés.
ça gère également le cas du qui ne doit pas être transformé si c'est inclus dans un lien genre http:// et à moins que l'admin prenne un malin plaisir à prendre des codes de smileys mal délimités et qu'on peut confondre avec des séquences qu'on retrouve dans des liens ou des bbcodes ça doit marcher.

Maintenant, un truc qui me casse prodigieusement la tête, c'est la coupure des "mots" trop longs.
 
Genre les p'tits malins qui tapent xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx pour avoir des lignes qui dépassent une taille raisonnable en largeur.
 
Le plus chiant étant de ne pas couper en plein milieu d'un code html ou d'un bbcode et de compter correctement les caractères si l'on veut gérer des caractères chinois, japonais ou autre qui bouffe plusieurs caractères car ils sont sous la forme &#nnnnn; (et d'ailleurs veiller à ne pas couper en plein milieu de ces codes.
 
C'est tellement prise de tête que j'ai presque envie de me dire "Oh puis après tout, est-ce vraiment gênant ces lignes trop larges ? "

pour les caractères jap/chinois etc, suffirait de tout passer en UTF-8/UTF-16 non ?

UTF8 ça n'aide pas si PHP ne le gère pas proprement, vu qu'un caractère peut occuper plusieurs octets.
en UTF16 ça marchera, mais est-ce que c'est supporté par PHP ?

Aprés un passage du message en htmlentities, il y a un certain nombres de caractéres qui ne sont plus présent dans le message. J'ai simplement pris l'un deux et je suis tranquille.

C'est la même problème, faut que php comprenne l'UTF. La seule différence c'est qu'en UTF16, tu le vois plus vite si ça marche pas

en peucheupeu y'a des fct d'iconv pour la longueur et le coupage de caractère qui prennent en compte le charset, ca devrait aider il me semble.

En fait, je pense que je vais juste me reprogrammer une fonction wordwrap maison et ça devrait le faire.

Bah il suffit de couper après un octet d'indice impair

J'ai réussi à me débrouiller pour découper les mots trop longs sans toucher à tout ce qui ne doit pas l'être (tags html et codes représentant des caractères spéciaux).
Finalement, des fois, il vaut mieux passer 20 minutes à programmer un truc soi-même plutôt que de passer des heures à chercher comment adapter des fonctions existentes.
 
Il me reste juste un dernier truc à régler : je pensais que les seuls caractères sécables étaient les " ", "\n", "\r" "\t" et "-" mais je viens de constater que les caractères asiatiques (entre autres) - mais pas les caractères arabes - codés par &#nnnnn; sont considérés comme sécables (le navigateur retourne à la ligne quand il arrive sur le bord droit du conteneur) alors que d'autres caractères comme &#034; qui représente des guillemets n'est pas sécable. Et je suis prêt à parier qu'il y a plein d'autres caractères que je soupçonne même pas qui sont sécables.
 
Comment savoir quels sont les codes qui représentent un caractère sécable et lesquels sont insécables ?
Y a-t-il une liste ou une fonction qui renvoie un booléen ?

pé hache pé
 

Je suis peu intervenu dans ce topic, mais si The Real Smiley peut ajouter mon forum : http://forum.tt-hardware.com

 
Added

Merci bien!

ce topic ca devient l'elite des créateurs de forums