Frage zum Wiki-Artikel „PHP MySQL API“

[dedlfix]

Tach!

Das ist ja auch der Grund, warum mysql_escape_string durch mysql_real_escape_string ersetzt (im Sinne von Empfehlung, das zu verwenden) wurde:
Es hat wild drauf los escaped, weil ihm die Zeichenkodierung der Datenbank herzlich egal war. Das neuere will die benutzte DB-Verbindung wissen (mysqli_escape_string ebenfalls), aber da haben wir den Salat, den du schildertest.

Es kann sein, dass mysql_escape_string() aus der Zeit vor dem Einzug der Beachtung der Zeichenkodierung stammt. Erst mit Version 4.5 (oder war es 4.1?) konnte man die verwendete Zeichenkodierung einstellen und auch Unicode wurde erst ab dem Zeitpunkt beachtet. Davor war die Kodierungseinstellung lediglich ein serverseitiger Parameter.

Richtige Anwendung beinhaltet die Beachtung des Zeichensatzes.

Es gibt mindestens eine asiatische Zeichenkodierung, bei der Bytes aus dem Bereich 00-7f in Kombination mit anderen Bytes ein bestimmtes Zeichen ergeben. Es kann dann zu Fehlfunktionen kommen, wenn man gemäß dieser Kodierung maskiert, aber der Server was anderes erwartet, und dann syntaktisch wichtige Zeichen erkennt, die eigentlich Nutzdaten sind. Ein konkretes Szenario ist mir noch nicht zufällig über den Weg gelaufen. Solch ein Szenario spielt aber keine Rolle, wenn Server und Maskierfunktionen ASCII-basierte Kodierungen annehmen. Alle zu maskierenden Zeichen liegen im ASCII-Bereich, und selbst addslashes() schafft es, die wirklich wichtigen davon zu berücksichtigen. Die unwichtigen beeinflussen nicht die Interpretation als Statement, sondern sind nur für Logfiles von Interesse.

Also theoretisch gibt es da Probleme, wenn man Fehler macht, hierzulande ist das aber kaum sicherheitstechnisch relevant, weil hier wohl eher keine nicht auf ASCII basierende Zeichkodierungen in den MySQL-Servern eingestellt sein werden.

dedlfix.