nicht angemeldet
Tach!
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.
Das funktioniert bei UTF-8. Es gibt aber asiatische Kodierungen, da musst du zuerst die Bedeutung aus dem Datenstrom lesen, bevor du zwischen \ und dessen Byte als Bestandteil eines anderen Zeichens unterscheiden kannst. Nicht umsonst arbeitet mysql_real_escape_string() kodierungsabhängig, was nur für UTF-8 und Latin1 (und einige andere) unbeachtet gelassen werden kann.
Wenn du als Programmierer solche uneindeutigen Kodierungen beachten müsstest, würdest du vermutlich auch erst die Zeichendekodierung und dann erst die Demaskierung vornehmen. Und das generell, nicht mal so und mal so.
Es MUSS der Datenbanksoftware mMn egal sein, was in den Daten drinsteht.
Nö. Ein Computer kennt den Zustand 'egal' nicht. Der braucht klare Verhältnisse für alle Lebenslagen. Wenn wir es mit im Statement eingebundenen Daten zu tun haben, kann die Kodierung nicht egal sein, denn sonst kann das Statement nicht richtig interpretiert werden. Bei Prepared Statements und den damit einhergehenden separaten Wegen für Statement und Daten ist das zunächst was anderes. Doch für die Weiterverarbeitung wird es dann wieder interessant, wenn MySQL die Zeichen erkennen muss, um korrekte Stringverarbeitung hinzubekommen.
Wenn ich in einem Textfeld ein Bild speichern will, dann darf MySQL das nicht verhindern.
Das Feld spielt an dieser Stelle noch gar keine Rolle. Wir sind beim Lesen und Interpretieren des Bytestroms. Du brauchst auf alle Fälle eine Unterscheidung, zwischen den Fällen, wo MySQL die Zeichen interpretieren muss und wo nicht. Wenn du die Bilddaten im Statement mitschicken willst, hast du sowieso erstmal das Problem zu lösen, wie du die Daten dort derart reinbekommst, dass nicht irgendwelche Zeichen darin als Statementbestandteil oder gar String-Ende aufgefasst werden. Die Daten müssen also auf der einen Seite "vertextet" und auf der anderen Seite wieder zu in Benärdaten konvertiert werden können.
Zurück zum Feld, hier muss MySQL auch unterscheiden können, ob es dafür Stringverarbeitung braucht oder nicht. Du kannst natürlich Binärdaten jenseits von BLOBs unterbringen, solltest das aber nicht ohne 'bin' als Kodierungsangabe machen.
Wenn du den Zustand "egal" haben möchtest, musst du eine MySQL-Version vor 4.1 nehmen. Die hatten das Multi-Byte-"Problem" nicht (und auch keine Möglichkeit der Unicode-Stringverarbeitung). Textschnittstelle vs. Binärdaten musste aber auch damals schon beachtet werden.
dedlfix.
MudGuard