TheRec

Que se passe-t-il si tu édites le champ dans la base de données et que tu enlèves tous les caractères sources potentielles du problème (l'affichage à double) ? Si cela ne règle pas le problème je te conseille une petite vérification de ton code..tu as sûrement un echo ou un print quelque part ...sûrement un ancien test de ta part..ça arrive souvent

Hors du contexte de ton site c'est assez dur de voir /c'est à dire sans le code sous les yeux)... Comment affiches-tu le texte entré par le formulaire dans la page qui pose problème ? Es-tu sur que les données dont celle que tu souhaite, vérifie directement dans la base de données (avec phpMyAdmin ou autre)... Es-tu sûr qu'il n'y a pas d'erreur lors l'insertion ?

C'est la magie des magic_quotes, ton serveur, ou plutôt le moteur PHP a ajouté de lui-même les "\" nécessaires grâce au système magic_quotes décrit ici : http://www.php.net/magic_quotes

En fait c'est plutôt "1337" à mon avis (733T signifie plutôt TEET...mais je vois pas), qui est une écriture "coddée" en chiffre pour dire leet (notez la ressemblance des lettres et chiffres) ... la consonnance en anglais est presque parfaite avec le mot "elite", qui signifie (que de suspens) : élite. C'est un language utilisé pas les prétendus gourous du piratage etc... bref pas de quoi s'attarder... ça pourrait presque s'apparenter à du language SMS

Bonsoir, effectivement, si tu souhaites éviter des injections SQL (oui tu le souhaites ! ), il faut procéder comme ceci. Personnellement j'ai écrit ces fonctions et je les utilise en général pour toutes mes requêtes SQL basées sur des données en provenance des utilisateurs. J'ai eu des occasions de les poster prédécemment mais on m'a souvent devancer..alors c'est pour cette fois function sqlString($text) { if(is_null($text)) { return 'NULL'; } else { if(function_exists('mysql_real_escape_string')) { return '\''.mysql_real_escape_string($text).'\''; } elseif(function_exists('mysql_escape_string')) { return '\''.mysql_escape_string($text).'\''; } else { return '\''.addslashes($text).'\''; } } } function sqlNumber($number) { if(!is_numeric($number)) return 'NULL'; else return str_replace(',', '.', (string) $number); } function sqlTrueFalse($value) { if(empty($value) || !is_numeric($value)) return 0; else return 1; } La dernière est a modifier selon les cas, elle retroune toujours une valeur, tu peux estimer que si la vlaeur testée n'est pas numérique (par exemple "true" ou même autre chose) cela applique la valeur NULL..mais j'ai pour habitude de toujours donner du pouvoir au valeur "VRAI" et ne pas donner de pouvoir au "FAUX", donc si la valeur n'est pas renseignée ou n'est pas ce que j'attends elle est mise à faux, à toi de voir comment tu souhaite les utiliser... **EDIT** Si Dan passe dans le coin, la CODEBOX me jour le même tour que la dernière fois... un petit "white-space: pre;" de pas assez quelque part

Cela sent la remarque sexiste un peu quand même Mais comme c'est ta soeur j'espère que ces demoiselles te pardonneront ! Et ce que veux te faire comprendre Dudu c'est que ce qui avantagerais ton site face au référencement c'est la séparation du contenu et de la présentation (CSS). Ce n'est pas à ma connaissance une recommandation telle qu'elle, mais je serais ravi d'être étonné sur ce coup. Mais cette "règle" s'impose de fait, les spécification de XHTML/CSS (peut importe les versions) n'encouragent jamais l'utilisation de styles en dehors des feuilles de styles... enfin c'est ce que j'ai pu déduire de mes lectures (oui j'avoue je ne suis pas au bout de toutes les recommandations..non frappez pas !!! )...

De rien

D'après ce que j'ai compris voilà un bout de code qui pourrait t'aider : $lines = file($filename); // On sort la premier ligne du tableau (la liste des champs) et on en fait un tableau $fields = split(",",array_shift($lines)); // Liste des champs a conserver, on utilisera les id du tableau...on peut faire autrement mais c'est plus dur $fieldsToKeep = array(0,1,2,3,4,5,6,7,8,9); foreach($lines as $key => $line) { // Séparer la ligne en cours en un tableau contenant les valeurs $fields_val = split(",",$line); // Passer chaque valeur en revue et déterminer si elle fait partie d'un champ a conserver foreach($fields_val as $field_key => $val) { if(in_array($field_key,$fieldsToKeep) !== false) { echo "Ligne ".$key." : ".$fields[$field_key]."->".$val."<br />"; // Ici, à la place d'afficher, tu crées ta requête SQL pour la ligne en cours } } unset($fields_val); // Ici tu effectues ta requête pour insérer tes données (celle de la ligne en cours) dans la base } C'est pas joli, il y a plus efficace mais ça reste assez simple a comprendre et j'ai pondu ça en 5 minutes ... je n'ai pas vraiement plus de temps a consacrer à cela désolé

"L'auto-déclaration" de tableaux ne fonctionnent pas dans les class, en tout cas pas sous PHP4 (je n'ai jamais testé cela sous PHP5...un petit tour dans le manuel s'impose peut-être)... Déclare ta variable ainsi : var $errorMsg=array(1 => 't'); Pour le premier problème, apparemment PHP4 ne permet pas de déclaration de constantes de classe... alors que PHP5 selon le manuel lui as cette possibilité : http://php.benscom.com/manual/fr/language.oop5.constants.php Je vais faire quelques recherches et je te redirais... mais garde bien en tête que c'es seulement depuis PHP5 que on considère PHP comme un language réellement orienté objet... PHP4 incluait une bonne partie du modèle objet mais c'était assez incomplet... **EDIT** C'est bien ce que je pensais... Trouvé dans le manuel PHP, dans les commentaires des utilisateurs : Cela signifie pour les "non-shakespeariens", que PHP4 ne permet pas les déclaration de constantes de classe, mais c'est possible depuis PHP 5.0.0 ...pour toutefois utiliser des constantes avec une classe il suffit de les déclarer AVANT la classe en question, elle seront toutesfois accessible sans instancier la classe... mais ça peut être un mal nécessaire...on peu aussi tout simplement passer par une variable, mais c'est du bricolage pour un projet de grande envergure...

C'est bien ce que je dis..si tu nous donnes la structure de ta table (le nom de chaque champ, et que tu nous donnes un aperçu de quelques lignes de ce(s) fichier(s) texte cela nous aidera énormément à mon avis... Une piste serait peut être de simplement séparer ta ligne du fichier texte ($valeur) en un tableau avec la fonction split et de ne prendre que les index qui te sont nécessaires... et ensuite libérer la place utilisée par le tableau issu de split (avec unset)...Cela ne fonctionne que si nous parlons d'une fichier texte avec des champs délimités (par un ";" par exemple)... sinon tu peux avoir un fichier texte avec une largeur fixe de champ, tu devrait pouvoir te débrouiller avec les fonctions de base des chaînes de caractères... et en dernier ressort un fichier n'ayant pas de particulatiré pour séparer les champs...dans ce cas bon courrage...

Je préférerais ce genre de condition de boucle, vu que ta boucle initiale dépend déjà d'une condition : while($cpt <= 5000) A joidre par un && à une autre condition dans la boucle initiale ... mais si tu nous donnes un cas plus précis tu auras une réponse plus précise Pour ta deuxième question, il te suffit de déterminer quelles lignes ne te dont pas nécessaires et je suppose que cela sera en fonction de leur contenu...et au vu du manque de détails sur la natures des données je peux te donner déjà ceci : $tableau = file($fichier); while(list($cle,$val) = each($tableau)) { $tab = explode(",",$val); foreach ($tab as $cle => $valeur) { if(strpos("le contenu que tu ne veux pas",$valeur) === false) { print "tab=". $tab[$cle] ."<br>"; } } } Remplace la fonction "strpos" parce une autre fonction de "recherche", par exemple une fonction se basant sur les expressions régulières (preg_match, ergi, ...)...

De rien ! Remercie sarc aussi , je me suis souvenu avoir utilisé cet outil (oui même si je suis légèrement daltonien ) quand sarc en a parlé, mais j'ai du chercher le lien

Bonjour, Je pense que c'est de cela que tu parles sarc : http://www.nils.org.au/ais/web/resources/c...er/versions/fr/

En effet... vu Googlebot reçoit le header suivant : Status: 404 File not found Il ne va pas indexer cette page... il serait préférable d'envoyer le header suivant (en PHP) : header("HTTP/1.1 301 Moved Permanently"); header("Location: ".$url); header("Connection: close");

Comme on dit chez moi (en Suisse) : Rouge sur rouge rien ne bouge ... (et rouge sur blanc tout fout le camp...), mais cela fait référence à une boission alcolisée à base de raisain en fait Trève de "proverbes", le design du site me plait bien et malgré mes problèmes de vue (leger daltonisme) je n'ai pas vraiement eu de problème avec ces couleurs... si tu tiens vraiement à changer essaie des Color Schemer pour marier tes couleurs : http://www.colorschemer.com/online.html J'aurais juste un remarque à faire au niveau des liens en général, au vu de la quantité de contenu (ce qui est bien), je différencierais les liens visités des liens non-visités par la couleur. Cela permet une navigation un peu plus aisée à mon avis...mais c'est une question de goûts aussi... *EDIT* J'ai cliqué un peu vite sur "Envoyer" ... La mise en page par tableaux (ceux à l'intérieur des <div>) n'est pas la meilleure solution pour la séparation de contenu/présentation qu'implique le XHTML (dans l'absolu), mais tu verra en essayant de réaliser cette mise en page avec CSS tu vas vite apprendre et tu y prendra goût (si ça t'intéresse évidemment).

Oui...et comme je l'ai pointé dans un message précédent, il a très souvent abus de langage entre standards et recommanations (de ma part aussi). A savoir que le W3C ne s'érige pas en dictateur des technologies Internet, mais comme organisme de rationnalisation celles-ci. Cette rationalisation a en définitive un but (vous me direz, c'est souvent ce qui dirige le monde), la réduction des coûts de conception et d'application de ces technologies et non de développer un religion. Il est bien connu (en tout cas pour les chefs de projet en développement) qu'un developpement cadré, sructuré, organisé, bref suivant des "normes" de développement est beaucoup plus productif que une programmation "à la volée" qui peut mener loin mais qui est rarement évolutive... Le W3C n'a sûrement aucunement l'intention d'imposer ses préceptes mais ils pensent également que comme tous les standards (je vous l'avais dit que j'en abusais aussi moi !) leurs recommandations s'imposeraient de fait...

Oui, mais j'ai l'avantage d'être "handicapé" à ce niveau sarc... C'est un détail pour celui qui voit bien...mais ça peut devenir vraiement pénalisant pour des trichomates anormaux sans parler des dichromates...

Oui, joli boulot. Je ne vois qu'un autre point que Dudu n'a pas évoqué. Je n'ai pas 10/10 chaque oeuil (ça serait plutot 8/10 à droite et 9/10 à gauche) et j'ai un léger daltonisme ... et le gris foncé sur le gris "clair" ne me convient pas lors d''une lecture prolongée... À mon avis tu devrais augmenter un peu le contraste entre le fond et la couleur du texte.

Je n'ai jamais dit que tu faisait du bourrage de crâne, loin de là... tu as une manière posée et assez ouverte de présenter les choses. Et je ne pense pas que je n'en fasse non plus :S Je parlais simplement du fait que la confirmité avec les standards n'était pas qu'une passade/mode/argument de vente et que la vision du W3C ne se limitait pas uniquement au 5 prochaines (par exemple) années. Je me doute que tu as conscience de cela... Mais je pense (et ça n'engage que moi) que beaucoup des W3C-septiques ne se représentent pas la vision du W3C ainsi, mais plutôt comme un "tue la créativité"...Évidemment les tableaux ont des possibilités qui sont plus compliquées à réaliser avec CSS, mais ils faut aussi se dire que CSS reste plus jeune qu'HTML et que à partir de CSS 3 beaucoup des lacunes seront comblées...et donc en quoi cela serait-il un mal de se préparer à l'évolution logique du Web...

La portabilité d'un programme/script n'a rien a voir avec son efficacité, mais en fait à l'aptitude de celui-ci d'être changé de serveur/environement sans une relecture complète de son code source. Mais je suis tout à fait d'accord pour dire que magic_quotes est efficace, mais personnellement, et ça n'engage qu moi, je vérifie moi-même les données reçue et je les "échape" ou les traitent en fonction des cas... mais c'est une question d'habitude Mais il est sûr qu'un développeur moins expérimenté (quoi que même un "expert") peut facilement passer à côté d'une faille, mais il ne faut pas penser que tous les cas sont réglés par magic_quote non plus... les failles peuvent venir de pratiquement partout...

Oui..c'est superbe les automatismes, je n'ai rien contre...sauf quand cela nuit à la portabilité du script et ce n'est pas quelque chose de négligeable en programmation à mon avis...et sûrement celui de beaucoup de développeurs... Un peu de lecture sur ce sujet : http://www.phpfrance.com/tutoriaux/index.p...es-magic-quotes Section "5- Pourquoi ne pas utiliser les magic quotes ?"

En mode non hébergé je ne vois pas... Sinon en open-source et hébergé par tes soins il y a cela : http://www.craftysyntax.com/ Le site n'est pas très agréable mais il ne faut pas s'y fier...le système est efficace et pas trop difficile à installer... quoique la traduction française n'est pas très très bonne... Et cela a surtout l'avantage d'être gratuit...

Yep... de rien, mais pour Anonymus (bien qu'il doit sûrement déjà le savoir) il n'y a pas que des avantages en utilisant magic quote. La portabilité du code devient très limitée à mon avis lorsque tu utilises les magic_quotes... mais pour une petite application c'est pas le facteur le plus important...

Bonsoir, cela peut provenir de "MagicQuote", personnellement je n'aime pas trop travailler avec.. Source : http://www.php.net/get_magic_quotes_gpc Si cette fonction te renvoie la valeur "true", tu peux éventuellement essayer de désactiver cette fonctionnalité avec un fichier .htacces et la ligne suivante : php_flag magic_quotes_gpc off Sinon tu peux toujours essayer d'apprendre à utiliser cette fonctionnalité, mais il y a quelques subtilités... à toi de voir : http://www.php.net/manual/fr/security.magicquotes.php

La mise en cache n'intervient pas à cahque indexation selon mes dernières observations ... je suppose que les datacenters seraient assez surchargés. Je suppose, ce fois-ci, que la mise en cache n'intervient pas non plus à la première indexation (mais je ne l'ai pas testé)... La présence de la date sur certaines page et non sur d'autre peut peut-être provenir de l'envoie de l'en-tête HTTP "Last-Modified", mais je ne suis pas sûr. Je t'avoue que je n'avais jamais prêté garde à cette différence ... peut-être auras-tu plus de chance demain avec d'autres sur ce point :S Bonne nuit