php/mySQLi: real_escape_string - Anwendungsfrage

[Wuppi]

Hallo zusammen

ich hab ein kleines Problem ... für ein neues Projektchen wollte ich direkt mal mit mySQLi anfangen - bisher nur mySQL genutzt - aber das fällt ja irgendwann aus php raus.

Ich hatte bisher immer eine kleine Funktion über der ich u.a. mysql_real_escape_string und trim gefahren habe - und was so angefallen ist:

Code: Alles auswählen

function checking($stringg) {
	$string = mysql_real_escape_string($stringg);
	$string = trim($stringg);
[...]
	return $string;
}

Bevor jetzt eine Variable per insert, replace, update in die DB ging, wurde diese halt mit checking(); angepackt. Hatte den Vorteil - übersichtlicher, kürzer, keine 100x mysql_, trim... im Quelltext usw. und wenn ich mal was testen wollte - in der Funktion.

Das ganze klappt mit mySQLi nicht mehr.
mysql_real.... wird nicht unterstützt - klar.
Ich hab dann $mysqli->real_escape_string($db_insert); gefunden. Nur kann ich das nicht wie gewohnt in der Funktion einsetzen. Ok - vielleicht falsch gedacht. Also hab ich es vor dem Query-String eingesetzt:

(vereinfachte Darstellung vom "vorgeplänkel")

Code: Alles auswählen

 
// $blabla kommt aus einem XML und enthält z.b. /Die%20Toten%20Hosen%20(Anfang%20-%20Ende%20'02)/ 
$blabla = checking($blabla); // (ohne den real_escape_string; also eigentlich im Moment nur trim ...)
$db_insert = "insert .... $blabla"; // schwer vereinfachte Darstellung ;) 
$mysqli->real_escape_string($db_insert);
$mysqli->query($db_insert);

Es klappt ... nicht wirklich. Das real_escape_string macht nicht das gleiche wie mysql_real_escape_string.
Von den 10.000 Datensätzen die ich gerade importieren wollte, gingen nur 8500 rein. Die anderen 1500 will SQL nicht so akzeptieren:

/Die%20Toten%20Hosen%20(Anfang%20-%20Ende%20'02)/

Wie man hier sieht ist vor dem 02) ein ' ... ende im Gelände. Mit mysql_real_escape ging das sauber in die DB.

Was mache ich hier (grundlegend) falsch? Gehe ich mit real_escape den falschen weg?

EDIT:
wenn ich vor der erstellung der Query-Strings mit

Code: Alles auswählen

            $blabla = $mysqli->real_escape_string($blabla);

arbeite, dann bekomm ich ca. 150 weitere Datensätze in die DB ... also auf die Variable $blabla klappt es. Aber ich habe ca. 10 Variablen wo das angewandt werden muß ... da wäre es mit der Funktion wieder schöner.

Code: Alles auswählen

function checking($stringg) {
	$string = trim($stringg);
        $string = $mysqli->real_escape_string($string);
	return $string;
}

klappt natürlich nicht

Gruß
Wuppi

[gn#36]

Es gibt auch bei mysqli noch einen prozeduralen Ansatz, den du nutzen kannst wenn dir die Objekte nicht liegen. Ansich verhält sich die Funktion/Methode aber gleich wie zuvor, d.h. du darfst nur den String angeben, der in das Query eingesetzt werden soll, nicht das Query selbst. Also sowas wie

Code: Alles auswählen

$string = $mysqli->real_escape_string($string);
$sql = "INSERT INTO tabelle (stringrow) VALUES('$string')";
$mysqli->query($sql); 

Alternativ auch:

Code: Alles auswählen

$string = mysql_real_escape_string($connection, $string);
$sql = "INSERT INTO tabelle (stringrow) VALUES('$string')";
mysqli_query($connection, $sql); 

Der einzige Unterschied zu vorher ist, dass du die Datenbankverbindung angeben musst - in der Prozedur ist das der erste Parameter der Funktion - [php:mysqli_real_escape_string].
Bei der mysql Erweiterung war die Angabe auch möglich und wenn man z.b. mit mehreren DBs gleichzeitig redet auch zwingend notwendig.

[Wuppi]

in dieser Variante hatte es ja geklappt - nur musste ich aber das komplette $string = $mysqli->real_e.... für jede Variable einfügen ... ich wollte das aber mit einer funktion machen - das wollte nicht wie klassisch.

Hab es jetzt aber rausbekommen:

Code: Alles auswählen

function checking($stringg) {
    global $mysqli;
	$string = trim($stringg);
	return $mysqli->real_escape_string($string);
}

jetzt kann ich vor jeder relevanten Variable in ein checking(VARIABLE); packen. Wie vorher. Das ist für mich im aktuellen projektchen nicht wichtig - aber meine etwas größere Datenbank - bis ich das alles durch korrigiert hätte (ja suchen/ersetzen *G*) - so passe ich die Funktion an und schwupp ist zumindest der Part schon mal kompatible Fehlerquellen: 0.

Wollte mit dem projektchen (ist nicht wirklich was großes) halt a) mysqli und b) Objektorientiert arbeiten - so noch kaum erfahrungen. Die andere DB wird wohl, weil einfacher zu migrieren, im prozeduralen Ansatz bleiben. Irgendwann mal

[gn#36]

Ich habe mir dafür mal irgendwann einen eigenen Database Abstraction Layer gebaut. Dann muss man nur in dem die Funktion austauschen, die vorher benutzt wurde, und zwar auch bei mysql_query und Konsorten.