mysqli_real_escape_string() de-escapen?

[psoido]

Hi, heute eine Frage zu mysqli_real_escape_string(). Damit habe ich bisher eher sehr selten zu tun gehabt. Die Frage ist, wenn alle Daten bei INSERT INTO oder UPDATE per mysqli_real_escape_string() in die Datenbank geschrieben wurden/werden, (wobei das "wurden" nicht 100 pro sicher ist), wie werden dann die "escapes" bei einem SELECT wieder valide de-escaped? Reicht da ein stripslashes(nl2br($variable))? Oder wie macht Ihr das so?

[hausl]

wie werden dann die "escapes" bei einem SELECT wieder valide de-escaped?

Gar nicht, dann stehen die Daten korrekt in der DB und das ist auch gut so.

Da gehts ja um den Kontextwechsel und nichts anderes.

[psoido]

Gar nicht, dann stehen die Daten korrekt in der DB und das ist auch gut so.

Da gehts ja um den Kontextwechsel und nichts anderes.

? Da muss ich meine Frage wohl etwas ausweiten. Also, wenn die Daten (angenommen) alle mit mysqli_real_escape_string() in die DB geschrieben wurden, dann benötigt es bei einem SELECT ebenso ein mysqli_real_escape_string() bei der abzufragenden Data (bei z.B. WHERE), damit diese auch gefunden wird, weil die Data ist ja in der DB mit Escapes gespeichert, oder etwa nicht? (Mir sind zumindest \r\n und " in der DB aufgefallen) Desweiteren wäre diese abgerufene Data dann mit Escapes und würde zur weiteren Verarbeitung ein stripslashes(nl2br($variable)) benötigen, weil sonst die Escapes mit verarbeitet werden würden, bzw. bei einem echo angezeigt werden würden, oder etwa nicht? Ich frag, weil ich es nicht 100 pro weiß. Zudem bin ich ein wenig verwirrt, weil ein nl2br() notwendig ist um die \r\n in <br> umzuwandeln, aber ein stripslashes() ist (bei z.B. ") nicht notwendig, weil die Slashes in der Variable der DB Abfrage nicht mehr vorhanden sind. Da wäre meine Frage: In welchem Schritt verschwinden die Slashes (Escapes)? ... ohne dass die \r\n verschwinden?

EDIT: das Forum hier ist zugleich Beweis: Die Backslashes vor den einzelnen " wurden in meinem Text entfernt, aber die \r\n nicht!

EDIT: ach, ich hab einen Denkfehler wegen den Slashes... \\r\\n \" ... kleine kurze Verwirrung. Also wäre meine Frage. Wann/Wo werden die Escape-Slashes bei einem SELECT entfernt?

Ich muss meine Frage spezifizieren. In der diesbezüglichen Datenbank stehen \r\n (exakt so, mit einem Slash) und \" (exakt so, mit einem Slash). In der doc von mysqli_real_escape_string() steht:

Characters encoded are NUL (ASCII 0), \n, \r, \, ', ", and Control-Z.

\n und \r würden escaped, steht da. In meiner DB sind sie es scheinbar nicht? Hab ich da etwa ein Problem in der DB?
edit: man muss die " bei jedem edit in diesem Forum erneut mit zwei Slashes escapen, weil die gelöscht werden...

[hellbringer]

Da muss ich meine Frage wohl etwas ausweiten. Also, wenn die Daten (angenommen) alle mit mysqli_real_escape_string() in die DB geschrieben wurden

Das ist schon mal falsch. mysqli_real_escape_string() ist nur für die Übertragung zur Datenbank relevant. In die Datebank wird selbstverständlich der Wert ohne Escaping geschrieben.

dann benötigt es bei einem SELECT ebenso ein mysqli_real_escape_string() bei der abzufragenden Data (bei z.B. WHERE), damit diese auch gefunden wird, weil die Data ist ja in der DB mit Escapes gespeichert, oder etwa nicht?

Nein. Das Escaping ist nur für die SQL-Sprache notwendig, da hier bestimmte Zeichen eine besondere Bedeutung haben. Also überall dort, wo man Werte in SQL-Code einfügt, muss escapet werden. Mit der Datenbank selber hat das an sich nichts zu tun, sondern da gehts nur um die Sprache.

Zudem bin ich ein wenig verwirrt, weil ein nl2br() notwendig ist um die \r\n in <br> umzuwandeln

Weil hier ein Kontextwechsel von Text nach HTML stattfindet. In HTML haben \r und \n andere Bedeutungen als in reinem Text. Das hat aber weder mit SQL, noch mit Datenbanken zu tun.

Da wäre meine Frage: In welchem Schritt verschwinden die Slashes (Escapes)?

Dort, wo der SQL-Code interpretiert wird.

ohne dass die \r\n verschwinden?

\r und \n verschwinden nicht. Die bleiben immer da.

das Forum hier ist zugleich Beweis: Die Backslashes vor den einzelnen " wurden in meinem Text entfernt, aber die \r\n nicht!

Der Forumseditor ist Müll und voller Bugs.

[psoido]

Hallo hellbringer, ich hatte noch ein Edit in meinem letzten Beitrag.

Das ist schon mal falsch. mysqli_real_escape_string() ist nur für die Übertragung zur Datenbank relevant. In die Datebank wird selbstverständlich der Wert ohne Escaping geschrieben.

In meiner DB als *.sql Datei im Texteditor sind \r\n und \" je mit einem Slash gespeichert. Also wurde wohl bei " das Escaping in die DB gespeichert? Oder ist das wieder was anderes wegen als *.sql speichern? Seltsamerweise verschwinden diese Escape-Slashes bei " bei einem SELECT, aber bei r und n natürlich nicht. Wie das?

\r und \n verschwinden nicht. Die bleiben immer da.

Das ist das was mich verwirrt, weil einmal so und einmal anders, also der Unterschied bei \r\n und ". Kann es sein, dass es da eine missverständliche Situation gibt? Also eigentlich wäre eine Newline ein n und ein Rücklauf ein r (ohne Slashes). Damit diese nicht als Alphabet-Buchstaben angezeigt werden, sondern als Newline und Rücklauf, werden sie escaped/geslasht und sind es dann sozusagen schon, womit mysqli_real_escape_string() bei diesen beiden nichts zu tun hat. Kompliziert. Anders ist es bei allen anderen relevanten Zeichen, die noch nicht escaped/geslasht sind. Diese werden temporär escaped/geslasht.

[psoido]

... Editieren meines letzten Beitrags erspar ich mir die Mühe wegen dem Escapen...
Anmerkung:
Kann es sein ... Das komplette System muss resetet werden! Keine Alphabet-Buchstaben für Newline, Rücklauf, etc. verwenden. Dafür gibt es extra Zeichen, wie ¶, siehe
https://de.wikipedia.org/wiki/Absatzzeichen
Mit der Verwendung dieses Zeichens wäre die Situation nicht so missverständlich. Das Zeichen kann gerne auf die Tastatur, aber bitte nicht so wie das @.

[erc]

Kann es sein ... Das komplette System muss resetet werden! Keine Alphabet-Buchstaben für Newline, Rücklauf, etc. verwenden. Dafür gibt es extra Zeichen, wie ¶

Wie speichert man deiner Meinung dann ein ¶ Zeichen in der Datenbank? Solange Anweisungen/Steuerzeichen und Daten in einem String transportiert werden, hast du immer das Problem, dass Daten maskiert werden müssen.

[psoido]

Wie speichert man deiner Meinung dann ein ¶ Zeichen in der Datenbank? Solange Anweisungen/Steuerzeichen und Daten in einem String transportiert werden, hast du immer das Problem, dass Daten maskiert werden müssen.

Maskierung ist hier nicht das Problem, sondern die Verwendung von Alphabet-Buchstaben. Selbst ein # oder ein ~ wäre unmissverständlicher als r und n. Sonderzeichen und Steuerzeichen wären das Passende: \¶ oder selbst \# \~ oder eben was eigenes/neues. Damit wäre es dann unmissverständlich wie bei \"

[hellbringer]

In meiner DB als *.sql Datei im Texteditor sind \r\n und " je mit einem Slash gespeichert.

Logisch, das ist ja SQL-Code. Das hat aber nichts damit zu tun, wie die Daten in der Datenbank gespeichert werden.

Also wurde wohl bei " das Escaping in die DB gespeichert?

Nein.

Seltsamerweise verschwinden diese Escape-Slashes bei " bei einem SELECT, aber bei r und n natürlich nicht. Wie das?

Wieso verschwinden? Warum sind sie überhaupt da? Klingt danach, als wäre Datenmüll in der Datenbank.

Das ist das was mich verwirrt, weil einmal so und einmal anders, also der Unterschied bei \r\n und ". Kann es sein, dass es da eine missverständliche Situation gibt?

Es ist eigentlich ganz einfach:

Im SQL-Code wird SQL-Escaping verwende.
Im HTML-Code wird HTML-Escaping verwendet.

Ende der Geschichte.

Also eigentlich wäre eine Newline ein n und ein Rücklauf ein r (ohne Slashes).

Line Feed ("\n") und Carriage Return ("\r") sind Steuerzeichen und in Textform unsichtbar. Erst durch Escaping werden sie sichtbar.

[VPh]

Im SQL-Code wird SQL-Escaping verwende.
Im HTML-Code wird HTML-Escaping verwendet.

Und für Shell-Code gibt es auch noch eine eigene Funktion. Weil da eben auch wieder andere Zeichen besondere Funktionen übernehmen könnten, und unescaped zu unerwartetem Verhalten führen würden.

Den lass ich auch noch hier: https://php-de.github.io/jumpto/kontextwechsel/

[psoido]

Sollte mysqli_real_escape_string() auch bei SELECT verwendet werden?
Ich habe da nur was zum Vorgänger mysql_real_escape_string() gefunden. Das wurde auch bei SELECT verwendet. Ist das eher problematisch oder muss/sollte das sogar?

PS: hellbringer. so ein Link zum verweisenden Thema im geschlossenen ist ganz praktisch. Dann weiß ein jeder welches Thema der MOD mit "doppelt" meint, und das in alle Zukunft.

[hellbringer]

Sollte mysqli_real_escape_string() auch bei SELECT verwendet werden?

Wie oft muss ich mich noch wiederholen? Immer dann, wenn Werte in SQL-Code eingefügt werden. Ob im SQL-Code ein SELECT oder sonst was drin steht, ist doch irrelevant. Darum gehts auch gar nicht.

so ein Link zum verweisenden Thema im geschlossenen ist ganz praktisch. Dann weiß ein jeder welches Thema der MOD mit "doppelt" meint, und das in alle Zukunft.

Noch praktischer wäre es, man würde keine doppelten Threads zum gleichen Thema aufmachen. Dann hab auch ich weniger Arbeit.

[psoido]

So ist das also. Danke hellbringer für die nun unmissverständliche Antwort!

Das mit \r und \n verstehe wer will. Im *.sql dump sind \r \n und \" hinterlegt. Müsste es dann aber nicht \\r \\n und \" sein, wenn \r und \n escaped werden würden? Aber da ist dann wieder der Unterschied, dass einerseits das Escaping nur für die Datenübertragung benutzt wird und nicht im Speicher. Dann haben also die \" im *.sql dump gar nichts mit dem mysqli_real_escape_string() zun tun, sondern sind dort wegen *.sql dump-spezifischen Dingen. Da muss man erstmal drauf kommen...

[hellbringer]

Das mit \r und \n verstehe wer will. Im *.sql dump sind \r \n und " hinterlegt. Müsste es dann aber nicht \\r \\n und " sein, wenn \r und \n escaped werden würden?

\r und \n sind bereits die escapeten Varianten. Ohne Escaping sind diese Zeichen nicht sichtbar bzw. erfüllen ihre Funktion als Steuerzeichen.

mysql> CREATE TEMPORARY TABLE test ( value VARCHAR(255) );
Query OK, 0 rows affected (0.03 sec)

mysql> INSERT INTO test VALUES ("foo\nbar\nbaz");
Query OK, 1 row affected (0.00 sec)

mysql> SELECT value FROM test;
+-------------+
| value       |
+-------------+
| foo
bar
baz |
+-------------+
1 row in set (0.00 sec)

[psoido]

Irgendwie habe ich es jetzt kapiert. \r und \n sind je 1 Zeichen mit sozusagen 2 Bytes.