Hallo Stucki, Michael Stucki schrieb: > Hallo Peter, > >> Leider ist das ein sehr weit verbreiteter Irrglaube! >> >> ---------------------------------------------------------------- >> Das MySQL-Modul von PHP benutzt IMMER latin1 als Zeichensatz für >> die Verbindung zw. PHP und MySQL! >> ---------------------------------------------------------------- > > Das wäre mir neu.
Gut, dann nochmal ganz akademisch genau. ;) Das MySQL-Modul von PHP benutzt immer den Zeichensatz, mit dem libmysql bzw. MySQL kompilliert wurde(default=latin1)! vgl.: [1] [2] Fakt ist jedenfalls, dass der Zeichensatz MySQL-Verbindung von PHP aus in 98% der Fälle 'latin1' ist, weil das nur durch eine dieser drei Möglichkeiten zu ändern ist: 1. Kompillieren der libmysql-Bibliothek mit './configure --with-charset=utf8' 2. my.cnf: 'skip-character-set-client-handshake' 3. my.cnf: 'init-connect=SET NAMES `utf8`' (o.ä.) IMO ist das alles nichts für den üblichen Hausgebrauch! Daneben beeinflusst es möglicherweise andere Applikation, die noch mit dem MySQL-Server arbeiten, und evtl. nicht auf solche ungewöhnlichen Settings vorbereitet sind. Für TYPO3 speziell steht dafür setDBinit zur Verfügung. :-> >> D.h. MySQL rekodiert ggf. automatisch zw. dem Zeichensatz der >> Verbindung und der Datenbank. Da das sowohl bei der Abfrage, als >> auch beim Rückliefern des Ergebnis passiert, merkt man das >> innerhalb TYPO nicht! >> >> Sobald jedoch eine andere Anwendung (phpmyadmin, o.a.) mit der >> Datenbank arbeitet fällt das Problem auf (Im übrigen auch bei einem >> Backup mit mysqldump). > > Das wäre der Fall wenn man setDBinit nutzen würde, weil das nur von > TYPO3 genutzt würde. Warum sollte es mit setDBinit Probleme geben? Hast Du da ein Beispiel? Probleme entstehen dann, wenn die Zeichensatz-Variablen, die gesetzt sind, nicht zu dem faktisch verwendten Zeichensatz der Anwendung passen. > Aber wenn Server und PHP schon mit UTF-8 laufen gibt's da keine > Probleme. Was heisst denn "Server und PHP schon mit UTF-8 laufen" genau? Genau da im Detail liegt doch der Hase im Pfeffer! >> Merke: forceCharset immer nur zusammen mit setDBinit verwenden! >> Sonst gibt es >> a) doppelt UTF-8 kodierte Daten bei einer ut8-8 Datenbank oder >> b) UTF-8 kodierte Daten in einer Datenbank wo latin1 vorne draufsteht. > > All das ist möglich, aber nicht die Regel. Dutzende von Praxisbeispielen sagen anderes! Sobald forceCharset ohne weitere Massnahmen (siehe Anfang dieser Mail) gesetzt wird, passiert a) oder b) > Es ist möglich forceCharset ohne setDBinit zu verwenden wenn man > vorher sicherstellt dass der Server (MySQL), der Client (PHP) und die > Verbindung alle bereits mit dem gleichen Zeichensatz laufen. > > Das geht am einfachsten so: > > /etc/mysql/my.cnf, Abschnitt [mysqld]: > > character-set-server = utf8 Damit lege ich nur fest, dass Datenbanken, Tabellen und Felder, sofern kein expliziter Zeichensatz im CREATE angegeben ist, utf8 verwenden (Sofern dass beim gewünschten Feldtyp eine Rolle spielt). > skip-character-set-client-handshake Na gut, wenn man natürlich sagt, dass man den Zeichensatz-Wunsch des Client ignorieren soll, dann funktioniert das auch wieder. Aber, dass ist IMO nicht Sinn der Sache! Ausserdem dürfte das auf den wenigsten Servern so konfiguriert sein, bzw. ist im shared Hosting nicht zu beeinflussen. > Bedeutet: - MySQL-Server läuft mit UTF-8 - ... und zwingt auch den > Client dazu, das zu nutzen: Ignoriert (skip!) den Zeichensatz, den der Client beim Verbindungsaufbau anmeldet und zwingt den Client den Server-Zeichensatz zu nutzen. > http://mysql.openmirrors.org/doc/refman/5.1/en/server-options.html: > > # --character-set-client-handshake # Don't ignore character set > information sent by the client. To ignore # client information and > use the default server character set, use # > --skip-character-set-client-handshake; this makes MySQL behave like$ > # MySQL 4.0. > http://dev.mysql.com/doc/refman/5.0/en/charset-server.html Womit Du einen BUG in der MySQL-Dokumentation gefunden hast! :-> Laut [3] wirkt sich 'character-set-server = utf8' nur auf CREATE aus. Das habe ich bisher auch immer geglaubt. Aber, bei gleichzeitiger Verwendung von 'skip--character-set-client-handshake' hat es nach [4] dann tatsächlich auch noch die Auswirkung dass es den Zeichensatz der Verbindung festlegt. Damit ist "They have no other purpose" auf [3] eigentlich falsch. ;) >> P.S.: es gibt noch eine alternative/analoge Lösung zu setDBinit für >> den Mysql-Server, die ich aber nicht empfehlen würde: >> #init-connect=SET NAMES `utf8` > > Das würde vermutlich das gleiche tun wie obenstehende Konfiguration. Es ist eine der drei Möglichkeiten JEDEN Nutzer des MySQL-Servers zu zwingen standardmäßig utf8 zu verwenden (Wobei die Anwendung das anschließend nochmal selbst ändern kann). > Warum würdest du das nicht empfehlen? Weil jeweils nur die Anwendung/der Client weiss, in welchem Zeichensatz sie Ihre Daten abliefert, und in welchem Zeichensatz sie das Ergebnis erwartet! Und ein MySQL-Server, der wirklich ÜBERALL durchgängig utf8 verwendet, eher die Aussnahme, denn die Regel ist. Und, wenn eine Anwendung failsafe sein soll, muss sie das ganze so oder so nochmal prüfen und ggf. ändern. Dafür gibt es ja die 'character_set_%' Variablen. ;) > Ist doch besser so, denn dadurch wird die Änderung nicht nur von > TYPO3 angewendet sondern auch von externen Tools wie z.B. > phpMyAdmin... phpMyAdmin benutzt IMO immer utf-8, da passt tatsächlich immer alles. Aber eben nur, wenn die Daten in MySQL auch korrekt ausgezeichnet sind, sprich der hinterlegte Zeichensatz auch dem faktisch benutzten entspricht. Wenn utf-8 Daten in einer DB stecken, wo vorne 'latin1' draufsteht, dann ist jede Anwendung machtlos. Grundsätzlich halte ich es definitv für eine Aufgabe der Anwendung (und nicht des Servers) mitzuteilen welcher Zeichensatz bei der Kommunikation zw. Client und Server verwendet werden soll. > Liebe Grüsse - michael Liebe Grüße zurück, Peter [1] http://bugs.mysql.com/bug.php?id=19292 [2] http://dev.mysql.com/doc/refman/5.1/de/configure-options.html [3] http://dev.mysql.com/doc/refman/5.1/en/charset-server.html [4] http://dev.mysql.com/doc/refman/5.1/en/server-options.html P.S.: Ich erinnere mich auch an zurückliegende Tage, wo man bei unansehnlichen Zeichen in PhpMyadmin immer gesagt hat, ach da passt irgendwas in der Config bei PhpMyadmin nicht. Meine Erfahrung lehrt mir, dass in 99,9% aller Fälle dann irgendwo anders(!) etwas nicht in Ordnung ist. PhpMyadmin nutzt utf8 und (ein aktuelles!) MySQL kümmert sich wunderbar um das korrekte rekodieren. -- Peter Niederlag http://www.niekom.de * TYPO3 & EDV Dienstleistungen * http://www.typo3partner.net * professional services network * _______________________________________________ TYPO3-german mailing list TYPO3-german@lists.netfielders.de http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-german
