UTF_8 in MySQL

[Bobby]

Moin

Nun muss ich doch einmal nachfragen. Folgendes Szenariao:

Eine Webseite mit Formular, das bereits mit UTF-8 charset geladen ist, soll nach Absenden in die Werte in eine DB speichern. Die abgesendeten Werte kommen ja bereits UTF-8 codiert beim MySQL-Server an.

Soll nun der String wie er abgesendet wurde gespeichert werden also z.B. "Jörg" Oder soll dieser erst wieder encodiert werden und bei der Ausgabe wieder UTF-8 kodiert werden. Also "Jörg". Also wie sollte es in der DB stehen: "Jörg" oder "Jörg"

Gruß Bobby

[suit]

Also wie sollte es in der DB stehen: "Jörg" oder "Jörg"

natürlich "Jörg"

[Bobby]

Moin

Also wie sollte es in der DB stehen: "Jörg" oder "Jörg"

natürlich "Jörg"

Also muss ich wie vorgehen? Die DB-Felder sind als UTF gekennzeichnet. Wenn ich nun abspeichere werden die Daten "Jörg" entgegengenommen und so abgespeichert.

Wann und wie muss ich das Statement set names 'utf8'; senden? Odre muss ich noch mehr beachten?

Gruß Bobby

[Bobby]

Moin

erledigt. Es klappt. Danke

Gruß Bobby

[Auge]

Hallo

Also muss ich wie vorgehen? Die DB-Felder sind als UTF gekennzeichnet. Wenn ich nun abspeichere werden die Daten "Jörg" entgegengenommen und so abgespeichert.

Nein, es wird Jörg entgegengenommen und Jörg gespeichert.

Wann und wie muss ich das Statement set names 'utf8'; senden?

Haben Hopsel -- mit der anderen Methode -- und ich schon geschrieben.

Odre muss ich noch mehr beachten?

Als Ergänzung: Für die Felder der Datenbanktabellen, die Zeichenketten aufnehmen sollen (z.B. VARCHAR, TEXT), ist als Kollation auch UTF-8 (utf8_general_ci[1]) einzutragen.

[1] So benutze ich das jedenfalls. "ci" steht für Case Insensitive, was bedeutet, dass bei einer Suche über den Inhalt des jeweiligen Feldes von der DB-Engine nicht auf Groß- und Kleinschreibung geachtet wird.

Tschö, Auge

[suit]

[1] So benutze ich das jedenfalls. "ci" steht für Case Insensitive, was bedeutet, dass bei einer Suche über den Inhalt des jeweiligen Feldes von der DB-Engine nicht auf Groß- und Kleinschreibung geachtet wird.

Je nach Sprache böten sich noch anderen Sortierreihenfolgen an - z.B. utf8_german_ci (afaik ist da irgendwas mit der s-ss-ß-Sortierung anders) - aber das muss man afaik immer noch per Hand reinkompilieren - in der Doku finde ich drüber auch nichts (mehr) http://dev.mysql.com/doc/refman/5.1/de/charset-unicode-sets.html - ggf. ist diese aufgrund mangelnder Unterschiede zu uft8_unicode_ci rausgeflogen.

Jedenfalls sollte man als Sortierreihenfolge für den "Hausgebrauch" auf utf8_bin verzichten ;)

[Auge]

Hallo

[1] So benutze ich das jedenfalls. "ci" steht für Case Insensitive, was bedeutet, dass bei einer Suche über den Inhalt des jeweiligen Feldes von der DB-Engine nicht auf Groß- und Kleinschreibung geachtet wird.

Je nach Sprache böten sich noch anderen Sortierreihenfolgen an

Wusste ich es doch, irgendwas war da noch. :-)

Tschö, Auge

[dedlfix]

Hi!

Je nach Sprache böten sich noch anderen Sortierreihenfolgen an - z.B. utf8_german_ci (afaik ist da irgendwas mit der s-ss-ß-Sortierung anders) - aber das muss man afaik immer noch per Hand reinkompilieren - in der Doku finde ich drüber auch nichts (mehr) http://dev.mysql.com/doc/refman/5.1/de/charset-unicode-sets.html - ggf. ist diese aufgrund mangelnder Unterschiede zu uft8_unicode_ci rausgeflogen.

german gibt es nicht und gab es nie für utf8_*, wohl aber für latin1_*.

Jedenfalls sollte man als Sortierreihenfolge für den "Hausgebrauch" auf utf8_bin verzichten ;)

Jedenfalls sollte man fallabhängig entscheiden, welche Vergleichsregeln angepasst sind. Der "Hausgebrauch" erstreckt sich durchaus auch auf Passwörter.

Lo!

[Bobby]

Moin

Als Ergänzung: Für die Felder der Datenbanktabellen, die Zeichenketten aufnehmen sollen (z.B. VARCHAR, TEXT), ist als Kollation auch UTF-8 (utf8_general_ci[1]) einzutragen.

Das hatte ich bereits beachtet. Aber Danke für den Tip. Nun läuft alles wie gewollt.

Gruß Bobby

[Auge]

Hallo

Eine Webseite mit Formular, das bereits mit UTF-8 charset geladen ist, soll nach Absenden in die Werte in eine DB speichern. Die abgesendeten Werte kommen ja bereits UTF-8 codiert beim MySQL-Server an.

Soll nun der String wie er abgesendet wurde gespeichert werden also z.B. "Jörg" Oder soll dieser erst wieder encodiert werden und bei der Ausgabe wieder UTF-8 kodiert werden. Also "Jörg". Also wie sollte es in der DB stehen: "Jörg" oder "Jörg"

In der DB soll natürlich Jörg stehen. Um das zu erzwingen, sollten die verarbeitenden Skripte ebenfalls mit UTF-8 gespeichert sein und, das ist das wichtigere, die Kommunikation mit der Datenbank muss ebenfalls in UTF-8 erfolgen. Dazu setzt du als erstes nach der Herstellung der Verbindung folgenden Query ab: SET NAMES utf-8. Damit weist du die DB an, bei allen folgenden Operationen während der aktuellen Verbindung UTF-8 als Kodierung zu benutzen.

Tschö, Auge

[Hopsel]

Hi Auge!

Dazu setzt du als erstes nach der Herstellung der Verbindung folgenden Query ab: SET NAMES utf-8.

Mit aktuellen Versionen von PHP und MySQL kann man auch mysqli::set_charset verwenden.

MfG H☼psel

[Bobby]

Moin

In der DB soll natürlich Jörg stehen. Um das zu erzwingen, sollten die verarbeitenden Skripte ebenfalls mit UTF-8 gespeichert sein und, das ist das wichtigere, die Kommunikation mit der Datenbank muss ebenfalls in UTF-8 erfolgen. Dazu setzt du als erstes nach der Herstellung der Verbindung folgenden Query ab: SET NAMES utf-8. Damit weist du die DB an, bei allen folgenden Operationen während der aktuellen Verbindung UTF-8 als Kodierung zu benutzen.

Danke. Nun klappts wie gewünscht.

Gruß Bobby

[hotti (noreg)]

moin,

[..]Oder soll dieser erst wieder encodiert werden und bei der Ausgabe wieder UTF-8 kodiert werden.

Meine D-wiese: So roh wie möglich und so wenig wie möglich künstlich umkodieren.

Bspw. kommst Du ohne jegliche Umkodierungskünste aus, wenn ein utf-8-kodiertes Suchformular nach Begriffen sucht, die ebenfalls utf-8-kodiert in der DB vorliegen. Und Browser können utf-8 scholange.

Hotti