petit probleme de regex, ah là là là les regex, quelle galère...

[niahoo]

Oui le BBCode n'a qu'un seul paramètre par balise. Mais bon, rien n'empêche de faire un parser qui en accepte plusieurs.

[Xenos]

Ca ne change en rien son problème de guillemets inclus... faire confiance à l'utilisateur pour qu'il n'utilise pas ' "] ' dans sa balise ALT, c'est pas franchement recommandé, car y'a non seulement les "méchants" pirates et hackeurs qui s'amuseront à bousiller tes balises, mais aussi des erreurs involontaires de frappe, qui planteront aussi (et si l'utilisateur voit que ca plante, il risque de pas revenir, et dès que quelqu'un a vu le bug, il faut environ 48h pour qu'il se répendre et que tout le monde l'essaie "juste pour voir").

[srm]

Je me suis un peu avancé sur la Regex de la version sale, en effet elle ne couvrirait pas tous les cas de façon exactes
Et je confirme et réaffirme tout ce qui a été dit.
Tu dois transformer le ' ou le " (ça dépend le délimiteur que tu choisis) avec un escape, le plus souvent et commun reste le \

[php_addict]

donc alors autant ne pas utiliser ni de ' ni de " non ?

genre [img alt=L'eau ça mouille]

non?

[Myrina]

tu pourrais essayer avec preg_replace_callback; la regexp t'isolant ta balise [img.....] et la fonction faisant du traitement de chaine de caractère (recherche de la sous-chaine comprise entre alt= et ] ou autre_attribut_du_tag_img= )

[srm]

[img alt=L'eau ça mouille more=Elle est ou la fin de alt ?]
[img alt=D'ailleurs alt=text more=ou pas]

[Xenos]

On est forcé d'avoir un système de délimitation de la chaine alt (ou toute autre balise). En effet, imaginez que ] se trouve dans la chaine alt:

[img alt=un crochet] autrebalise=truc]contenu de img[/img]
Ici, "humainement", on se dit "ben, le alt vaut uncrochet] et y'a autrebalise qui vaut truc".

Imaginez maintenant:
[img alt=truc]contenu[/img][img alt=machin]contenu2[/img]
Est-ce que j'ai: 1 image avec alt=truc]contenu[/img][img alt=machin
ou est-ce que j'ai 2 images, une avec alt=truc, l'autre avec alt=machin?

C'est pour cela qu'il faut un système de délimitation.

2 solutions existent généralement:
- Définir un caractère de début et un caractère de fin de chaine, souvent les mêmes, par exemple " ou ' et dans la chaine, remplacer ce caractère par un token équivalent (par exemple, \'). Le caractère de début est parfois facultatif (dans le cas présent, il vaut mieux en mettre un, mais en C++ par exemple, une chaine de char n'a pas de caractère spécial au début, en revanche, elle finit toujours par le caractère 0x00, qui est appelé caractère de fin de chaine)
- Définir la longueur, en octets, de la chaine et stocker cette valeur sous la forme d'un nombre. Cette deuxième solution est assez similaire aux VARCHAR de MySQL. Par exemple, si mon alt contient " test" ", il fait 7 octets de long (2 espaces, 4 lettres, 1 guillemet), alors, dans la balise img, j'enregistre la longueur et le texte:
[img alt_length=7 alt= test" ]
Pour la lecture, on utilise la valeur de alt_length pour déterminer combien de caractères il faut lire après "alt=".
Cette méthode peut néanmoins être peu pratique: imaginez que la valeur de alt soit " alt_length=0", alors, on aurait:
[img alt_value=12 alt= alt_length=0]
Il peut devenir délicat de trouver le "bon" alt_length.

Cette méthode n'est pas un simple "report du problème sur alt_length": en effet, on sait quelque chose sur alt_length qu'on ignore sur "alt": alt_length est un nombre entier non-signé. Donc, pour lire la valeur de alt_length, il suffit de lire les chiffres qui suivent la balise alt_length= et ce jusqu'au premier espace.

Pour ma part, je recommande la 1ere méthode dans le cas présent (caractère de début et de fin, + échappement de ce caractère dans la chaine lorsqu'on crée la balise). C'est d'ailleurs la méthode la plus employée dans les langages type XML: si vous codes en XML (ce qui inclus HTML), vous aurez remarqué que les caractères < et > sont remplacés par &lt; et &gt; : ces caractères délimitent le début et la fin d'une balise, c'est la raison pour laquelle ils sont échappés. Et pour éviter qu'un "&lt;" qui erait écrit volontairement par l'utilisateur, ne devienne "<" à l'affichage, le "&" entré par l'utilisateur est lui-même échappé (en "&amp;" il me semble).