UTF-8, MySQL und PHP

scope

Mitglied
Thread Starter
Mitglied seit
24.01.2005
Beiträge
4.115
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)

PHP:
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

Mitglied
Mitglied seit
23.11.2004
Beiträge
54.545
hast du auch eine set names utf8 query gemacht? damit die mysql verbindung auf utf8 steht?
 

scope

Mitglied
Thread Starter
Mitglied seit
24.01.2005
Beiträge
4.115
Das ist etwas, das ich noch nie gehört habe.. was bedeutet das genau?

Edit:
Super, habs gefunden!

PHP:
mysql_query( "SET NAMES 'utf8'" );
Besten Dank!
 
Zuletzt bearbeitet:

scope

Mitglied
Thread Starter
Mitglied seit
24.01.2005
Beiträge
4.115
2ndreality schrieb:
Wo werden die Sonderzeichen falsch angezeigt? Im phpMyAdmin?
phpMyAdmin und auf meiner Seite mit UTF-8-Charset.

2ndreality schrieb:
Andere Frage: Warum utf8_unicode_ci anstelle von utf8_general_ci?
Andere Frage - warum nicht? :D

2ndreality schrieb:
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

Mitglied
Mitglied seit
23.11.2004
Beiträge
54.545
2ndreality schrieb:
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

Mitglied
Mitglied seit
05.01.2004
Beiträge
1.070
Nur zur Vervollständigung: Diese *_ci Einstellung, gibt nur die collation, also die Art der Sortierung an. Nicht die Kodierung.
 

2nd

Mitglied
Mitglied seit
25.07.2004
Beiträge
9.020
scope schrieb:
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 :)

Jakob schrieb:
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
 
Zuletzt bearbeitet:

mehlkelm

Registriert
Mitglied seit
10.11.2006
Beiträge
1
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?