nicht angemeldet
Hello,
Ich meine, wenn man eine ganz normale Fehlerbehandlung betreibt, das Escaping stimmt, usw. Ich wäre jetzt nicht darauf gekommen, dass MySQL hier in den Datenstriom eingreift, nur weil die Codierung nicht stimmt. Wenn das Escaping passt, dürfte das die Datenbank doch eigentlich hier nicht interessieren - war mein Gedanke. Kannst Du mir erklären, mit welcher Berechtigung MySQL hier Daten verstümmelt (bitte bei ordnungsgemäßem Escaping!)?
Was würdest du tun? Irgendeinen Tod musst du bei der Sache sterben. Fakt ist, Mysql bekommt ein fehlerhaft kodiertes Statement, und da kannst du nicht erwarten, dass es fehlerfrei damit arbeiten kann. Statt Abschneiden käme lediglich noch die Ersetzung durch das "replacement character" (U+FFFD, �) in Frage mit irgendeinem anschließendem Versuch, im nachfolgenden Bytestrom wieder was Sinnvolles zu erkennen. Und das kann unter Umständen gleich zu einer Sicherheitslücke führen. Wenn es einmal aus dem Tritt gekommen ist, helfen auch keine korrekten Escape-Sequenzen, denn dann könnte man auch mittenrein treten unter der Annahme, dass das \ noch zur UTF-8-Sequenz hätte gehören sollen. Die Anzahl der Folgebytes einer UTF-8-Sequenz geht ja aus deren erstem Byte hervor.
Das Escapezeichen \ kommt doch im internen Datenpuffer gar nicht an. Es wird doch bereits von der Textschnittstelle ersetzt, die Befehlscode und Daten wieder voneinander trennt.
Es MUSS der Datenbanksoftware mMn egal sein, was in den Daten drinsteht.
Wenn ich in einem Textfeld ein Bild speichern will, dann darf MySQL das nicht verhindern.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
MudGuard