Warnung: file_put_contents(/home/www/web1/html/php_dev/test.txt) [function.file-put-contents]: failed to open stream: Permission denied in /home/www/web1/html/php_dev/sys/lib.activity.php (Zeile 58)
Formulartextfelder d. Länge X vs. Varchar(Y)-Speicherung [Archiv] - PHP-Scripte PHP-Tutorials PHP-Jobs und vieles mehr
ebiz-webhosting
- Ad -
php-resource




Archiv verlassen und diese Seite im Standarddesign anzeigen :
Formulartextfelder d. Länge X vs. Varchar(Y)-Speicherung


 
KillUrMind
03-03-2010, 18:12 
 
Hallo liebe PHP-Resource-Gemeinde,

um es schnell auf den Punkt zu bringen: Ich habe ein Formular mit div. Feldern und möchte die eingegebenen Daten in einer Datenbank speichern. Mein Problem nun ist, dass ich eine Maximallänge der Eingabe angeben möchte und die Daten UTF-8-kodiert speichere. Durch das UTF-8 verändert sich jedoch die Länge des Eingabe- bzw. Speicherstring, da ja z. B. Umlaute o. Ä. mit mehreren Zeichen i. d. DB gespeichert werden.
Kann man nun irgendwie festlegen, wie groß das Varchar-Feld für z. B. ein 250 Zeichen langes Formularfeld sein muss?

Vielen Dank für alle Antworten!

 
AmicaNoctis
03-03-2010, 18:15 
 
Hallo,

es heißt ja varchar und nicht varbyte, weil es X Zeichen speichern kann, auch wenn es X + k Bytes sind. Die Antwort lautet also: 250

Gruß,

Amica

 
KillUrMind
03-03-2010, 19:45 
 
Ja schon klar, nur wenn ich dem User mitteile "nur 250 Zeichen" und das ganze utf8-kodiert (wird ja seitens MySQL ausgeführt) speichere, wird z. B. ein ü in 2 Zeichen übersetzt. D. h. ich muss das doch berücksichtigen in meiner DB, da dann ja aus 250 Zeichen sehr viel mehr werden können. Oder stelle ich mich da gerade zu blöd an.

 
AmicaNoctis
03-03-2010, 19:52 
 
Nein, ein ü ist ein Zeichen, dass es intern zwei Byte sind, spielt absolut keine Rolle. Hör auf, Zeichen und Byte zu verwechseln ;)

Es ist so, wie ich sage: varchar(255) nimmt auch 255 'ü's, probier's einfach aus mit varchar(10), wenn du mir sowieso nicht glauben willst.

Edit: :rtfm: Oder sieh ins Manual, dafür ist es ja da.

 
KillUrMind
03-03-2010, 20:36 
 
Okay krass, hast Recht - hatte ich wohl was falsch gemacht gehabt, glaube weil ich in dem einen Table noch ISO hatte.
Wie schauts mit Backslashes von mysql_real_escape_string() aus, die ja mit reinkommen?

Danke.

 
AmicaNoctis
03-03-2010, 20:44 
 
Wie schauts mit Backslashes von mysql_real_escape_string() aus, die ja mit reinkommen?


Wie es damit ausschaut? Gut, denke ich.

Ernsthaft: Ich versteh die Frage nicht. Was soll damit sein?

Edit: Jetzt hab ich kapiert, was du meinst. Die werden ja nicht in die DB geschrieben, sondern sind nur da, um Sonderzeichen im String zu escapen. Das ist wie bei PHP: Du schreibst zwar " foo=\"bar\"", aber ja nur, weil " die Sonderbedeutung "Hier ist Schluss mit String" hat und daher aufgehoben werden muss. Wenn du den Inhalt dann rausholst, ist ja auch kein Backslash mehr drin, oder?

Wie lange machst du das jetzt?

 
TobiaZ
03-03-2010, 22:41 
 
Wie schauts mit Backslashes von mysql_real_escape_string() aus, die ja mit reinkommen? Bullshit. die kommen NICHT mit rein! ;)
Auch hier: Versuch macht kluch.

 
KillUrMind
04-03-2010, 00:15 
 
Wie es damit ausschaut? Gut, denke ich.

Ernsthaft: Ich versteh die Frage nicht. Was soll damit sein?

Edit: Jetzt hab ich kapiert, was du meinst. Die werden ja nicht in die DB geschrieben, sondern sind nur da, um Sonderzeichen im String zu escapen. Das ist wie bei PHP: Du schreibst zwar " foo=\"bar\"", aber ja nur, weil " die Sonderbedeutung "Hier ist Schluss mit String" hat und daher aufgehoben werden muss. Wenn du den Inhalt dann rausholst, ist ja auch kein Backslash mehr drin, oder?

Wie lange machst du das jetzt?

Okay, ich dachte die werden mitgespeichert.

 
AmicaNoctis
04-03-2010, 01:30 
 
Okay, ich dachte die werden mitgespeichert.

Dann würden sie ja auch wieder rauskommen, das wäre totaler Unfug und ergibt keinen Sinn. ;)


Alle Zeitangaben in WEZ +2. Es ist jetzt 23:36 Uhr.