Du bist nicht angemeldet.

1

Donnerstag, 21. September 2006, 03:04

addslashes wird in der MySQL-DB nicht gespeichert?

Tach Post oder so

Vor einigen Tagen unterhielt ich mich mit Lapis darüber, dass addslashes in der Datenbank nicht gespeichert werden ... also addslashes("tester'er'erer") ergibt in der Datenbank nicht
tester\'er\'erer, so wie man es vermuten könnte (zumindest nicht, wenn man per phpmyadmin da reinguckt) sondern tester'er'erer

axo um die Fakten gleich hinzulegen:

Zitat

Willkommen bei phpMyAdmin 2.7.0-pl1
Verbunden mit MySQL 5.0.18-nt auf localhost als root@localhost


gibt es dafür eigentlich ne logische erklärung, ausser das phpmyadmin von sich aus nen stripslashes auf die Daten haut?

TNS
Signatur von »TheNobody Style«

2

Donnerstag, 21. September 2006, 07:31

Versuch einer logischen Erklärung:

addslashes ist nötig, um unter anderem Zeichen, die das Ende eines Strings bedeuten könnten, zu maskieren, natürlich wird das nicht gespeichert, wozu denn auch?

Beispiel:

Quellcode

1
2
3
SELECT user_id
FROM user_table
WHERE user_name = '%s'
Wenn jemand Ich bin's als Benutzernamen eintippt, würdest du ohne addslashes folgendes SELECT auszuführen versuchen

Quellcode

1
2
3
SELECT user_id
FROM user_table
WHERE user_name = 'Ich bin's'
Das würde eine Fehlermeldung zurückliefern.

Mit addslashes würdest du folgendes SELECT ausführen:

Quellcode

1
2
3
SELECT user_id
FROM user_table
WHERE user_name = 'Ich bin\s'
Das ist syntaktisch korrekt, aber es wäre blöd, wenn der Herr mySQL jetzt das \ tatsächlich im Benutzernamen suchte.


Nochmal:
Sonderzeichen müssen, wenn du sie nicht in ihrer Funktion als Sonderzeichen verwenden willst, maskiert werden.
Zum Maskieren kann man addslashes verwenden, besser wäre [phpnet]mysql_real_escape_string[/phpnet].
Bei Formulareingaben, die du so behandeln willst, ist es ratsam, vorher zu prüfen, ob magic_quotes_gpc aktiv ist, dann hat PHP schon addslashes über die Formulardaten laufen lassen, das solltest du mit stripslashes rückgängig machen und dann mysql_real_escape_string drüberlaufen lassen.

PHP-Quelltext

1
2
3
4
if (get_magic_quotes_gpc())
  $_POST['user_name'] = stripslashes($_POST['user_name']);
$user mysql_real_escape_string($_POST['user_name'], $db_connection);
$sql sprintf($sql$user);
Signatur von »mrhappiness« Ich denke, also bin ich. Einige sind trotzdem...

3

Donnerstag, 21. September 2006, 09:03

das diese Zeichen in nem WHERE maskiert werden müssen ist mir schon klar und darum geht es mir hier auch gar nicht. Wenn ich einen Text in der Datenbank speichern will und diesen voher mit addslashes behandle, dann sollte man davon ausgehen können, dass dieser Text auch maskiert in der Datenbank steht.

huch ... da is mir doch gerade etwas aufgefallen:
jögürt 'wie' auch "immer"
dieser String wurde genau so in nem varchar-Feld gespeichert und zwar per addslashes(jögürt 'wieos' auch "immer")

Versuche ich jetzt mal eben dieses im phpmyadmin zu exportieren, dann bekomm ich das hier:
INSERT INTO `table` VALUES ('jögürt ''wie'' auch "immer"');
Wie man hier sieht, wurde das 'wie' maskiert und zwar mit jeweils einem weiteren ' ... was lustigerweise laut phpinfo nicht sein sollte, da magic_quotes_sybase auf OFF steht (genau wie magic_quotes_runtime). Bleibt also die Frage wo die \ bei \' abgeblieben sind, die ja durch addslashes gesetzt wurden ...
Signatur von »TheNobody Style«

4

Donnerstag, 21. September 2006, 13:15

Sorry, ich versteh's nicht.

Wenn der Anwender Ich bin's eingibt und magic_quotes_gpc ausgeschaltet ist, stehen in der PHP-Variablen keine \ drin.

Schreibst du das mit addslashes in die DB, wird das ' maskiert (= \') und zwar nur für den Prozess des SSchreibens, in der DB steht danach wieder Ich bin's

Quellcode

1
INSERT INTO tabelle SET feld = 'Ich bin\'s'


Ist magic_quotes_gpc eingeschaltet, steht in deiner PHP-Variablen Ich bin\'s


Schreibst du das mit addslashes in die DB, wird das ' maskiert (= \') und auch das \ (= \\) und zwar nur für den Prozess des SSchreibens, in der DB steht danach wieder Ich bin\'s

Quellcode

1
INSERT INTO tabelle SET feld = 'Ich bin\\\'s'


Was davon passiert nicht?
Signatur von »mrhappiness« Ich denke, also bin ich. Einige sind trotzdem...

5

Donnerstag, 21. September 2006, 14:06

Zitat von »mrhappiness«

Sorry, ich versteh's nicht.

Willkommen in da Club ;-)

Es geht hier um Variante 1 und es kann ja meiner Meinung nach nicht sein, dass MySQL eigenständig ein stripslashes durchführt und den String als Ich bin's speichert, wenn ich Ich bin\'s im INSERT habe. :suspicious:
Aber wie ich das sehe scheint das aber normal zu sein. Wenn ich also den String aus der DB hole und maskiert brauche, dann muss ich die Variable also wieder mit addslashes behandeln?
$row['feld'] = addslashes($row['feld']);
Signatur von »TheNobody Style«

6

Donnerstag, 21. September 2006, 14:14

Das, was du im INSERT-String hast ist ja nicht das, was der Anwender eingetippt hat (bei Fall 1).

Bei

Quellcode

1
INSERT INTO tabelle SET feld = 'Ich bin\'s'
willst du gar nicht Ich bin\s in die Datenban schreiben sondern Ich bin's.

Bei

Quellcode

1
INSERT INTO tabelle SET feld = 'Ich bin's'
würde es aber Fehlermeldungen hageln, da nach Ich bin der String ja bereits zu Ende ist.

Wie willst du denn Ich bin's in die DB kriegen, ohne das ' zu maskieren? :confused:


Du musst alle Daten, die du in die DB schreiben willst, so aufbereiten wie du sie haben willst und dann eventuell vorhandene Sonderzeichen (wie zum Beispiel ein solches Hochkomma) maskieren. Dazu nimmt man addslashes oder besser mysql_real_escape_string.
Signatur von »mrhappiness« Ich denke, also bin ich. Einige sind trotzdem...

7

Donnerstag, 21. September 2006, 14:47

mrhappiness: wir sind uns ja dahingehend einig und das ist auch nicht das Problem. Mir fiel es halt auf, weil ich den String mit addslashes behandelt in der DB gespeichert hatte und diesen String im Script auch maskiert brauche. Machen wir es an einem Beispiel erklärbar:

Ich speichere in der Datenbank diverse Bilddaten wie URL und auch den Titel, welche der Anwender über ein Formuar eintragen kann.

url = testbild.gif
titel = jögürt 'wie' auch "immer" peng

Vor dem Speichern nun addslashes, weil sonst die ' einige Probleme machen würden. Durch die Verwendung von addslashes könnte ich davon ausgehen, dass der String als jögürt \'wie\' auch \"immer\" peng gespeichert wird, weil per Definition eben diese Zeichen maskiert werden.

jetzt will ich dann aus der DB mit diesen Daten einen Bildcode erschaffen

PHP-Quelltext

1
echo "<img src="".$row['url']."" alt="".$row['titel']."" />";

Soweit ich das ja kein ungewöhnliches Scenario. Das Problem ist, dass du in desem Falle die ' und auch " nicht unmaskiert verwenden kannst, weil das nämlich dem alt-Tag gar nicht gefällt. Folgenden Code würde man so erzeugen:

Quellcode

1
<img src="testbild.gif" alt="jögürt 'wie' auch "immer" peng" />


und so müsste er aussehen, damit er fehlerfrei funktioniert:

Quellcode

1
<img src="testbild.gif" alt="jögürt \'wie\' auch "immer" peng" />


So wie sich mir das darstellt kann ich darauf verzichten, die Daten aus der DB mit stripslashes zu behandeln, weil die Maskierungen eh nimmer da sind und ausserdem muss ich die Daten nochmal mit addslashes behandeln, wenn ich im Script die Daten maskiert brauchen (zB. auch um ein INSERT INTO für die Datensicherung zu erstellen).

Das is recht verwirrend ;)

TNS
Signatur von »TheNobody Style«

8

Donnerstag, 21. September 2006, 16:28

Warum benutzt du beim Erzeugen des HTML nicht die vorgesehenen Funktionen [phpnet]htmlentities[/phpnet], bzw. [phpnet]htmlspecialchars[/phpnet]?

Ich persönlich vertrete den Standpunkt, dass in der DB das stehern sollte,was wirklich eingegeben wurde, wenn ich irgendwas bearbeiten muss, weil es das Ausgabemedium fordert, mache ich das bei der Ausgabe.

Was, wenn du irgendwann mal die Liste deiner Bilder per XML oder weiß der Geier was exportieren willst?
Du würdest dich grün und blau ärgern, hättest du in der Datenbank Backslashes drin, die da gar nicht hingehören

Verwirrend ist es nicht wirklich, es sieht nur so aus.

  • Wenn magic_quotes_gpc nicht aktiv ist, bekommst du die Daten exakt so, wie sie der Anwender eingegeben hat.
  • Wenn du diese Daten in die DB schreiben willst, masierst du eventuell vorhandene Sonderzeichen mit [phpnet]mysql_real_escape_string[/phpnet].
  • Wenn du das, was der Anwender eingegeben hat, irgendwann irgendwo im Browser ausgegeben willst, verwendest du [phpnet]htmlentities[/phpnet], bzw. [phpnet]htmlspecialchars[/phpnet]
Signatur von »mrhappiness« Ich denke, also bin ich. Einige sind trotzdem...

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »mrhappiness« (21. September 2006, 16:30)


9

Freitag, 22. September 2006, 05:38

ich glaub wir reden irgendwie ein wenig aneinander vorbei ;)
Ich hab mich der Programmierung zugewandt, weil es normal ein sehr logische Sache ist und ich ein sehr logischer Mensch bin ... doch was in dem Fall hier passiert ist nicht logisch.

PHP-Quelltext

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// magic_quotes_gpc = OFF
$inhalt $_POST['formularfeld'];
// Anwender hat 
// jögürt 'wie' auch "immer" peng
// eingeben

$inhalt addslashes($inhalt);
// Output wäre nun: jögürt \'wie\' auch "immer" peng

$sql "INSERT INTO tabelle SET feld = '".$inhalt."'";

// ......

$sql "SELECT feld FROM tabelle";
echo $row['feld'];
// Output ist nun: jögürt 'wie' auch "immer" peng


nun fragt sich meine Logik: Wo zum Geier sind die Backslashes abgeblieben, denn ich habe das Enfernen nicht mit stripslashes($row['feld']); angewiesen. Denn bisher hab ich das immer genau so gemacht: mit addslashes in die Datenbank und ein stripslashes, wenn ich die Daten wieder aus der DB geholt habe ... weil ich davon ausging, dass genau das in der DB steht, was ich auch gespeichert habe, nämlich: jögürt \'wie\' auch \"immer\" peng und NICHT: jögürt 'wie' auch "immer" peng

Du verstehst mein Dilemma? ;)

Aber vielleicht ist das einfach mein programmiererischer Irrtum und ich muss mir nur merken das die Backslashes wieder wech sind, wenn ich die Daten aus der DB hole :wallbash:
Man lernt halt nie aus :thumbsup:

TNS
Signatur von »TheNobody Style«

10

Freitag, 22. September 2006, 08:57

Ich verstehe das Dilemma, aber wie willst du denn sowas speichern, ohne die Backslashes?
Signatur von »mrhappiness« Ich denke, also bin ich. Einige sind trotzdem...

11

Freitag, 22. September 2006, 10:50

gar nicht ... ich bin nur bisher davon ausgegangen, dass die Backslashes auch in der Datenbank stehen bleiben ;)
Signatur von »TheNobody Style«