D'entrée de texte et de caractères spéciaux et de MySQL

Vous avez la bonne idée de conserver le texte dans la base de données raw. Pas sûr de ce que toutes les entités HTML stuff est pour; vous ne devriez pas besoin de faire ça pour une base de données d'insertion.

[La seule raison pour laquelle je peux penser pourquoi vous essayez peut-être de l'entité décoder entrants entrée de la base de données serait si vous trouvez que vous obtenez des références de caractère comme Š dans votre soumission d'un formulaire de saisie. Si c'est le cas, c'est parce que l'utilisateur est saisie des caractères qui n'existent pas dans l'encodage utilisé par la page avec le formulaire. Cette forme de codage est totalement faux parce que vous ne pouvez pas distinguer entre l'utilisateur de taper des Š et littéralement taper Š! Vous devriez éviter cela en utilisant le codage UTF-8 pour l'ensemble de vos pages et le contenu, étant donné que chaque personnage s'intègre dans ce codage.]

Des chaînes dans votre script doit toujours être en texte brut avec pas de s'échapper. Cela signifie que vous ne faites rien jusqu'à l'heure de la sortie dans un contexte qui n'est pas simple de texte. Donc, pour les mettre dans une chaîne SQL:

$category= trim($_POST['category']);
mysql_query("SELECT * FROM things WHERE category='".mysql_real_escape_string($category)."'");

(ou utiliser des requêtes paramétrées pour éviter d'avoir à manuellement échapper.) Quand on met le contenu en HTML:

<input type="text" name="category" value="<?php echo htmlspecialchars($category); ?>" />

(vous pouvez définir une fonction d'assistance avec un nom plus court comme function h($s) { echo htmlspecialchars($s, ENT_QUOTES); } si vous voulez réduire la quantité de saisie que vous avez à faire dans les modèles.)

Et... c'est assez bien. Vous n'avez pas besoin de traiter des chaînes de caractères qui sortent de la base de données, car ils sont déjà brute des chaînes de caractères. Vous n'avez pas besoin de traiter des chaînes d'entrée(*), d'autres que toute demande spécifique de validation de champ que vous voulez faire.

*: eh bien, sauf si magic_quotes_gpc est activé, dans ce cas vous ne devez stripslashes() tout ce qui vient de get/post/cookie, ou, ma bonne option, juste immédiatement échouer:

if (get_magic_quotes_gpc())
    die(
        'Magic quotes are turned on. They are utterly bogus and no-one should use them. '.
        'Turn them off, you idiot, or I refuse to run. So there!'
    );

Je tiens à souligner deux choses:

1. il n'y a rien de mal à sauver des personnages comme ' et " dans une base de données, SQL injections sont juste une question de manipulation de chaîne, en fait, ils n'ont rien à voir avec SQL ou des bases de données -- le problème seulement repose dans la façon dont la chaîne de requête est construite. Si vous voulez écrire vos propres requêtes (non recommandé), vous n'avez pas à coder chaque apostrophe ou guillemet double: il suffit de s'échapper une fois pour construire un coffre-fort de la chaîne, et de les enregistrer dans la base de données. Une meilleure approche est d'utiliser PDO comme mentionné, ou à l'aide de la extension mysqli qui permet des requêtes préparées avec les états

2. htmlentities() et des fonctions similaires doivent être utilisés lors de l'envoi des données de sortie vers le navigateur, pas pour l'encodage des données stockées dans une base de données pour au moins deux raisons: tout d'abord, il est inutile, la DB ne se soucie pas des entités html, il contient uniquement des données; d'autre part, vous devriez toujours traiter les données provenant de la base de données comme potentiellement dangereux, donc vous devez l'enregistrer en format "raw" et encodez lors de l'utilisation de ce.