Question

Je vais avoir des problèmes échapper / décapage des chaînes avec PHP / MySQL - il semble toujours être des barres obliques redondantes

.

Prenons la chaîne suivante comme exemple:

<span style="text-decoration:underline;">underline</span>


Lors de l'ajout d'une chaîne à la base de données, j'échapper avec mysql_real_escape_string() et les suivantes est stocké dans la base de données ( EDIT : coché cette en interrogeant la base directement avec l'application mysql):

<span style=\\\"text-decoration:underline;\\\">underline</span>


Lors de la lecture arrière de la base de données, je passe la chaîne par stripslashes() et ce qui suit est de retour:

<span style=\"text-decoration:underline;\">underline</span>


Étant donné que les guillemets sont encore échappés, il casse le code html et le texte n'est pas souligné.


  1. Pourquoi mysql_real_escape_string() ajoute trois barres obliques et stripslashes() enlever deux barres obliques? Je les attendre à la fois d'ajouter / supprimer une barre oblique.
  2. Comment puis-je empêcher que cela se produise?
  3. Est-ce que j'aborde ce la bonne façon?
Était-ce utile?

La solution

Meilleure solution

Dans votre fichier php.ini, les chances sont que la directive magic_quotes_gpc est activée. Cela devrait être désactivé pour des raisons de sécurité. Si vous n'avez pas accès au fichier php.ini (par exemple. Sur un hôte partagé), vous pouvez toujours faire la même en utilisant une directive .htaccess (en supposant que c'est un serveur apache).

Dans votre php.ini

magic_quotes_gpc Off

Dans un fichier .htaccess:

php_flag magic_quotes_gpc Off

Pourquoi est-ce qui se passe?

La raison pour laquelle cela se passe est dû au cours de la logique suivante.

  1. Une chaîne qui a besoin de s'échappe est envoyée au serveur.
    • This is my string. It's awesome.
  2. Citations magiques échappe lapostrophe avant qu'il arrive à votre code.
    • This is my string. It\'s awesome
  3. mysql_real_escape_string a maintenant deux personnages à échapper, la \\ backslash ainsi que la \' apostrophe.
    • This is my string. It\\\'s awesome
  4. Cette nouvelle chaîne échappée super est stocké dans la base de données.
  5. Lorsque la chaîne est extraite de la base de données, get passé à stripslashes. Cela supprime les deux évasions ajouté à l'étape 3, mais étant donné que l'un des anti-slash a été échappé stripslashes pense qu'il appartient.
    • This is my string. It\'s awesome

Ce problème peut vraiment sortir de la main lorsque vous resoumettre ces chaînes à la base de données, chaque fois que le nombre de multiplications de antislash.

Solution alternative

Une alternative rapide et facile serait de supprimer simplement les barres obliques ajoutés par magic_quotes avant de passer la chaîne à mysql_real_escape_string.

$str = stripslashes($_POST['str']);
$str = mysql_real_escape_string($str);

Autres conseils

  

Lors de l'ajout d'une chaîne à la base de données, j'échapper avec mysql_real_escape_string() et les suivantes est stocké dans la base de données:

     

<span style=\\\"text-decoration:underline;\\\">underline</span>

Non, ce n'est pas. Lorsque vous échapper des chaînes dans une requête SQL, il est seulement pour transporter les données dans la requête. La base de données analyse la requête et stocke les données dans la base de données, sans barres obliques. Ainsi, lorsque vous récupérez les données de la base de données, vous devriez pas quoi que ce soit unescape. Il est une idée fausse.

Si vous trouvez qu'il ya des excès barres obliques dans la sortie, vous avez probablement les guillemets magiques activés. les Éteignez .

Edit:

mysql> create table foo (bar text) ;
Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO foo (bar) VALUES ("<span style=\\\"text-decoration:underline;\\\">underline</span>");
Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM foo;
+-------------------------------------------------------------+
| bar                                                         |
+-------------------------------------------------------------+
| <span style=\"text-decoration:underline;\">underline</span> | 
+-------------------------------------------------------------+
1 row in set (0.00 sec)

Comme vous pouvez le voir, la requête a un niveau plus échapper que les données apparaît dans la base de données et par conséquent comment il sort lors de l'interrogation pour elle. Dans votre cas, ce qui est probablement en cours, est que vous avez des citations magiques activés et vous échapper des chaînes avant de les intégrer dans une requête. Cela conduit à double Évasion, l'altération de vos données. La bonne solution est de garder échapper des chaînes comme vous le faites, mais désactiver les guillemets magiques. Et ne pas ne rien sur les données qu'il sort de la base de données. Méfiez-vous que les données déjà dans le système doit être nettoyé d'abord.

Si get_magic_quotes_gpc() est désactivé dans le serveur, de sorte que nous pouvons utiliser

$data= mysql_real_escape_string($_POST['data']);

si get_magic_quotes_gpc() est dans SERVEUR, nous devons utiliser

$data= mysql_real_escape_string(stripslashes($_POST['data']));

sinon ajouter deux barres obliques avec vos données.

Aussi une autre solution est que nous pouvons utiliser stripslashes($data) alors chercher à datadase si nous n'utiliser que mysql_real_escape_string($_POST['data']);

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top