Ouais je suis bien d'accord pour les nombres, le but de la fonction ici n'est pas de protéger tout et n'importe quoi dans une requête SQL, c'est vraiment juste pour une chaîne avec un délimiteur spécifique. Pour les nombres c'est clair qu'une vérification ou un cast explicite s'impose.
C'est justement sur les techniques qui jouent sur l'encodage que j'aurais aimé en savoir un peu plus, et apparemment les logiciels que j'ai essayés ne testent pas des failles d'encodage.
Je suis bien d'accord que c'est une mauvaise idée d'utiliser une fonction perso quand il y a déjà des fonctions ou librairies bien plus poussées pour faire ça, néanmoins je suis justement dans un cas où je n'ai aucune fonction ou méthode native me permettant de faire ce que je veux.
Actuellement je développes un DAO perso pour mes projets, permettant d'utiliser au choix PDO, mysqli, mysql_* (ou un peu ce qu'on veut, suffit d'étendre la classe abstraite et d'implémenter les méthodes spécifiques).
J'ai inclus un système de requêtes préparées à la PDO, à la différence qu'en plus de pouvoir affecter une valeur (quote simple), on peut aussi affecter un identifieur (backtick), typiquement pouvoir faire "SELECT :field FROM :table WHERE `id` = :id".
En pratique il y a peu de chances que les identifieurs dynamiques proviennent de l'utilisateur, ce sera plutôt pour un confort de développement à l'intérieur de l'application.
Quoi qu'il en soit ce type d'affectation n'est pas supportée par PDO, mysqli ou mysql_*. PDO propose bien une méthode quote, mais celle-ci utilise une quote simple comme délimiteur (qui est d'ailleurs ajouté autour de la chaîne retournée), et je ne penses pas que ce soit une bonne idée de remplacer le premier/dernier caractère de la chaîne échappée par un backtick pour un identifieur.
Même constat pour la méthode escape_string de mysqli, ou pour un mysql_real_escape_string, ces fonctions n'échappent pas les backtick.
Je suis donc dans un cas où je dois utiliser une fonction perso pour sécuriser l'échappement d'un identifieur, et même si je ne penses pas affecter dynamiquement un identifieur dans une requête SQL tous les jours, c'est une fonctionnalité que je souhaite rendre possible, et sécurisée.
Après on est pas censé mettre tout et n'importe quoi dans un identifieur SQL, contrairement à une valeur, donc je ferais peut-être mieux de tester la valeur avec une expression régulière et lancer une exception à ce moment là plutôt que de déléguer l'identifieur incorrect au serveur SQL qui retournerait une erreur de syntaxe ?
