Mesdames et Messieurs bien le bonjour
 
j'aimerais comprendre le fonctionnement d'une expression régulière me permettant de mettre en forme une chaîne toute pourrie en un beau div html.
 
voici ma chaîne :  
ref_player="27351" num_position="" num_played="1" num_time="0" num_goal="0" txt_url="Ligue 1/player/27351" date_year="20,5"
 
ceci est bien sur imbitable sans une belle mise en forme et je voudrais donc le passer dans une moulinette du type :  
 

 
Si vous pouvez m'aider à mieux comprendre ce que je dois mettre pour que ça fonctionne, ça serais super.
 
Bonne continuation.

[0-9] c'est un seul chiffre, déjà.
 
Tu veux [0-9]* ou [0-9]+.
 
Pour date_year pareil avant la virgule, et t'oublies de matcher après la virgule...

Quel est la différence profonde entre [0-9]* et [0-9]+ ?
 
Par rapport à  la virgule... En fait, le chiffre n'a pas forcément de virgule... ça peut être '20,9' ou '20', tout court.

http://www.expreg.com/
Bonne lecture.

Merci skeye !!
 
après lecture, je met donc à jour ma ligne de commande :  
 
ref_player="([0-9]+)" num_position="" num_played="([0-9]+)" num_time="([0-9]+)" num_goal="([0-9]+)" txt_url="(.*?)" date_year="([0-9|0-9,0-9]+)"
 
Je sèche encore sur le 20,1 ou 20...
 
de plus, je me demande si je dois échapper les " qui sont dans la chaîne ?

Oui, par un \

=>

 
Pour ton pb de date_year si tu veux accepter les entrées suivantes : 20,1 ou 20 ou 0,1 utilise le pattern suivant :

Qui correspond à : "un ou plusieurs chiffres et éventuellement une virgule suivie d'un ou plusieurs chiffres"

Super, merci beaucoup superbob56 !!
 
voici donc ce que j'ai maintenant :  
 
  $pattern = "ref_player=\"([0-9]+)\" num_position=\"\" num_played=\"([0-9]+)\" num_time=\"([0-9]+)\" num_goal=\"([0-9]+)\" txt_url=\"(.*?)\" date_year=\"([0-9]+(\,[0-9]+)?)\"";
  $replace = "<div><span class=\"toto\">$1</span></div>";
  echo "hello" . preg_replace( $pattern, $replace, $string ) . "<br />\r\n";
 
j'ai pas mon div, mais j'ai bien mes 'hello' qui s'affichent...
 
Je ne vois pas pourquoi, car ça à l'air ok là, non ?

Est-ce vraiment top une telle regexp pour ce genre de cas ? Genre suffit que deux attributs switchent de place et ça pète

 
Bel effort, maintenant il va te demander de lui écrire la version qui résout ce problème

Oui, FlorentG, mais disons deux choses
 
1- Je ne suis pas vraiment responsable de la création du 'pattern' et donc si deux attribut switchent, je n'y serait pour rien en cas de non fonctionnement ultérieur
 
2- Même si on part de l'hypothèse (insensée, je le conçoit) que rien ne changera jamais, l'exmple ne fonctionne pas...
 
Point positif, j'ai appris un peu plus sur les expressions régulières
 
Donc, si quelqu'un voit pourquoi ça fonctionne toujours pas ?

ah ah ah esox_ch => même pas en fait

Pour être sûr, affiche les trois chaines pattern, replace et string pour vérifier que l'échappement se fait bien et que rien n'a été oublié
Et puis essaye progressivement, juste la partie ref_player="([0-9]+)" pour commencer et continue petit à petit.

Sinon nettement plus simple/propre/efficace/ tu mets ça dans une balise, genre :

<player ref_player="27351" num_position="" num_played="1" num_time="0" num_goal="0" txt_url="Ligue 1/player/27351" date_year="20,5" />

 
Pis t'utilises http://simplehtmldom.sourceforge.net/ pour parser les attributs.

<player ref_player="27351" num_position="" num_played="1" num_time="0" num_goal="0" txt_url="Ligue 1/player/27351" date_year="20,5" />

euh là c'est plus du tout du html que tu génères, hein...

 
C'est du XML valide. Le truc le gère aussi, même quand y a pas d'entête ni rien.

oui, mais les navigateurs ne sont pas censés savoir quoi en faire au milieu d'une page html, et peuvent te faire péter la page à la gueule s'ils en ont l'envie.

 
Nan mais il transforme ça dans son PHP en mémoire pour pouvoir récupérer ses attributs proprement et créer son div, personne n'a parlé d'afficher ça tel quel.

mais bien sûr, il va générer du html non conforme en mémoire pour pouvoir le re-parser en php sans jamais l'afficher. Va falloir que tu m'expliques ce que tu fumes toi hein...

 
Mais c'est pas du HTML robert, on parle de XML là, toi me lire (ou la doc du truc sinon, au choix) ?  
 
Il a sa chaîne (je sais pas d'où il la sort d'ailleurs, mais on s'en cague un peu), il s'aperçoit qu'elle ressemble vachement à une liste d'attributs XML, donc il transforme ça en tag XML, et il parse avec un vrai parseur de XML fait pour ça. Et il a la valeur de ses attributs sans aucune regexp, sans qu'un \" ou qu'un ordre différent des attributs vienne foutre le bordel. Ensuite il crée son div dans sa vue comme un grand.
 
J'peux te faire un dessin, si tu préfères.

1) Je m'appelle pas robert.
2) Tu es le seul à parler de xml, là. Lui il a une chaine de caractères, il veut en extraire des valeurs avec une regexp. Ta solution c'est d'ajouter une lib supplémentaire et de bidouiller pour lui passer des infos au format qu'elle attend? Et tu appelles ça "simple/propre/efficace"? C'est une blague?

 
C'est pas parce qu'il nous parle de regexp que c'est la bonne solution. En l'occurence, pour parser un truc qui ressemble de près ou de loin à de l'XML, c'est relativement merdique.  
 

 
La bidouille, c'est d'utiliser des regexp pour extraire des infos d'un format qu'on peut parser avec un vrai parseur fait pour ça.  
 
La bibliothèque est légère, peut lui servir dans pleins d'autres cas similaires, lui permet de ne pas se prendre le chou avec des choses genre un \" au milieu de ses attributs (ça doit être joli à gérer en regexp) ou leur ordre (sympa aussi), tout en produisant du code environ 52 fois plus lisible et certainement au moins aussi performant.

 
Tu crois qu'elle fait comment ta lib?
Allez, je l'ai même récupérée pour regarder, c'est cadeau :
 

protected function match($exp, $pattern, $value) {
        $check = true;
        switch ($exp) {
            case '=':
                $check = ($value===$pattern) ? true : false; break;
            case '!=':
                $check = ($value!==$pattern) ? true : false; break;
            case '^=':
                $check = (preg_match("/^".preg_quote($pattern,'/')."/", $value)) ? true : false; break;
            case '$=':
                $check = (preg_match("/".preg_quote($pattern,'/')."$/", $value)) ? true : false; break;
            case '*=':
                $check = (preg_match("/".preg_quote($pattern,'/')."/i", $value)) ? true : false; break;
        }
        return $check;
    }
 
protected function parse_selector($selector_string) {
        // pattern of CSS selectors, modified from mootools
        $pattern = "/([\w-:\*]*)(?:\#([\w-]+)|\.([\w-]+))?(?:\[(!?[\w-]+)(?:([!*^$]?=)[\"']?(.*?)[\"']?)?\])?([, ]+)/is";
        preg_match_all($pattern, trim($selector_string).' ', $matches, PREG_SET_ORDER);
 
 
 
  function __construct($str=null) {
        if ($str) {
            if (preg_match("/^http:\/\//i",$str) || is_file($str)) 
                $this->load_file($str); 
      
 
etc etc etc

 
C'est sûr qu'ajouter une lib non officielle consistant en une grosse classe de 900 lignes ça va être vachement plus performant que de faire exactement le bout de code dont il a besoin, tout en en profitant pour apprendre à se servir d'un outil.

Mais on s'en tamponne de son implémentation, à la bibliothèque.      
 
Elle parse proprement le truc, avec des performances parfaitement honorables, et une API python-like hyper bien foutue et qui permet d'avoir un code lisible, maintenable et adaptable, et qui se vautre pas lamentablement si t'as oublié qu'il pouvait y avoir plus d'un espace entre chaque attribut ou qu'un \" pouvait venir foutre le bazar.
 
Après si tu préfères gagner 3 centièmes de seconde pour t'amuser avec des regexp bancales et qui prennent 2 minutes à relire/adapter c'est toi qui vois.    (Ou lui, en fait.)
 
Mais vas-y fais toi plaisir et sors nous donc l'expression qui prend tous les cas en compte.

Le seul truc que tu oublies, c'est qu'il a pas du xml, et encore moins 'nimporte-quel xml en entrée. Il n'a pas tous les cas à gérer, il a juste ceux qui l'intéressent. Et ta lib n'offre absolument aucune garantie de fonctionner, c'est un projet sourceforge d'un mec dans son coin, le jour où ça t'explose à la gueule sans prévenir parce-que le mec a pas prévu un cas tu l'as dans le cul.
Bref.

 
$string = '<player ' . $string . ' />'; ça me paraît pas dramatique comme truc à avoir à faire avant de parser. Après, ça dépend d'où vient la chaîne, y a certainement un meilleur endroit pour le faire.
 

 
Bah rien ne t'empêche d'aller la modifier, le code est clair et loin d'être sorcier (et de prévenir l'auteur d'ailleurs, c'est un projet actif, la dernière release doit dater de deux mois max edit: ouais voilà, 25 octobre).

Ah oui c'est vrai c'est tout de suite vachement plus simple que de faire le truc adapté à son problème.

 
Donc selon toi y a + de chances qu'une bibli qui fait un parsing générique propre et qui existe depuis PHP4 "oublie un cas" qu'un script écrit à l'arrache qui essaie tant bien que mal de gérer N cas spécifiques ?
 
Ben voyons.

 
non, d'après moi utiliser une lib qu'on ne maitrise pas, dont on ne connait pas la qualité et qui n'est de toute manière pas faite pour résoudre le type de problème qu'on a n'est pas une bonne idée, point barre.

 
Donc t'étudies le code source de toutes les biblis que t'utilises quand tu dév ?  
 
Parce que si tu parles de maîtrise de son API, y a vraiment rien de plus simplissime, franchement, je pense que ça se maîtrise "un peu" plus vite que les regexp, du coup.
 
Quant au "pas fait pour", no comment vu la solution que tu préconises, mais bon bref, on en a déjà causé et ça tourne en rond.

 
Non. Mais je n'utilise pas des libs faites par des gens que je ne connais pas, dont je ne connais pas les compétences, et qui ne sont supportées par aucun organisme pseudo-officiel. Ce n'est pas parce-qu'un projet est hébergé sur sourceforge qu'il mérite une confiance aveugle, loin de là - les mainteneurs ce ces projets peuvent disparaitre du jour au lendemain sans que tu saches pourquoi et sans que personne ne les reprenne, t'auras juste l'air d'un con si ça ne marche pas comme prévu.

Personne n'a dit que la bibli était fiable à 100% ou qu'il fallait faire confiance à sourceforge. Y a évidémment un risque, mais là en l'occurence il s'agit d'un projet actif, on sent que le mec assure un minimum, qu'il a pensé à son API, qu'il sait coder, qu'il sait ce qu'il fait. Du reste, je l'ai souvent vue recommandée dans des forums (anglophones pour la plupart) par des gens qui n'avaient pas non plus l'air d'être des truffes.
 
Je suis pas personellement fan de l'utilisation massive de libs de ce genre, mais y a parfois des perles et je vois pas pourquoi faudrait nécessairement se priver, quand le gain (ici en lisibilité/maintenabilité/rapidité de code) est significatif.

Ça donnerait ça (non testé) :

$player_tag = '<player ' . $input_string . ' />';
$xml = new simple_html_dom();
$xml->load($player_tag);
$player = $xml->first_child();
// Voilà, tout est dispo dans $player->ref_player, $player->num_position, etc

Ca ne fout pas le bazar, vu que \" n'existe pas en XML. On utilise &quot; pour escaper

'fectivement.