Différences

Ci-dessous, les différences entre deux révisions de la page.

--- langages:php:erreurs [03/01/2015 12:03]
julp [Insertion des données sous forme htmentities/htmlspecialchars]
+++ langages:php:erreurs [08/05/2015 17:50] (Version actuelle)
julp
@@ Ligne 208: / Ligne 208: @@
 ===== Les noms des fonctions/méthodes sont sensibles à la casse =====
-Encore une fois, c'est totalement faux ! Un petit récapitulatif s'impose, PHP et casse : ce qui y est sensible ou non :
+Déplacé sur [[http://www.julp.fr/blog/posts/3-mythe-php-1-c-est-mysql_query-et-non-mysql_query]]
-^ Élément du langage ^ Sensible ou insensible à la casse ^ Note ^
-| Nom d'une constante | sensible (par défaut) | voir ci-dessous |
-| Nom d'une classe chargée | insensible | voir ci-dessous |
-| Nom d'une fonction/méthode | insensible | - |
-| Nom d'une variable (propriétés de classe et d'instance comprises) | sensible | $x et $X désignent deux variables différentes |
-Je reviens sur :
-  * les constantes : par défaut, le nom de leur déclaration doit être repris. Il est cependant possible, en positionnant le troisième paramètre à valeur vraie de define, de forcer PHP à rendre le nom de la constante insensible à la casse. Les constantes déclarées par const implique nécessairement une sensibilité à la casse (FOO et foo désignent deux constantes différentes).
-  * les noms de classe : par chargée, j'entends une classe connue de PHP. Si, en revanche, la classe désignée n'existe pas encore et qu'un autoload intervient, ce dernier, lui, peut être affecté par la casse. On pensera notamment au fait que les systèmes de fichiers Windows sont insensibles à la casse quand, sur Unixoïde, c'est le contraire. Par conséquent, que la classe s'appelle "Foo" ou "foo" au niveau de PHP, ça désigne la même classe. Mais, au niveau de l'autoload, quand vous cherchez à inclure un script, le nom (foo.php contre Foo.php), suivant le système, ne donnera pas nécessairement le même résultat : l'un des deux pourra échouer si le nom de la classe ne correspond pas exactement au nom du fichier qui en contient le code.
 ===== Il FAUT un try/catch =====
@@ Ligne 265: / Ligne 255: @@
 ===== Pour faire expirer mes sessions, je joue sur la durée de vie du cookie PHPSESSID (session.cookie_lifetime) =====
-A moins de savoir ce que l'on fait, c'est à éviter pour deux raisons :
+Déplacé sur [[http://www.julp.fr/blog/posts/8-mythe-php-2-pour-faire-expirer-mes-sessions-je-joue-sur-la-duree-de-vie-du-cookie-phpsessid-session-cookie_lifetime]]
-  * premièrement, ce n'est pas parce que vous faites expirer le cookie de session (nommé PHPSESSID par défaut) que la session côté serveur n'existe plus. Au contraire, les fichiers de session (gestionnaire par défaut) vont persister côté serveur. Tout ce que vous allez obtenir c'est une multiplication inutile des fichiers temporaires de session et, du fait qu'ils sont toujours présents côté serveur, ça n'empêcherait pas quelqu'un d'exploiter la session que vous croyez avoir terminée. Ce qui compte avant tout, c'est de configurer le garbage collector pour qu'il soit efficace (il faut trouver le juste équilibre par rapport à son trafic : il ne doit pas être invoqué trop souvent - cela va consommer des ressources machines inutilement - ni pas assez - accumulation des fichiers des sessions expirées et pourrait faciliter le travail d'un attaquant, ça en fait plus de sessions à voler).
-  * deuxièmement, ce que la plupart des gens ne savent pas, c'est que PHP ne reconduit pas la date d'expiration du cookie d'une requête à l'autre. C'est à dire que si vous mettez session.cookie_lifetime à 15 minutes, que quelqu'un visite votre site à 13h32, qu'il revienne ou non avant 13h47, il perdra sa session (et les données qui vont avec) à 13h47 quoi qu'il arrive. Cela en fait donc un comportement admissible dans de très rares cas, il serait plus dommageable qu'autre chose.
 ====== Apache ======
@@ Ligne 285: / Ligne 273: @@
 ===== LIKE est insensible à la casse =====
-J'ignore d'où les gens peuvent tirer une telle affirmation car la documentation de MySQL ne l'a jamais mentionné. Pour cause, chez MySQL, ce qui détermine la sensibilité ou l'insensibilité à la casse c'est ni plus moins que l'interclassement courant et, ce, quel que soit l'opérateur (simple égalité - ''='' - comme LIKE). De la même façon que les jeux de caractères, vous avez toute une chaîne d'héritage pour déterminer la collation courante :
+Déplacé sur [[http://www.julp.fr/blog/posts/4-sql-gestion-de-la-casse]]
-  * vous pouvez en expliciter une ponctuellement à tout niveau de la requête via le mot-clé COLLATE
-  * s'il s'agit d'une colonne, c'est celle que vous lui avez accolée à la création de votre table
-  * sinon, pour des données liées à aucune colonne, vous héritez de l'interclassement défini par la variable nommée collation_connection
-Pour preuve :
-<code sql>mysql> set collation_connection = utf8_bin;
-Query OK, 0 rows affected (0.02 sec)
-mysql> select 'foo' LIKE 'F%';
-+-----------------+
-| 'foo' LIKE 'F%' |
-+-----------------+
-|               0 |
-+-----------------+
-row in set (0.00 sec)
-mysql> set collation_connection = utf8_general_ci;
-Query OK, 0 rows affected (0.00 sec)
-mysql> select 'foo' LIKE 'F%';
-+-----------------+
-| 'foo' LIKE 'F%' |
-+-----------------+
-|               1 |
-+-----------------+
-row in set (0.00 sec)</code>
-(ça fonctionnera de la même manière avec tout opérateur)

julp

Outils pour utilisateurs

Outils du site

Différences

Outils de la page