MySQL - eintragen von Daten geht schief... (Seite 3)

UFOMelkor schrieb:

Aber was hat das mit dem Thema zu tun?

Oft liegt die Ursache in banalen Zusammenhängen.

Ich habe mich mal an einer Konvertierungsfunktion versucht, aber leider funktioniert das Ganze nicht so wie ich es mir vorgestellt habe ....

Das hier war mein Ansatz...

$fehlerhafte_eingabe = array(\'€\',\'¤\',\'¦\',\'§\',\'¨\',\'©\',\'«\',\'¬\');
$korrekte_ausgabe = array(\'€\',\'¤\',\'¦\',\'§\',\'¨\',\'©\',\'«\',\'¬\');

function convert($str) {
return str_replace($fehlerhafte_eingabe, $korrekte_ausgabe, $str);
}


Die eigentlichen Arrays sind natürlich deutlich länger, diese hier sind nur ein kleines Beispiel.

Viele Grüße
Johnny

Hallo Johannes

Ich bin momentan an einem Skript was auch str_replace verwendet dran.
Wenn ich Teil 1 in eine Datei verschiebe und diese dann include funktioniert das mit dem Ersetzen nicht mehr.

Noch habe ich keine Erklärung dafür das wenn ich die Variablen auf der Einstiegsseite lasse es mit dem Ersetzen funktioniert.

Gruß
Jörg


//Teil 1
$suche[1] = \'&\';
$ersetzen[1] = \'%26\';
$suche[2] = \'ä\';
$ersetzen[2] = \'%C3%A4\';
//Teil 2
$page = str_replace($suche, $ersetzen, $row->page_title);
echo $page;

@Pohl:
Die Funktion kennt die beiden Variablen $fehlerhafte_eingabe und $korrekte_ausgabe nicht, entweder direkt in der Funktion definieren oder in der Funktion ein "global $fehlerhafte_eingabe, $korrekte_ausgabe;" integrieren.

@joerg: Ist der include vielleicht an der falschen Stelle...? Der Codeauschnitt, den Du da gepostet hast, reicht, denke ich, nicht, um einen Fehler zu finden.

Hallo Matthias

Als es vorhin nicht funktioniert hatte habe ich die selbe Reihenfolge gehabt im Skript mit oder ohne includen.

Jetzt funktioniert es plötzlich einwandfrei.
Keine Ahnung was los war ich bin sogar soweit daran zu glauben das mein Server einen Schluckauf hatte.

Also vergiss meinen Beitrag davor einfach.

Gruß
Jörg

UFOMelkor schrieb:

So gut ich weiß ist MySQL case insensitive, Groß- und Kleinschreibung ist also egal.
...

Die Syntax ist CI, Datenbank-, Tabellen- und Spaltennamen nicht.
Passe hat dir da einen ziemlich guten Tipp gegeben.
Das ganze Kombiniert mit etwas OOP und etwas Kreativität und die komplette Operation zum speichern und validieren von Benutzereingaben kann mit wenigen Zeilen Code Ãœberstanden sein. zB.


private function _newPost() {
$table = $this->_getTable(\'Comments\');
$table->bind(Request::getString(\'newComment\',\'array\'));
$table->store();
}


Und das tolle ist man kann es immer und immer wieder verwenden, OOP halt.
Aber ich komm vom Thema ab....

Pohl schrieb:

Das hier war mein Ansatz...

$fehlerhafte_eingabe = array(\'€\',\'¤\',\'¦\',\'§\',\'¨\',\'©\',\'«\',\'¬\');
$korrekte_ausgabe = array(\'€\',\'¤\',\'¦\',\'§\',\'¨\',\'©\',\'«\',\'¬\');

function convert($str) {
return str_replace($fehlerhafte_eingabe, $korrekte_ausgabe, $str);
}

Der Ansatz ist überflüssig, PHP bietet bereits die entsprechende Lösung.

www.php.net/mb_string

Ultima schrieb:
Du könntest auch überprüfen von wo die Formulardaten kommen, und wenn das nicht deine Domain ist diese Ignorieren. Das hält allerdings nur noob-bots ab.

Wie willst du das implementieren? Abgesehen von einer sessionbasierten Lösung fällt mir nur der Referrer ein, und der schließt die User aus, die ihn nicht übertragen lassen.

Ultima schrieb:
Das ganze Kombiniert mit etwas OOP und etwas Kreativität und die komplette Operation zum speichern und validieren von Benutzereingaben kann mit wenigen Zeilen Code Ãœberstanden sein. zB.


private function _newPost() {
$table = $this->_getTable(\'Comments\');
$table->bind(Request::getString(\'newComment\',\'array\'));
$table->store();
}


Und das tolle ist man kann es immer und immer wieder verwenden, OOP halt.
Aber ich komm vom Thema ab....

Und wo erfolgt die Validierung in deinem Beispiel bzw. wo reagierst du auf fehlerhafte Eingabewerte? Ganz so einfach ist auch OOP nicht

Ja ich meinte den Referrer.

Das Validieren übernimmt alles die Statische Klasse Requet.
Das man die erst mal schreiben muss ist klar (sowie die Table Klasse), aber wenn man es erst einmal hat dann hat mans und kann es immer wieder Verwenden je nach dem wie Flexibel das ganz ist.

Hier ein Beispielscipt von Joomla JRequest

api.joomla.org/__filesource/fsource_Joomla-Framework_Environment_joomlaenvironmentrequest.php.html

Es ging mir nicht darum, die Vorteile von OOP in Frage zu stellen, ich nutze selber für jede noch so kleine Seite OOP. Allerdings bleiben bei deinem Code-Beispiel einige Fragen übrig. Woher weißt die Request-Klasse, wogegen sie validieren muss? Klar, einige Standard-Sachen kann man herausfiltern, aber spätestens wenn es darum geht, nur gültige Emailadressen zu erlauben, ist die Request-Klasse überfordert (sofern man ihr nicht weitere Parameter übergibt).

Aber vermutlich reden wir aneinander vorbei und es ging dir bei der Methode nur um das Speichern des Kommentars. Dann bleibt aber immer noch eine Kleinigkeit auszusetzen:
private function _newPost($sComment) {
$table = $this->_getTable(\'Comments\');
$table->bind($sComment);
$table->store();
}

Das Ãœbergeben eines Parameters macht die Methode wesentlich flexibler in ihrer Anwendung, denn zum Speichern muss sie ja schließlich nicht wissen, woher sie den Text bekommt

Die Speicheroperation bekommt ein Array übergeben mit den Daten aus dem Formular, und wenn die Namen der Inputs und der Spalten in der Tabelle der Datenbank gleich sind kannst du sie direkt speichern.

Die statische Klasse Request Filtert grundsätzlich alles raus und mit entsprechenden Parametern kannst du das Filterverfahren auf deine die Anforderung anpassen. Email Adressen zu Validieren ist nicht Ihre Aufgabe aber das nachträglich zu machen sollte nicht das Problem sein.

Ich arbeite mit diesen Operationen und Klassen schon länger, es funktioniert einwandfrei und spart viel Arbeit, vor allem wenn man viele Benutzereingaben / Formulare zu prüfen hat.