Darstellungsfehler durch Serverwechsel - Zeichencodierung

[martin2002]

Hallo.

Ich habe mein Contenido System auf einen anderen Server umgezogen...
Nun habe ich Probleme mit der Zeichencodierung.

Auf dem alten Server lief MySQL Version 5.0.26 mit Zeichensatz utf-8 und Verbindungszeichensatz utf8-unicode-ci
Auf dem neuen Server läuft jetzt MySQL Verson 5.0.26-log. Ansonsten sind die Einstellungen identisch.
Ich habe die Datenbank exportiert, die in utf8 gespeicherte sql datei nochmal in ANSI abgespeichert (die inhalte sind großteils iso-8859-1) und in die neue importiert.

Merkwürdig ist jetzt, dass wenn ich im Backend die fehlerhaften Umlaute neu hinschreibe und anschließend speichere taucht nur ein Fragezeichen an der stelle auf (lässt sich auch nicht als utf8 darstellen). Das einzige wo das nicht geschieht ist im TinyMCE, wenn ich also Artikelinhalte bearbeite sitmmt alles (diese sind großteils auch richtig Codiert) - bearbeite ich aber z.B. die Artikeleigenschaften, werden die Umlaute, ß usw. durch das Fragezeichen ersetzt.

Woran kann das liegen?
Nimmt contenido evtl. die Codierung der MySQL verbindung als Grundlage und TinyMCE die Mandanteneinstellungen?

Grüße,
Martin.

[stony]

benutze mal beim importieren "Latin-1"

[martin2002]

hab ich versucht... hat leider nichts bewirkt.

ich habe auch eine komplette neuinsallation mit leerer datenbank versucht, das hat aber auch nichts genützt - umlaute werden immer in "?" verwandelt.

kann das vielleicht noch an einer einstellung von apache liegen?

grüße,
Martin

[stony]

muß wohl ^_^

mir ist sowas noch nicht passiert! vielleicht jemand anders?

[wosch]

Wenn du mal suchst im Internet mit den Stichworten:
umlaute mysql zeichensatz
wirst du einige Boards finden wo das gleiche Problem behandelt wird.

Es liegt an einer inkompaktiblität der PHPmyAdmin-Versionen.

Hier mal ein Auszug aus einem anderen Board:

Hallo zusammen,
... weil ich das gleiche Problem bei mir auf dem lokalen Server habe.

Die Lösung habe ich gefunden.

Der Fehler liegt bei den neusten PHPmyAdmin Versionen 2.6.x, vielleicht auch schon etwas früher. Dort wird als Zeichensatz beim Export UTF-8 ab MySQL Version 4.x verwendet. Das ist falsch. Einstellen lässt sich das nicht im PHPmyAdmin Interface. Aber man kann das manuell ändern und zwar nur ein einziges Mal, dann geht's bei allen Folgeaktionen.

1. In das Verzeichnis von PHPmyAdmin gehen
2. Dort dann in das Verzeichnis libraries
3. Die Datei database_interface.lib.php suchen und in einem Editor (am besten mit Zeilennummern) öffnen und ändern wie folgt:

Zeile 161 bis 168 (einschliesslich)

Code: Alles auswählen

 
if (!empty($GLOBALS['lang']) && (substr($GLOBALS['lang'], -5) != 'utf-8')) { 
            $lang_utf_8_version = substr($GLOBALS['lang'], 0, strpos($GLOBALS['lang'], '-')) . '-utf-8'; 
            if (!empty($GLOBALS['available_languages'][$lang_utf_8_version])) { 
                $GLOBALS['lang'] = $lang_utf_8_version; 
                $GLOBALS['charset'] = $charset = 'utf-8'; 
            } 
        }

Diese Zeilen einfach auskommentieren und das sieht dann so aus:

Code: Alles auswählen

 
/*if (!empty($GLOBALS['lang']) && (substr($GLOBALS['lang'], -5) != 'utf-8')) { 
            $lang_utf_8_version = substr($GLOBALS['lang'], 0, strpos($GLOBALS['lang'], '-')) . '-utf-8'; 
            if (!empty($GLOBALS['available_languages'][$lang_utf_8_version])) { 
                $GLOBALS['lang'] = $lang_utf_8_version; 
                $GLOBALS['charset'] = $charset = 'utf-8'; 
            } 
        } 
        */ 

4. Datei dann abspeichern und hoch zum server und die vorherige überschreiben.

5. Freuen, daß es nu endlich geht

Wenn du keinen Zugriff auf den Code des PHPmyAdmin hast hilft dir vielleicht dieser Trick weiter:

Man muss auch nicht unbedingt den phpMyAdmin des Providers nutzen. Man kann sich selbst einen auf dem Webspace einrichten....die Daten hat man ja vom Provider für den Zugriff bekommen. Da kann man dann die von mir vorgeschlagene und auch funktionierende Änderung vornehmen.

Probier es aus, vielleicht hilft es dir.

[martin2002]

ne das hat leider auch nicht funktioniert....
hab die änderung vom hoster machen lassen und dann exportiert....
importiert hab ich dann wieder mit latin1. (und auch ascii und utf8)

ist aber nur noch schlimmer geworden

[martin2002]

ich hab mal mit dem den Server betreuenden Techniker gesprochen...
der Server läuft wohl auf utf8. er meint ich sollte alle inhalte vor dem senden an die DB mit "htmlentities()" transformieren, bzw. gleich utf8 verwenden.

Ich denke ich werde beides machen. Utf-8 hab ich schon für die Sprachen eingestellt. Wie bringe ich dem Contenido Backend bei, dass es dem Browser utf-8 als Codierung übermittelt? also ich meine:

Code: Alles auswählen

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Ich denke mal es geht am besten, wenn ich im Datenbankadapter DB_Contenido (bzw. elternklassen) die htmlentities-Funktion einbaue?

Grüße,
Martin.

[martin2002]

okay kommando zurück...

die idee alles auf utf8 zu ändern ist dumm... das macht nur probleme
ich arbeite allerdings gerade die htmlentities "codierung" in die db_mysql.inc ein. das funktioniert ziemlich gut - ich muss jetzt nur noch die alten inhalte in der datenbank konvertieren.

wenn ich damit fertig bin, dann kann ich ja mal die lösung präsentieren.

[Benki]

ich hab das Problem auch bei mehreren Domains, nachdem unser Hoster unsere 71 Domains migriert hat und nur Mist bei rausgekommen ist.

Komischer Weise tritt der Fehler nicht regelmäßig auf.

auf

http://www.bergzicken-oerlinghausen.de/ ... 3&idart=33

sind die Fehler zu sehen und auf

http://www.bergzicken-oerlinghausen.de/ ... 3&idart=30

nicht.

Und so steht die Headline vom ersten Artikel in der Datenbank:
%3CP%3ETeamst%E4rke+f%FChrt+zu+verdientem+Punktgewinn%3C%
2FP%3E

Kurioser Weise wird ja oben auf der Seite bei 'Aktuelle Meldungen' die ausgelesene Headline wieder korrekt angezeigt.

Hat jemand da mal nen Tip?

Ist überigens auf jeder migrierten Seite so bis auf eine Präsenz. Da ist es tatsächlich auf jeder Seite in Ordnung. Dort bin ich aber genau so vorgegangen wie bei allen anderen...

Danke vorab

[HerrB]

Vielleicht nicht für diesen Fall relevant, aber eine wunderbare Erläuterung, Hintergründe und Lösungen (allgemein zur Umlautproblematik bei mySQL-Datenbanken) findet sich hier:
http://www.mysqldumper.de/board/viewtopic.php?t=2313

Gruß
HerrB

[thanatos]

Moin moin,

das Problem mit den geänderten Sonderzeichen in Fragezeichen hatte ich heute auch. Ich bin mit meiner Contenido Version 4.8.8 von meinem localhost auf meinen Webserver umgezogen. Danach waren alle Sonderzeichen verändert, z.B. wurde aus der Kategorie Fußboden Fu?boden.

Ich hab mir den Link, den HerrB zuletzt gepostet hat, mal ganz genau durchgelesen und etwas ausprobiert, das tatsächlich funktioniert hat

1. Über PhpMyAdmin habe ich auf dem localhost meine Contenido-Datenbank exportiert. An den Export-Einstellungen habe ich nichts weiter verändert.
2. Ich habe in im PhpMyAdmin auf dem localhost in meiner Datenbank auf "Struktur" geklickt und mir das Kollation-Encoding angeschaut, in meinem Fall latin1_general_ci.
3. Auf meinem Webserver habe ich im PhpMyAdmin dasselbe gemacht, also das Kollation-Encoding der dortigen Datenbank angeschaut. Das war ebenfalls latin1_general_ci.
4. Das Problem liegt also darin, dass beide Datenbanken dasselbe Encoding verwenden, die Daten aber trotzdem falsch dargestellt werden. Im MySQLDumper-Beitrag (Link von HerrB) stand der Tipp, die Daten in dem richtigen Format abzuspeichern.
5. Also habe ich meine exportierte xxxx.sql Datei mit dem TextPad geöffnet unter "Save as..." das Encoding auf "default" (entspricht Latin1) gesetzt. Die Datei habe ich sicherheitshalber xxxx_latin1.sql genannt.
6. Beim Importieren der Datei auf dem Webserver habe ich im PhpMyAdmin als Zeichenkodierung für die Datei latin1 ausgewählt.
7. Jetzt nur noch einmal über das Setup die Contenido-Ordner mit der neuen Datenbank migrieren und: Fertig!

Bei mir hat das so wunderbar funktioniert. Alle Sonderzeichen sind wieder so, wie sie sein sollten und bislang habe ich noch keine Fehler im Front- oder Backend festgestellt. Ich hoffe, euch ist damit weitergeholfen und es klappt bei euch ebenso gut

Beste Grüße
Than