Fatal error et réaffichage champs Formulaire Résolu/Fermé

Question

Bonsoir, Je saisis et contrôle par formulaire HTML et vue d'enregistrer en BD MySQL. Ces 2 opérations sur la même page se font en donnant comme action au Submit la page elle-même sur laquelle on se trouve. Deux problèmes se posent alors : En cas d'erreurs, les champs restitués ne sont restaurés que pour la première sous-chaîne ; ainsi, "Rue des Dragées" ne sera repris que par Rue ; Second problème, peut-être plus grave, en l'absence d'erreurs, le traitement se poursuit sur une autre page chargée d'écrire l'enregistrement ; pour autant, j'obtiens une "Fatal error : Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'anais' cannot be null' in /web/utlsudgoelo/www/pgUTL/traitformul.php:33 Stack trace: #0 /web/utlsudgoelo/www/pgUTL/traitformul.php(33): PDOStatement->execute(Array) #1 {main} thrown in /web/utlsudgoelo/www/pgUTL/traitformul.php on line 33 Le champ signalé "anais" contenait lors de la saisie 1945 mais semble réputé NULL ! Un constat (à travers quelques dizaines d'essais) : en revanche, si... je contrôle ma page comme prévu mais, au lieu de boucler sur elle-même pour les corrections je modifie l'adresse de la page ciblée par le Submit et l'écris directement dans la page déjà évoquée (où j'ai la "Fatal Error"), l'enregistrement s'écrit parfaitement par cette même page HTML (sans zones amputées). Bien entendu, ce n'est qu'une observation car cette solution ne peut me convenir (sans correction des zones réputées incorrectes) pour des saisies par des internautes ! Conclusion (peut-être hâtive) : ça semble bien être la réécriture par écho (qui déjà me splite la fin de mes champs) qui serait là encore la cause des désordres ? Il ne faudrait pas que cet "à priori" fasse de l'ombre à une saine recherche de la réalité. Je joins la manière dont je contrôle et réaffiche les champs (les contrôles ont été "simplifiés et surtout expansés face à des difficultés par ailleurs) : Code : /> Merci de votre aide pour un domaine où mes toutes récentes acquisitions (PHP, MySQL et PDO) ne peuvent me permettre de me confronter. RJL2805 Configuration: Windows 7 / Firefox 14.0.1

Utilisateur anonyme · Answer

Bonjour

Concernant le premier problème, il n'y a aucune raison pour que le champ restitué soit tronqué. Ni l'envoi par POST, ni le echo ne tronquent les chaînes. Tu dois faire quelque part un traitement qui les coupe, ou le input est trop petit et tu ne vois que le début.
ça semble bien être la réécriture par écho (qui déjà me splite la fin de mes champs)  Non echo ne splite rien du tout.

Concernant le second problème, c'est que ta requête est mal écrite ou plus probablement que tu ne lui passes pas les bonnes valeurs. Vérifie quelle valeur tu essayes de faire correspondre au champ anais, (éventuellement fais un echo de sa valeur juste avant l'execute). Ce n'est sûrement pas 1945, mais NULL s'il te le dit... Si tu ne comprends toujours pas, montre le code avec la requête et l'appel à execute.

rjl · Answer

Bonjour le père, C'est toujours une joie de te voir t'associer à mes soucis ; je suis de ton avis : ce n'est pas possible et pourtant tous mes tests en attestent sans intervention de ma part (en général avec édition des champs soit juste avant ou juste après redirection) ! Après avoir bouclé par le Submit sur le module lui-même (FormPreInsc.php), je redirige vers un module qui fonctionne, lui-même, parfaitement pour l'écriture des enregistrements $reqprepare=$connexion->prepare("INSERT INTO adh (anais, civil, nomadh, prenom, ad1, ad2, cpost, ville, tfixe, tmob, admail, MaJ) VALUES (?,?,?,?,?,?,?,?,?,?,?,CURDATE())"); $succes=$reqprepare->execute(array($anais, $civil, $nomadh, $prenom, $ad1, $ad2, $cpost, $ville, $tfixe, $tmob, $admail)); J'ai alors la Fatal Error déjà citée ! En bloquant avant l'écriture avec affichage des champs transmis (y compris des séparateurs "--"), j'obtiens en affichage de cette transmission (via le META) : tout est NULL ! Array ( [0] => [1] => [2] => [3] => [4] => [5] => [6] => [7] => [8] => [9] => [10] => [11] => [12] => [13] => [14] => ) En appelant directement le module enregistrement (traitformul.php) donc sans passer par réaffichage, ni META je trouve alors : Array ( [0] => 1945 [1] => -- [2] => M. [3] => -- [4] => RICARDO DI LOPEZ [5] => -- [6] => Lo?c [7] => -- [8] => 72 rue des Broches [9] => -- [10] => n? 72 [11] => -- [12] => 76000 [13] => -- [14] => ROUEN LES ESSARTS ) L'écriture sur la BD (sans bloquer juste avant) donne le message : Enregistrement réussi avec contenu base : image 2806.jpg où j'ai du accidentellement saisir 76 au lieu de 76000 ! [IMG]http://img856.imageshack.us/img856/158/bd2806.jpg/IMG Enfin, en ciblant ce même traitement (et module traitformul.php via un réaffichage à travers le Submit cyclant sur le même page FormPreInsc.php) et en se déroutant immédiatement sur le module traitformul via le META, j'obtiens en bloquant juste avant l'enregistrement (pour éviter Fatal Error) : Array ( [0] => 1945 [1] => -- [2] => Mme ; [3] => -- [4] => RICARDO [5] => -- [6] => Lo?c [7] => -- [8] => rue [9] => -- [10] => n? [11] => -- [12] => 76 [13] => -- [14] => ROUEN ) Les champs 4, 6, 8, 10 et 14 étaient tous composés de 2 strings dont seul le premier est récupéré ; le champ 12 est à 76 au lieu, par exemple de 76000 pour générer une erreur évitant la redirection et le Fatal Error ! C''est pour le moins surprenant et je vais donner le code, sachant que les redirections ne reflètent que l'état au moment de sa saisie. Code redirection par META : session_start(); // Ouvrir la session $npass = $_SESSION['npass']; $erreur= $_SESSION['erreur']; $_SESSION['npass']=$npass + 1 ; ?> Pre Inscriptions 1)) { echo ""; exit; } include ("DoctPagesUTL.php"); Merci de ton appui ; à ta disposition pour pousser ces tests si nécessaire mais je crois qu'une large part des possibilités sont présentées. Amicalement RJL2806

Utilisateur anonyme · Answer

Après avoir bouclé par le Submit sur le module lui-même (FormPreInsc.php), je redirige vers un module qui fonctionne,
Comment ça tu rediriges ? Vers une nouvelle page ? Mais alors, cette nouvelle page ne reçoit aucun formulaire ! Normal qu'elle ne retrouve aucune des valeurs saisies...

rjl · Answer

Bonsoir, Tu as tellement répondu vite que, par l'heure, j'ai confondu avec mon message (sans ouvrir) ! Bon, il y a problème : je me suis basé sur un tuto qui fait le Meta de redirection pour affichage : je ne vois pas comment il afficherait ce qui a été saisi sans transmettre les données... même si le mécanisme m'échappait. Le tuto est celui-ci : Les formulaires et les envois de paramètres www.info-3000.com/phpmysql/formulaireredirection/index.php Voici la base du Meta : Mais, j'avais mal lu ou pas intégré initialement (car il y a 5 pages A4 ; or ce soir, je lis ce que j'avais raté et le mets en évidence: "c'est le META ! Alors, attention ! Les variables $Nom et $Prenom ne seront pas transférées ! ' Il faut donc remplacer echo ""; par echo ""; Alors, merci de m'avoir permis cette lecture plus attentive te qui plus est m'avoir fait mieux toucher du doigt ce "détail" du Meta http-equiv Comme quoi, rien n'est évident, ni immédiat pour moi... Bilan, plus que 10 ou 12 champs à ajouter et transférer ; c'est un détail . Merci encore une fois pour ce dépannage superbe. RJL2807

Utilisateur anonyme · Answer

Il faut donc remplacer echo ""; par echo ""; C'est une façon de faire, mais certainement pas la meilleure à mon point de vue. Personnellement, j'ai l'habitude de traiter complètement la réception du formulaire dans la même page que l'envoi du formulaire. Ça simplifie bien les choses si tu t'aperçois que les données sont incorrectes et qu'il faut renvoyer le formulaire. La redirection ne vient en général qu'après, quand le formulaire a été correctement traité et qu'on veut passer à autre chose. Ensuite, j'ai l'habitude de faire la redirection par la fonction header de PHP. (header("Location: resultat.php"); AVANT tout envoi de données donc AVANT le ) plutôt que par une balise meta. J'avoue que j'aurais du mal à en donner une justification inattaquable. Surtout, pour passer des informations à une autre page, éviter d'en mettre une douzaine dans l'url (que tu récupéreras par $_GET, pas $_POST, attention !). Il est bien plus simple de les passer par $_SESSION. L'idéal étant d'en passer le moins possible, je te conseille de tenir compte de ma première remarque et de faire tout le traitement dès la réception du formulaire.

rjl · Answer

J'avais préparé une réponse et fait des essais avec ... ma douzaine de champs transmis ! J'avais aussi préparé des photos mais je range cela soigneusement dans ma poubelle (heureusement sans fond) !

Cet AM, je modifie toute la transmission non via le GET (j'ai aussi glané cela car il faut se tromper pour mémoriser ? ... et encore, souvent, je me souviens avoir déjà eu tel problème... mais retrouver la solution, c'est autre chose ! C'est alors que je reparcours les questions que j'ai déjà posées...) mais via $_SESSION()  et je reprends mes tests !

Merci et @bientôt      RJL2807

rjl · Answer

Dur, dur d'y voir clair...

En première lecture, j'avais saisi (bien que l'ayant déjà lu) que POST était pour émettre et GET pour réceptionner ; bien sûr, j'ai récupéré une gamelle pour être rappelé à l'ordre ! Du coup, je ne vois pas ce que GET pourrait m'apporter de mieux ?

Pour l'utilisation de  $_SESSION, pas de difficulté pour alimenter mais, tel que je vois les choses, il faut en revenant dans la page (par GET ou POST) que je réalimente au moins mes zones correctes avec $_SESSION... et là, je ne sais pas faire ; si je ne le fais pas, comme dans mes essais, dans le formulaire réaffiché, elles sont tronquées !

Après plusieurs essais, je pense faire fausse route : tout va de mal en pis ! Ainsi, maintenant le passage de paramètres au module traitformul est faux : traitformul.php?anais=&civil=&nomadh=&prenom=&ad1=&ad2=&cpost=&ville=$&ville&tfixe=&=&admail= ; (tmob n'avait pas été renseigné !

Déroutement actuel par le nombre d'erreurs :	if (($erreur==0)and ($npass)>2) {
		echo "<meta http-equiv='refresh' content='0; url=traitformul.php?anais=$anais&civil=$civil&nomadh=$nomadh&prenom=$prenom&ad1=$ad1&ad2=$ad2&cpost=$cpost&ville=$&ville&tfixe=$tfixe&$tmob=$tmob&admail=$admail'>";
		exit;  }
Réception actuelle dans la page elle-même si recyclage par Submit :	$ad2=utf8_decode($_POST['ad2']);
	$civil=($_POST['civil']); 
	$ville=utf8_decode(($_POST['ville']));
Petit problème (sur le module "traitformul.php"sur l'utilisation de $_GET et Array qui exigent un string :	$ville=utf8_decode(($_GET['ville'])); 
	$tfixe=("$_GET('tfixe')");
	$tmob=("$_GET('tmob')"); 

Si j'interdis le déroutement par des zones erronées, le réaffichage (en l'état actuel) est tronqué.

Merci de ton appui plus nécessaire que jamais car je désespère.       RJL2807

Utilisateur anonyme · Answer

En première lecture, j'avais saisi (bien que l'ayant déjà lu) que POST était pour émettre et GET pour réceptionner ; bien sûr, j'ai récupéré une gamelle pour être rappelé à l'ordre ! Du coup, je ne vois pas ce que GET pourrait m'apporter de mieux ? 
Ça commence très mal... aucun rapport.
J'essaye de résumer la différence entre POST et GET :
Les données mises dans l'url (http:monsite.com/page.php?donnee1=valeur1&donnee2=valeur2) sont envoyées par GET
Les données figurant dans un formulaire peuvent être envoyées par GET ou POST au choix selon ce que tu as mis comme attribut "method" dans ta balise FORM
Les données envoyées par GET sont reçues dans le tableau $_GET en PHP et les données envoyées par POST sont reçues dans le tableau $_POST.
Voilà pour le premier point. Je lis la suite et je reviens.

Utilisateur anonyme · Answer

module traitformul est faux : traitformul.php?anais=&civil=&nomadh=&prenom=&ad1=&ad2=&cpost=&ville=$&ville&tfixe=&=&admail= ; (tmob n'avait pas été renseigné ! 
Commençons par le commencement... Redonne le code du formulaire. Tant que traitmodul.php ne recevra pas des données correctes, le reste ne risque pas de marcher.

rjl · Answer

Je viens seulement de trouver ton message de 15h36 alors que ma réponse est prête avec des modifs bien engagées... J'ai de ce fait travaillé sur tes conseils de 9h 69 ! J'ai tenté de progresser et mis en place les variables SESSION associées aux champs à instruire, ... Je n'ai pu faire d'essai retombant au moment sur des Parse Error (temps que je pensais révolu) mais la dernière viens en ligne 117 avec l'affichage du formulaire : Fatal error: Call to a member function prepare() on a non-object in /web/utlsudgoelo/www/pgUTL/FormPreInsc.php on line 117 J'ai donc abandonné le module traitformul où j'allai (ou non) suivant que je remplissais le formulaire avec (ou sans) erreur ! Comme tu le préconises, je communique le code de l'unique module puisqu'il doit maintenant écrire la BD, mais c'est 140 lignes (problème avec une édition sans ascenseur ni n° de ligne). La ligne 117 bloquante est soulignée et en gras... Pire, je me ssius permis de poser 3 ou 4 questions en commentaires (elles sont soulignées en lignes 108 à 110 et 114)! Voila la dernière situation ; ci dessous c'est uniquement du code. Code du module FormPreInsc.php Pre Inscriptions 2) { // echo ""; // exit; } include ("DoctPagesUTL.php"); ?>

Mis à jour le 06/08/2012
par RJL
_____________
Site optimisé
768x1024 pixels

Formulaire : Toute donnée associée à un astérisque (*) est obligatoire

Coordonnées

An naiss. * aaaa : 1) { // if (strlen($anais) != 4) $anaisX=1; if ($anais != $anaisC) $anaisX=2+$anaisX; if ($anais < $ancour - 100) $anaisX=4+$anaisX; if ($anais > $ancour -25) $anaisX=8+$anaisX;} if ($anaisX > 0) $message .= "Année naissance non conforme
"; ?> /> Civilité : M. Mme (Clic => bouton devant M. si homme)
Nom *.................. : > ............................ Prénom * ........... : >
Adresse * ........... : >.............................. Adresse suite : >
Code Postal * .... : 1) { $cpostC = $cpost; $cpost = intval($cpostC); if ($cpost != $cpost) $cpostX=$cpostX+32; if (($cpost <1000) or ($cpost > 95999)) $cpostX=$cpostX+64;} if ($cpostX>0) $message .= "C. Postal incorrect
"; //?> /> .................................................................... Ville * ................ : >
Téléph. Fixe........ : /> .....aucun espace entre les chiffres des N°....... Téléph. Mobile : />
e-mail.................. : />

prepare("INSERT INTO adh (anais, civil, nomadh, prenom, ad1, ad2, cpost, ville, tfixe, tmob, admail, MaJ)"); $succes = $reqprepare->execute(array('anais=>$anais, civil=>$civil, nomadh=>$nomadh, prenom=>$prenom, ad1=>$ad1, ad2=>$ad2, cpost=>$cpost, ville=>$ville, tfixe=>$tfixe, tmob=>$tmob, admail=>admail')); if($succes == 1) $_SESSION['Msaf1'] = "Enregistrement réussi"; else $_SESSION['Msaf1'] = "Erreur de requête"; echo $_SESSION['Msaf1']; $_SESSION['Msaf1'] = " "; Header("Location:/pgUTL/identifK.php"); // IdentifK exit; } $_SESSION[anais] = $anais; $_SESSION[civil] = $civil; $_SESSION[nomadh] = $nomadh; $_SESSION[prenom] = $prenom; $_SESSION[ad1] = $ad1; $_SESSION[ad2] = $ad2; $_SESSION[cpost] = $cpost; $_SESSION[ville] = $ville; $_SESSION[tfixe] = $tfixe; $_SESSION[tmob] = $tmob; $_SESSION[admail] = $admail; ?>

Utilisateur anonyme · Answer

Je lis le début :
 $nomresp = $_SESSION['Login'];
Mais pour l'instant, $_SESSION['Login'] et tes autres variables de session n'existent pas encore... Il faut tester l'existence de $_SESSION['Login'] avant de s'en servir. Par exemple : 
$nomresp= isset($_SESSION['Login'])?$_SESSION['Login']:'inconnu'; 
 
$anais= $_SESSION[anais]; Tiens ! À partir de anais, tu oublies les ' autour de 'anais'.
idem plus loin avec echo ($_SESSION[anais]) et les autres.. C'est $_SESSION['anais'] 
$nomadh=utf8_decode($_POST['nomadh']). Là encore, lors du premier passage,$_POST['nomadh'] n'est pas défini puisque personne n'a encore cliqué sur le bouton submit. Tu devrais faire ce traitement AU DEBUT du script, dans un if (isset($_POST['envoi'])) qui vérifie que le formulaire que tu veux traiter a bien été saisi.
Je ne parle pas du utf8_decode qui est aussi une erreur, l'encodage est un autre sujet.

Ligne 123 : il y a du code derrière un exit, il ne sera jamais éxécuté.

Pourquoi essayes-tu de faire d'abord marcher un formulaire de 3 lignes au lieu de te lancer dans un truc compliqué ? Tu gagnerais du temps.

rjl · Answer

Bravo pour cette analyse rapide et pertinente  ; je réponds par points.

Effectivement, dans ces traitements, il y a beaucoup de choses que tu ne vois pas ; ainsi j'ai actuellement sur ce site une bonne quinzaine de pages dont les 2 tiers fonctionnent ; Exemple pour authentifier mes visiteurs, je suis sur une page notée d'accès réservé, qui demande Login et PassWord pour transmettre à un second module ; celui-ci vérifie sur une bas que j'ai chargée si la personne existe ou non et quels sont ses droits (les fameuses initiales). Dans les premiers modules je vérifiais pour renvoyer à l'accueil les personnes accédant à un module sans droits ; actuellement, pris par des questions de temps, je diffère cet ajout.
De même, tu ne verras pas nécessairement les remises à zéro de certaines donnes SESSION comme par exemple pour le npass (numéro de passage dans le module sur lequel nous sommes) : il est nécessairement dans le module qui lui donne accès la première fois pour un nouveau cycle.
Pour une meilleure compréhension, je te joins en image une page sur laquelle je gère mes relations entre page : elle n'est pas finalisée car susceptible de bouger d'où en bas à gauche ces boîtes en réserve (textes compris).
[IMG]http://img444.imageshack.us/img444/8238/bd2808pp.jpg[/IMG]

Donc le Login est bien testé pas cependant par le isset que je n'ai pas pris habitude d'utiliser (ça va venir) mais, je n'ai pas 3 mois de PHP, PDO ou MySQL !).

$_SESSION['anais'] : encore une remarque pertinente qui m'a entrainé 24 ou 36 corrections... ce qui ne me gène en rien car j'exécute alors souvent par recherche et remplace (plus fiable et rapide) d'où ma manière de travailler car, oui, je suis dans l'urgence (et oui, même en bénévolat, ça existe). Mais, j'ai habitude de travailler sur plusieurs tâches à la fois et je participe (en pente douce actuellement)  au  Conseil des Sages de ma commune, je vais avoir vers le 20 août à finaliser la mise en page de la revue trimestrielle des Aînés Ruraux de mon département dont je gère de + en + loin le site Internet (statique) que j'avais créé il y a 4 ans. Bien s^r, aujourd'hui, j'ai surtout l'UTL (Université du Temps Libre) avec d'ailleurs un CA le 21/08 et dont je suis secrétaire pour mon canton. Ainsi, c'est pour moi plus simple d'avancer en réel que relancer plus tard des correction ou ajouts et refaire une batterie de tests d'autant que c'est une bien vieille habitude (pas bonne mais réelle et assez efficace) !

utf8_decode : un point qui me souciait car si tout est déclaré en encodage utf8 (pages et BD), j'ai eu la surprise avec cette application de voir apparaître des signes cabalistiques ! Je les ai résolu avec cette instruction sachant bien que si j'y passe une fois de trop ça crée des problèmes ! Ma difficulté vient du PHP qui gère,  j'ai l'impression en ISO8859-1 en interne... aussi si je corrige une fois, c'est bon mais avec le réaffichage problème d'où la raison pour laquelle je truffe mes saisies de caractères accentues (et par ailleurs de saisies en plusieurs mots) !

Ligne 123 : il y a du code derrière un exit, il ne sera jamais exécuté.  Excellente observation : j'ai ajout devant des échos mais laissé une redirection vers identifK.php qui était chargé à un moment de faire une édition "propre" des messages d'erreur ; j'ai abandonné ce 'luxe' mais laissé à tort ces 2 instructions.

Je pourrai ajouter que je gère très mal les caractères spéciaux à éliminer en escape... je pense m'y appesantir quand le reste fonctionnera... 
Pour le moment, les modifs n'ont pu faire évoluer mon instruction 117 et son parse :
ligne 117 avec l'affichage du formulaire : Fatal error: Call to a member function prepare() on a non-object in /web/utlsudgoelo/www/pgUTL/FormPreInsc.php on line 117 

Merci de ton appui pour cette mauvaise écriture qui m'échappe.    RJL2808

rjl · Answer

Bonjour le père,

J'étais sans doute un peu fatigué hier par plusieurs sujets qui cafouillaient mais je ne voudrai pas t'avoir choqué en essayant de te présenter comment je fonctionnais.
Surtout, je ne voudrai pas ajouter à ta charge.
Le sujet qui nous occupe est ma grande priorité et j'y passe mon temps dès que je peux avancer par des tests, du développement ou d'autres idées à essayer.
Me  gène toujours les kilos de code qu'il faut afficher d'où, parfois mes extraits (éliminant si possible les lignes répétitives) ;
Par contre, dis moi comment tu souhaites que je travaille et s'il ne faut que 3 lignes, je le ferai car ça allégera si ce n'est les choses complexes, au moins le volume.
Encore un grand merci de ton appui ; et, à ta disposition pour améliorer l'efficacité de nos échanges.
Amicalement     RJL2808

Utilisateur anonyme · Answer

Bonsoir rjl

J'étais en voyage aujourd'hui.
Ne crains pas de m'avoir choqué, je n'ai même pas compris ce qui aurait pu me choquer.
Je reviens d'abord sur ton erreur ligne 117 Fatal error: Call to a member function prepare() on a non-object ... Effectivement, tu appelles la $connexion->prepare(), mais $connexion n'est pas un objet de type PDO. En fait, $connexion n'est pas défini du tout. Il n'y a pas de connexion à la base de données dans FormPreInsc.php. Il faut l'ajouter.
Quand ce sera fait, tu auras (au moins) un autre problème : l'array que tu passes pour l'execute est mal défini. 
array('anais=>$anais, civil=>$civil, nomadh=>$nomadh, prenom=>$prenom, ad1=>$ad1, ad2=>$ad2, cpost=>$cpost, ville=>$ville, tfixe=>$tfixe, tmob=>$tmob, admail=>admail')
de l'apostrophe avant anais à celle après admail, il y a une seule chaine. C'est comme si tu avais écrit array('toto') sauf que ton texte est un peu plus long que toto. Il fallait écrire :
array('anais'=>$anais, 'civil'=>$civil, 'nomadh'=>$nomadh, ..., 'admail'=>admail')

dis moi comment tu souhaites que je travaille Je n'aurai pas cette prétention. Et quand je parlais de 3 lignes, je parlais d'un formulaire de 3 lignes (genre nom, prénom, fonction), loin de moi l'idée qu'il suffit de 3 lignes pour traiter ce formulaire ! Mais le code est plus court, donc plus facile à reproduire ici et moins sujet aux fautes de frappe... Et ça permet de bien faire des essais d'écriture et de relecture dans la base de données, de transmission d'informations d'une page à l'autre... Quand on a bien compris comment ça marche, ça devient facile d'ajouter 25 champs si on en a besoin.

rjl · Answer

Bonjour le père,

Merci de ta réponse détaillée.
En premier lieu pour l'écriture, une instruction n'avait pas suivi : include_once ("ConnectBDutl.php");    // Connexion à la BD
contenant :entre autre dans le Try :
$arrExtraParam= array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8"); 
		$connexion = new PDO( $dsn, $utilisateur, $motDePasse );
		$connexion->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
Pour l'Array, j'avais recherché le format mais, il y a plusieurs formes et j'ai mal interprété la notion de chaîne.

Après nombre d'essais, voila comment j'ai modifié mes instructions 117 à 130 : cf.image jointe en [IMG]http://img196.imageshack.us/img196/9836/bd2810.jpg[/IMG] 
Note qu'au 2ème essai j'avais modifié par les utf8_decode d'où la correction des mots accentués (prenom ou ad2) ; autre conséquence l'écho (instruction provisoire sans utf8_encode pour revenir à la bonne situation ici) met à son tour "en valeur" ces caractères accentués !
Je pense aussi que les SESSION_[' concernant les champs peuvent être substitués par des POST_['  ou disparaître selon leur utilisation.

Seules difficultés résiduelles actuellement :
o	Les champs tronqués à la première sous-chaîne malgré longueurs suffisante et communication conforme de la chaîne ; j'ai cherché dans les fonctions de traitement des strings mais sans succès !
o	J'ai introduit un bouton radio dans le formulaire pour obtenir les bonnes valeurs en civilité avec un pré-choix Mme (81% des cas !). Problème, eje ne sais pas le réafficher imposant à l'utilisateur de le rechoisir à chaque affichage  (particulièrement en cas d'erreur sur une autre zone) !
o	ce n'est pas un problème puisque quasi solutionné mais tu me disais utf8_decode non approprié... J'en conviens mais n'ai pas trouvé de meilleure solution avec PHP ne fonctionnant pas en utf8 ?

Voila ma situation actuelle et si tu as des pistes, elles seront les bien venues ! J'ai pris du temps mais corrigé au maximum tant pour les erreurs bloquantes (code) que pour le fonctionnel (enregistrement).

Merci d'avance pour ton soutien.       RJL2810

Utilisateur anonyme · Answer

Commençons par cette histoire de chaîne tronquée au premier espace. Après relecture, c'est évident. Ce n'est pas un problème de php, mias de html. Tu l'aurais vu si tu avais vérifié le code généré par ton script ( n'as-tu jamais fait Ctrl U sur une page pour voir le code HTML ?) petit extrait de ce que tu as écrit, pour mettre le nom dans le formulaire : > Supposons que ta variable contienne Loïc Eugène. Le code généré est : Pour html, il y a un attribut qui s'appelle value et qui contient Loïc, et un autre qui s'appelle Eugène (ce qu'il ne doit pas comprendre) et qui n'a aucune valeur. Il faut toujours entourer les valeurs des attributs d'apostrophes (simples ou doubles) pour éviter ce désagrément. C'est même toujours obligatoire dans certaines version de html. J'en profite pour te faire remarquer que la balise ouvrante du php, c'est ) n'ont pas de balise fermante associée. D'où la correction :

Utilisateur anonyme · Answer

Pour la civilité, je ne vois pas très bien où est le problème. Il faut mettre ou ne pas mettre checked="checked" dans l'un des boutons et l'inverse dans l'autre en fonction de $civil.

Utilisateur anonyme · Answer

Pour l'utf8, je maintiens que tu ne dois utiliser ni utf8_encode, ni utf8_decode.
Tes tables mysql sont-elles bien définies en utf8 ?
D'après l'échantillon d'affichage que tu nomtres, il manquerait une balise meta qui déclare que ta page est encodée en utf8. As-tu cette balise ? Peux-tu montrer la partie <head> de ta page ?

rjl · Answer

Bonjour le père, J'étais toujours en poste mais, j'essayais de progresser et rapporter une copie correcte... Ce n'est pas vraiment concluant ! Alors, rien n'est plus bloquant et je peux faire mes essais : les enregistrements sont bien pris en compte (et, comme je ne prédéfinis plus le sexe, M. ou Mme reste positionné en bouton radio en cas d'erreur). les champs saisis se réaffichent bien en cas d'erreur et sont repris, seule l'erreur étant à corriger. J'ai essayé d'aller au-delà et c'est dans ce cadre que j'ai bien cafouillé malgré mes recherches ! Je souhaitai forcer en majuscules accentuées les champs nomadh et ville ; la fonction $nomadh = strtoupper($_POST['nomadh']); ne fonctionnant pas (car laissant les minuscules accentuées en l'état), les autres fonctions proposées n'étant pas connues de mon PHP (elles ne passent pas en gras bleu et restent en noir avec Notepad++), j'ai ajouté en tête de mon code HTML un setlocale pour prendre en compte les caractères français dans strtoupper() : . . . . . . . . . . Malheureusement, j'ai perdu car ça n'a pas fonctionné ! Un problème qui reste entier. Enfin, ayant saisi un nom avec apostrophe (l'hôpital), je me suis retrouvé avec un \' donc l\' hôpital dans ma base de données ! J'étais conscient de ne pas avoir traité à la fois ces aspects et la sécurité qui doit entourer les saisies utilisateurs : Comment les gérer avec quelles fonctions pour éliminer les risques utilisateurs (accidentels ou non) mais aussi se retrouver avec la saisie voulue et non comme moi avec un antislash parasite ? Les questions ont changé, signe que tu me fais progresser. Tu me demandes les META : c'est facile, elles sont comme plus de 20 lignes en INCLUDE dans TOUS les modules. seules 3 lignes précédent et y échappent : Pre Inscriptions Le reste est fourni par l'INCLUDE avaec au début pour le : La BD, elle, est bien en utf8. Pour la civilité, comme indiqué plus haut, j'ai supprimé le checked="checked" qui me faisait perdre le choix initial en cas de réaffichage suite à erreur (plus exactement, je ne savais pas repositionner le bouton radio cliqué, le checked me ramenant toujours à l'option par défaut ! Je ne l'ai pas écrit mais, j'ai corrigé mes input dont l'affichage des "value" ce qui fait que je n'ai pas de difficulté pour réafficher ce qi a été saisi ; par contre, je me permet un cycle supplémentaire pour réafficher ce qui a été saisi avant de remettre la grille à blanc : Civilité : value="M. " />M. value="Mme" />Mme
Nom *.................. : Un dernier point, j'ai fait voler en éclat les délais qui étaient fixés compte tenu de mes faiblesses, de la charge de saisie et mise en page des compte-rendu des conférences à reprendre. Je pense avoir fait le tour des sujets actuels et te souhaite un bon dimanche ; encore merci et @bientôt. Amicalement RJL2811

Utilisateur anonyme · Answer

Pour la manipulation (comme le forçage des majuscules) en utf8,n les fonctions 'simples' du php ne conviennent pas car elles fonctionnent sur le principe 1 caractère = 1 octet. Or, en utf8, les caractères (accentués en particulier) peuvent être codés sur plusieurs caractères. Il FAUT utiliser les fonctions multioctets : https://www.php.net/manual/fr/book.mbstring.php par exemple mb_strtoupper().

Pour les \ qui apparaissent avant les apostrophes, c'est normal aussi. Ils sont ajoutés par le php dans les données GET, POST et COOKIE. Cette fonctionnalité, qui s'appelle les guillemets magiques, a été mise dans PHP dans un souci de sécurité mais compte-tenu de se inconvénients, elle est désormais obsolète. http://www.php.net/manual/fr/security.magicquotes.php
Elle est encore souvent activée sur les serveurs par souci de compatibilité avec  les anciens scripts.
Une fonction (get_magic_quotes_gpc()) permet de savoir si la fonctionnalité est activée au pas, et donc de savoir s'il faut retirer les \ en trop ou pas. Ça se fait facilement avec une fonction :
function RecupChaine ($chaine) {
  if (get_magic_quotes_gpc()) return stripslashes($chaine);
  return $chaine;
}
Cette fonction est à utiliser pour récupérer les données d'un formulaire ($_GET ou $_POST et des $_COOKIE).
$nom=RecupChaine($_POST['nom']);

rjl · Answer

De plus en plus hermétique pour moi... A force de bidouillage, j'ai même perdu le maintien du choix bouton radio lors des rafraîchissements de page (après erreur). Mais, ce qui me chagrine, c'est que je n'ai pas réussi (mauvaise utilisation ?) avec les fonctions que tu m'as indiquées. Pour les majuscules, je ne suis qu'à moitié surpris, car je l'avais déjà essayée et avait lu qu'elle ne traitait pas les minuscules accentuées... Malgré tout, j'ai trouvé cette fonction améliorée uc_strtouper_fr() qui n'a pas fonctionné non plus (d'où ma tendance à penser mauvaise utilisation) :. // et une utilisation des fonctions : Je te transmets une image qui montre l'antislash resté en zone adresse (ad1) et la fonction et son utilisation. [IMG]http://img857.imageshack.us/img857/4559/bd2812.jpg[/IMG] Par ailleurs, tu peux voir que les caractères accentués ne passent pas en majuscules malgré la fonction améliorée... Pourtant, celle-ci est bien sollicitée puisque les autres minuscules sont modifiées (cf. image). Merci, bon dimanche et @+ RJL2812

Utilisateur anonyme · Answer

Pour le passage en majuscule, comme je te l'avais dit, il faut utiliser les fonction multioctet mb_...
Utiliser utf8_decode, puis faire un traitement, puis à nouveau utf8_encode risque de te donner des résultats décevants, puisque tu ramènes sur un codage à un octet (256 caractères possibles) un codage à plusieurs octets, qui admet des dzaines (centaines ?) de milliers de caractères différents.Par exemple, tu perds le € et le oe. Il FAUT utiliser mb_strtoupper() pour convertir en majuscules une chaîne utf8.
C'est normal que ta fonction uc_strtoupper_fr ne marche pas, l'explication est un peu longue, mais je pourrai te la donner si tu y tiens.

Quant à la fonction RecupChaine, tu ne l'utilises pas de la même manière dans le script ci-dessus et dans l'image jointe. Je t'ai dit de l'appliquer aux données récupérées par POST, c'est bien ce que tu fais dans l'image jointe, alors que dans le script ci-dessus tu l'appliques au résultat de la fonction uc_strtoupper_fr, ce qui n'est déjà plus la données récupérée par post.
N'empêche que ça aurait dû marcher quand même. On voit le problème sur le champ Adresse, et dans l'image on ne voit pas que tu appliques la fonction à l'adresse. Si tu es sûr de le faire, tu peux m'envoyer le code en MP ?

rjl · Answer

Bonsoir le père, Je vais enregistrer mes résultats avec les essais correspondants pour les commenter en parallèle, car, après 3 ou 4 essais, j'ai difficile à me souvenir de ce que j'ai modifié pour chaque essai plus encore à revenir à l'état initial si ça s'est détérioré ! Je commence par le test avec mb_strtoupper() sachant que j'ai maintenu (sauf pour $nomadh $ville et $ad1) la fonction RecupChaine () ; j'avais déjà fait ce test et l'ai repris toujours sans succès il y a 5mn ; je reprends maintenant exclusivement sur les résultats du $_POST : Nom *.................. : J'ai pour mes 3 zones test : $nomadh=Cédaïde ; $ad1=rue de l'Hôtel de l'Hôpital ; $ville=châteauroux ; Après envoi du Formulaire, je récupère : $nomadh=CéDAïDE ; $ad1=rue de l'Hôtel de l'Hôpital ; $ville=CHâTEAUROUX; Première remarque : RecupChaine () a marché et, j'espère que ce ne sont pas les 2 apostrophes qui me valent cela ? Pour mb_strtoupper(), j'aurai été surpris qu'au 4ème ou 5ème test ça fonctionne ! Pour autant, je vais faire un test supplémentaire avec quasiment les mêmes données (sauf $ad1) pour lever un doute. $nomadh=Cédaïde ; $ad1=rue de l'Hôtel ; $ville=châteauroux ; Le résultat est $nomadh=C?DA?DE ; $ad1=rue de l'Hôtel de l'Hôpital ; $ville=CH?TEAUROUX ; Mon pré-sentiment n'est pas loin sauf que j'ai travaillé comme si j'envoyais mon enregistrement pour la BD ; je corrige pour un nouvel essai avec les mêmes données en entrée : Nouveau résultat est $nomadh=CÃ©DAÃ¯DE ; $ad1=rue de l'Hôpital ; $ville=CHÃ¢TEAUROUX ; Cette fois, j'avais travaillé, non plus avec utf8_encode() mais avec utf8_encode() soit donc :
C'est donc que le champ serait bien en utf8, ce qui n'améliore pas pour ma compréhension de l'enregistrement en BD. Un nouvel essai devient donc nécessaire sans encode, ni decode mais en modifiant la fonction en mb_strtoupper_fr() : Il fallait le faire mais le résultat reste le même ! Un dernier test... à tout hasard (toujours les mêmes entrées) ; Un résultat inattendu, correct mais dont je te laisserai interpréter le pourquoi : Au niveau appel, j'ai modifié comme annoncé la fonction : Elle a cependant fonctionné avec une fonction dont j'avais retiré les utf8_encode et decode : //fonction mb_stroupper en français //Pour appeler la fonction: /*echo mb_strtouper_fr($variable); //par exemple $variable="je suis indigné"; echo mb_strtouper_fr($variable); // renvoit : JE SUIS INDIGNÉ function mb_strtoupper_fr($chaine) { $chaine= mb_strtoupper($chaine);/*$chaine=utf8_decode($chaine);*/$chaine=trim($chaine); $chaine= strtr($chaine, "äâàáåãéèëêòóôõöøìíîïùúûüýñçþÿæoeðø","ÄÂÀÁÅÃÉÈËÊÒÓÔÕÖØÌÍÎÏÙÚÛÜÝÑÇÞÝÆOEÐØ"); /*$chaine=utf8_encode($chaine);*/ return $chaine; } Ce que j'ai retiré pour un résultat : $nomadh=CÉDAÏDE ; $ad1=rue de l'Hôpital ; $ville=CHÂTEAUROUX ; Le GAG : Tous les résultats enregistrés sur la BD... sont erronés : 1947 Mme Cédaïde Josée rue de l\'Hôpital 36000 Châteauroux 2012 0000 0 2012-08-12 521 (minuscules et antislash) ! Je n'analyserai le pourquoi que demain... mais simple question : est-ce que dans le , le echo $nomadh= mb_strtoupper_fr($_POST['nomadh']); instruit bien le $nomadh ? Ce qui est sûr c'est que par cette méthode, je ne repasse pas par les mêmes fonctionnalités pour enregistrer... Reste une question cruciale... Pourquoi me faut-il passer par utf8_decode() pour enregistrer correctement les caractères accentués ? Une évolution intéressante mas pas sans poser question. Merci d'avance de tes avis RJL2812

Utilisateur anonyme · Answer

Je t'ai répondu en MP.

Fatal error et réaffichage champs Formulaire

24 réponses

Discussions similaires