Ses derniers messages sur les forums
Plusieurs commentaires à propos de ton code.
60000000000000 n'est pas un nombre entier que PHP peut représenter dans un entier (maximum : 2^32 - 1).
Habituellement, lorsqu'une fonction règle un paramètre, lui fournir 0 signifie souvent quil y a désactivation du contrôle de ressource. C'est confirmé par la doc de
set_time_limit.
Utiliser
die c'est mal. Il faut gérer l'erreur, et non pas tuer froidement le script.
Il y a un trou de sécurité dans la construction de ta requête. il faut utiliser mysql_real_escape_string pour préparer les informations fournies.
Il manque un espace de séparation dans le update de la ligne 53.
Il faut que tu apprenne les
tables de vérité, et l'
algèbre booléenne par extension.
Essaye d'indenter correctement ton code. Pour cela, utilises un éditeur de texte plus adapté tel que Vim ou emacs, plutôt que Notepad.
Lorsque tu as un if qui est suivit d'un statement composé d'un seul statement, renvoie à la ligne ce statement.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Créé un fichier qui contient le code qui suit, et fait le afficher via le navigateur.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Comme dit moogli, tu peux renommer la colonne, ou alors utiliser les backticks « ` ».
Ceci dit, ta table m'a laissé sans voix. Ça faisait longtemps que je n'avais pas vu autant de colonnes pour une même tables. C'est toujours le signe d'une mauvaise analyse du problème. Mais plus grave, ce sera ingérable sur le long terme.
D'ailleurs, quel est le nom de l'outil pourri qui t'a vomi le HTML ?
C'est le même outil qui génère la table ?
Si tu veux jeter l'ensemble des variable HTTP POST dans ton contexte d'exécution, il existe la fonction
extract.
Mais il y a une chose qu'il faut que tu gardes en tête : ton script n'a aucune notion de sécurité, ce qui est gênant. Recherche l'acronyme XSS sur lephpfacile.com, ou le web. On en a beaucoup parlé.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Bordel le BBcode !
Si ton maître de stage galère aussi, il ne doit pas être très compétant.
En effet, le fragment de l'URL (la partie après le #), n'est pas transmis au serveur distant. C'est uniquement une information locale.
Ceci implique que tu ne peux rien en faire dans PHP, puisqu'il ne l'a pas reçu.
Et le « full ajax », quand c'est bien fait, c'est bien ©
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
La documentation n'en parle pas en tout cas. Par contre, pourquoi utiliser ce module Pear alors qu'ils le déconseillent dans la documentation ?
D'après ce que je comprends du source de la classe Mail_mimeDecode, il faut utiliser la méthode getMimeNumbers pour récupérer les parties du courriel.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
'<font color="red">'.$erreur = 'Compte non reconnu.'.'</font>';
Le code que tu as fait s'interprète ainsi :
* chaîne '</font>'
* chaîne 'Compte non reconnu.'
* concatène '</font>' à 'Compte non reconnu.'
* assigne le résultat de la concaténation à la variable erreur.
* chaîne '<font color="red">'
* chaîne copiée depuis la variable erreur.
* concaténer la copie du contenu à la chaîne '<font color="red">'.
* libérer la chaîne concaténée précédemment.
Si tu comprends ça, tu devrais être capable de corriger ton problème, et tu comprends alors pourquoi '<font color="red">' ne s'affiche pas.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Ce qui m'intrigue, c'est pourquoi les employés gérant le stock n'utilisent pas un outil commun avec le site web ?
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
(subrally) Il faudrait que tu arrête de parler de caractères spéciaux. Habituellement, on désigne par cette locution les caractères qui ont un comportement magique, et qui sont en général invisible. Tels que le retour charriot ou la fin de ligne.
Et maintenant, tu devrais te poser, prendre une feuille et un crayon. Représente les flux d'échange de données dans une application PHP.
Les différents éléments qu'on peut considérer sont :
- le script PHP
- les variables PHP
- le client web
- le serveur de base données
- le client de base données
- les « variales » de la base de données
- le script SQL (potentiellement issu de ton script)
Je dois en oublier, mais je pense qu'on a l'essentiel. Chacune de ces entités peuvent utiliser un encodage différent.
Tu peux constater que le problème est complexe, et que le hasard n'est donc pas de mise dans la résolution des problèmes liés aux encodages. Il faut que tu saches quels sont les encodages utilisés, et gérer de manière éclairée.
Tu pourrais choisir de tout mettre en UTF-8. Si dans un premier temps c'est acceptable, si tu ne contrôle jamais les encodages, tu risques d'avoir des bogues, voir des trous de sécurité, très difficiles à traquer et réduire.
C'est, à mon sens, l'une des plus grandes difficultés dans le développement Web.
Une fois que tu auras compris ça, le comportement des chaînes ne te surprendra plus !
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Au cas où tu ne l'as pas remarqué, le problème était de créer des objets déclarés dynamiquement. Et autre détail : je ne pense pas que répondre à un message un an après la résolution apporte quoique ce soit ;)
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
