UTF-8, MySQL und PHP

[scope]

So, folgendes Problem:

Ich habe einen String, der erfolgreich mit der folgenden Funktion als UTF-8 erkannt wird
(Kommt aus einem Formular einer HTML-Seite mit UTF-8-Charset)

function is_utf8( $pString ) 
{
   # From http://w3.org/International/questions/qa-forms-utf-8.html
   
   return preg_match('%^(?:
         [x09x0Ax0Dx20-x7E]            # ASCII
       | [xC2-xDF][x80-xBF]            # non-overlong 2-byte
       |  xE0[xA0-xBF][x80-xBF]        # excluding overlongs
       | [xE1-xECxEExEF][x80-xBF]{2}  # straight 3-byte
       |  xED[x80-x9F][x80-xBF]        # excluding surrogates
       |  xF0[x90-xBF][x80-xBF]{2}    # planes 1-3
       | [xF1-xF3][x80-xBF]{3}          # planes 4-15
       |  xF4[x80-x8F][x80-xBF]{2}    # plane 16
   )*$%xs', $pString);
}

Meine PHP-Dateien sind als UTF-8 gespeichert,
und die MySQL Tabellen und Varchar-Spalten sind als utf8_unicode_ci kodiert.
Trotzdem werden Sonderzeichen beim Ablegen in der Datenbank falsch angezeigt ( 'ö' => 'ö')
Wenn ich den String vor der Ausgabe durch die utf8_decode-Funktion laufen lasse, ist die Ausgabe korrekt - wieso?
Woran kann das liegen?

 

[oneOeight]

hast du auch eine set names utf8 query gemacht? damit die mysql verbindung auf utf8 steht?

 

[scope]

Das ist etwas, das ich noch nie gehört habe.. was bedeutet das genau?

Edit:
Super, habs gefunden!

mysql_query( "SET NAMES 'utf8'" );

Besten Dank!

 

[2nd]

Trotzdem werden Sonderzeichen beim Ablegen in der Datenbank falsch angezeigt ( 'ö' => 'ö')

Wo werden die Sonderzeichen falsch angezeigt? Im phpMyAdmin?

Andere Frage: Warum utf8_unicode_ci anstelle von utf8_general_ci?

Hier stehen noch ein par nützliche Infos zu Zeichensätzen in MySQL DB: http://blog.koehntopp.de/archives/1424-MySQL-Zeichensatz-Grundlagen.html

2nd

 

[scope]

Wo werden die Sonderzeichen falsch angezeigt? Im phpMyAdmin?

phpMyAdmin und auf meiner Seite mit UTF-8-Charset.

Andere Frage: Warum utf8_unicode_ci anstelle von utf8_general_ci?

Andere Frage - warum nicht?

Hier stehen noch ein par nützliche Infos zu Zeichensätzen in MySQL DB: http://blog.koehntopp.de/archives/1424-MySQL-Zeichensatz-Grundlagen.html

2nd

Besten Dank!
Aber es funktioniert ja jetzt auch!

 

[oneOeight]

Andere Frage: Warum utf8_unicode_ci anstelle von utf8_general_ci?

das beantwortet die mysql doku

Die bedeutsamste Funktion in utf8_unicode_ci besteht darin, dass Erweiterungen unterstützt werden, d. h., wenn ein Zeichen mit einer Kombination anderer Zeichen gleichgesetzt wird. Beispielsweise wird im Deutschen und einigen anderen Sprachen ‘ß’ mit ‘ss’ gleichgesetzt.

utf8_general_ci ist eine ältere Sortierfolge, die Erweiterungen nicht unterstützt. Hier können nur 1 : 1-Vergleiche zwischen Zeichen durchgeführt werden: Vergleiche für die utf8_general_ci-Sortierfolge sind also schneller, aber unter Umständen weniger korrekt als Vergleiche für utf8_unicode_ci.

 

[Jakob]

Nur zur Vervollständigung: Diese *_ci Einstellung, gibt nur die collation, also die Art der Sortierung an. Nicht die Kodierung.

 

[2nd]

phpMyAdmin und auf meiner Seite mit UTF-8-Charset.

phpMyAdmin kannst Du bzgl. der Anzeige-Kodierung umstellen, geht auf der Startseite. Dann zeigt er es auch richtig an.

@oneOeight: Danke für den Hinweis (ich kenne die Doku und diese Seite ), aber ich wollte von Scope wissen, warum er utf8_unicode benutzt und nicht utf8_general, da utf8_general der Standard ist

Nur zur Vervollständigung: Diese *_ci Einstellung, gibt nur die collation, also die Art der Sortierung an. Nicht die Kodierung.

Jup.

_ci = Case Insensitive
_cs = Case Sensitive

Gibt an ob das ä hinter dem a z. B. kommt.

2nd

 

[mehlkelm]

Danke, hatte das Problem bei meiner lokalen server umgebung auch und "SET NAMES 'utf8'" hat es gelöst. Da stellt sich bei mir jedoch die Frage: Bei meinem debian server funktioniert alles bestens, ohne diese query. Wieso?
Ist möglicherweise das debian mysql paket so kompiliert, dass es das nicht mehr braucht?