MySQL character set latin1

Deutsches Forum
1

Hallöchen,

neues Problem: Ich habe gestern einen aktuellen Shop (4.5.0) online gestellt auf Linux-Server, und diesmal KEIN utf-8 genommen, da bei deutsch und englisch eigentlich kaum nötig (außer evtl. für Mailadressen mit exotischen idn-Domains, aber die sind ein Glück mehr als selten).

Nun bekomme ich aber die altbekannten Umlautfehler, da MySQL-Server (5.1.x) auf Linux (zumindest OpenSuse) standardmäßig intern mit uft-8 laufen. Früher konnte man sich mit:

[mysqld]
default-character-set = latin1
default-collation = latin1_german1_ci

in der my.cnf behelfen, das klappt aber seit längerem nicht mehr, und ich finde bisher einfach keine Möglichkeit es anders zu lösen, als in allen CMS/Shop/DB-System auf unserem Server manuell folgenden Eintrag zu ergänzen (nach DB-connect):

SET NAMES latin1

Dies gilt nun halt auch für Oxid, d.h. damit es bei mir auf Linux sauber mit latin1 läuft, muss ich in der Datei /core/oxdb.php die Funktion getDb() am Ende wie folgt ergänzen:

if ( $myConfig->isUtf() ) {
            self::$_oDB->execute( 'SET NAMES "utf8"' );
            self::$_oDB->execute( 'SET CHARACTER SET utf8' );
            self::$_oDB->execute( 'SET CHARACTER_SET_CONNECTION = utf8' );
            self::$_oDB->execute( 'SET CHARACTER_SET_DATABASE = utf8' );
            self::$_oDB->execute( 'SET character_set_results = utf8' );
            self::$_oDB->execute( 'SET character_set_server = utf8' );
        } else {
            self::$_oDB->execute( 'SET NAMES latin1' );
        }

Nun die Frage: Ist das Fehlen des Codes ein Bug, wäre die Ergänzung ein Feature, oder bin ich völlig auf dem Holzweg und man kann es doch irgendwie per my.cnf-Option lösen?
Kann mir jemand folgen und ist richtig fitt in Mysql? Ich wäre über jeden Tipp dankbar! :wink:

Lg

2

Du hast nicht gesagt ob dein umlautfehler beim Wechsel vom entwicklerserver auf produktionsdatenbank passiert ist?! Ich hatte beim letzten einspielen des mysqldumps das gleiche Problem. Da es aufwãndiger gewesen wäre den mix aus latin1/utf8 im nachhinein auf utf8 zu bringen habe ich den mysqldump explizit mit dem Set Parameter für latin1 gestartet. Alle Tabellen wieder gelöscht und default kollation ebenso auf latin gesetzt. Mit der sauberen latin1 sql Datei gab es dann keine konvertierungsfehler mehr. Nachträglichen konvertieren schlägt oft fehl,daher würde ich den gleichen weg gehen und du spart dir Änderungen an der ms.cnf.

3

Sowie Änderungen am Core… ! Rechtschreibfehler sind meinem desire hd Mobil geschuldet;)

4

Okay, danke für den Tipp, aber auch mit explizitem latin-dump geht es leider nicht. Das File ist auf jeden Fall clean, aber unsere Server-DB speichert halt intern trotzdem per uft-8 (evtl. nur bei OpenSuse?) und spuckt es per default auch so wieder aus.

Klar sind core-Änderungen pfui, aber es hilft echt nichts anderes und stören tut der Code ja niemanden. Von daher habe ich eher die Hoffnung, die Entwickler davon überzeugen zu können, dass fest zu integrieren (evtl. noch plus die anderen SET-Einträge wie bei utf-8, aber die sind ja teilweise redundant)… :wink:

Vorher möchte ich aber möglichst 100%tig ausschliessen können, dass es noch andere Lösungen für mich gäbe. Also haut rein, weitere Ideen sind willkommen! :slight_smile:

5

Ich denke du hast recht, “SET NAMES latin1” fehlt, und außerdem glaube ich das ‘SET NAMES “utf8”’ bei utf-8 ausreichend wäre.

6

Ja, ich denke auch, man sollte es mal im Bugtracker eintragen. Es wird auch nichts mit OpenSuse zu tun haben, sondern seit MySQL 4.1.2 wird halt in UTF-8 gespeichert.

Hier hat sich einer Mühe gegeben, es ausführlich zu erklären:
http://forum.mysqldumper.de/die-umlautproblematik-was-wieso-was-tun-t2313.html

und dies sollte man natürlich auch kennen:
http://dev.mysql.com/doc/refman/5.1/de/charset-connection.html

von daher stimmt es auch, dass dies reichen würde:

    if ( $myConfig->isUtf() ) {
        self::$_oDB->execute( 'SET NAMES utf8' );
    } else {
        self::$_oDB->execute( 'SET NAMES latin1' );
    }

der Rest ist redundant…

Evtl. weitere Einwände oder Ideen?

7

Mit dem Code gehe ich d’accord, einen kleinen Einwand habe ich: MySQL speichert die Daten intern nicht immer als utf-8. Das steht zwar so in dem verlinkten Text, MySQL speichert die Daten aber intern mit dem in der jeweiligen Spalte angegebenen Zeichensatz. Für den Anwender spielt das keine Rolle, weil MySQL die Daten automatisch beim Erhalt und Versand umwandelt, dafür stehen die Defaults wohl normalerweise auf latin, bei dir aber auf utf-8, daher benötigst du das ‘SET NAMES latin1’.

8

Hm, okay, mag sein (obwohl ich es woanders schon mal gelesen hatte), aber bin ich echt der einzige mit dem “Problem”? Und wie stelle ich MySQL anders ein? Kann es sein, dass es nur per command-line-option beim Aufruf des Daemons funzt? Echt schräg, ich dachte, ich hätte die Thematik längst verstanden und hatte auch jahrelang keine Probleme mit UTF-8 (nach einigen Startschwierigkeiten), und nun das Ganze andersherum, unglaublich… :frowning:

Macht es sich denn überhaupt spürbar bemerkbar, aus Performancegründen auf UTF-8 zu verzichten (habe ich bei kleinen bis mittelgroßen CMS/Shops bisher nie festestellen können)? Sonst bleibe ich nämlich in Zukunft doch dabei und damit auf der sicheren Seite, was die internationalen Sonderzeichen angeht. :wink:

Nebenbei bemerkt kam ich nach länderen Experimenten mit eben diesen (IDN-)Zeichen darauf, dass man aus “deutscher Sicht” als Collation besser latin1_german1_ci statt latin1_general_ci, und utf8_unicode_ci statt utf8_general_ci nimmt. Dann bleiben auch die Umlaute korrekt sortiert. Aber das ist ein etwas anderes Thema und hat ja mit der DB-Verbindung nix zu tun.

9

Wie man den Default-Wert setzt da muss ich passen. Ich würde aber sagen das gehört im core geändert, so dass es unabhängig vom Default funktioniert. Auch mit Performancedaten zu utf-8 kann ich nicht dienen, solange keine Performanceprobleme da sind, würde ich immer utf-8 benutzen. Und wenn doch Performanceprobleme auftauchen, bezweifle ich dass sich die dann durch Umstellung auf Latin lösen lassen. Aber vielleicht hat ja jemand genaue Zahlen oder Erfahrungen? Würde mich auch interessieren.

Guter Tipp mit den Collations!

10

Ja, ich bleibe nun wohl auch bei UTF-8, da ich in einer integrierten DB schon genug Sonderzeichen gefunden habe, die es halt in latin1 nicht gibt (das übersieht man anfangs schnell mal). Insgesamt betreibe ich seit Jahren die meisten (eher kleinen) Sites eh nur mit UTF-8, und habe auch nie Performanceprobleme deswegen bemerkt. Evtl. sieht das bei richtig großen Shops anders aus, aber egal. Auf dieses Sonderzeichengenerve habe ich jedenfalls echt keinen Bock mehr, und meine Kunden natürlich auch nicht… :wink:
Mit UTF-8 ist und bleibt man definitiv auf der sicheren Seite und hat eine Sorge weniger.

Nun denn, trotzdem ging es ja auch ums Prinzip, also habe ich mal einen Bugeintrag dafür erstellt: https://bugs.oxid-esales.com/view.php?id=2937