WBCE CMS Forum

grindbatzn

Gast

Migration und Umlaute...

Ich weiß, nicht, bin ich deppert oder sonstwas..

Jedesmal das gleiche: DB exportieren, woanders importieren -> falsche Umlaute.
Es scheint egal zu sein, ob ich die Exportfunktion von PHPMyAdmin oder einfach das Backup-Modul verwende.

Wie stelle ich fest, welchen Zeichensatz der Dump hat? Wo könnte der Fehler liegen?
Egal was ich mache, ich kann nur wählen zwischen "??" oder den Rauten statt richtigen Umlauten...

(WIndows 7)

Beitrag geändert von florian (13.04.2020 14:25:51)

grindbatzn

Gast

Re: Migration und Umlaute...

Hmm - es passt alles - solange ich das UpdateScript nicht aufrufe..

florian

Administrator

Re: Migration und Umlaute...

Wenn Du Seiten migrierst, bei denen vorher als Zeichensatz Latin-1 (ISO 8859-1) eingestellt war, sind die Probleme - fürchte ich - unvermeidlich, da im Zuge der Migration/Update auf UTF-8 umgestellt wird (was mMn unumgänglich ist).

---

Code allein macht nicht glücklich. Jetzt spenden!

grindbatzn

Gast

Re: Migration und Umlaute...

Die alte Datenbank war UTF-8, der Dump war UTF-8 (zumindest hat mir Notepad++ das so angezeigt), die neue Datenbank ist UTF-8, und in phpMyAdmin werden die Umlaute auch richtig angezeigt.

Solange ich das Updatescript nicht aufrufe, werden die Umlaute ebenfalls noch richtig angezeigt.

NACH dem Updatescript muss ich auf Latin-1 schalten, damit die Umlaute richtig kommen. Was wird im Updatescript geändert? Kann es an der Datenbank-Klasse liegen?

grindbatzn

Gast

Re: Migration und Umlaute...

phpMyAdmin zeigt mir die Umlate richtig an.
WBCE zeigt sie falsch.
Ändere ich die Umlaute manuell in WBCE, zeigt sie mit phpMyAdmin falsch an.

Ich vertraue phpMyAdmin mehr als WBCE. Da steckt irgendwo der Wurm drin.

florian

Administrator

Re: Migration und Umlaute...

Von wo nach wo migrierst / updatest Du (also PHP-/WB-/WBCE-Version des Ausgangs- und des Zielsystems)?

Beim Updaten/Umziehen von WBCE-Versionen hatte ich dieses Problem definitiv noch nie. Nur wie gesagt beim Aktualisieren von älteren WB-Instanzen.

---

Code allein macht nicht glücklich. Jetzt spenden!

grindbatzn

Gast

Re: Migration und Umlaute...

Ja, es ist natürlich eine ältere WB-Instanz, da hab ich natürlich auch zuerst mal gesucht.

Aber: Es deutet nichts darauf hin, dass das Umlaut-Problem durch die Migration als solche entstanden ist. War vorher UTF-8, wars zwischendrin, ist jetzt.
Und: phpMyAdmin zeigt mir die Umlaute auch richtig.

Auch bevor ich das Upgrade-Script startete, waren die Umlaute noch in Ordnung.
Das entfernen von define('DB_CHARSET',      'utf8_unicode_ci'); aus der config.php brachte auch keine Änderung.

Es muss etwas mit der Datenbank-Verbindung sein.

jean

Mitglied

Re: Migration und Umlaute...

(versuch mal 'ALTER DATABASE Datenbankname DEFAULT CHARACTER SET  utf8 COLLATE utf8_general_ci' in phpadmin in einer Tabelle, ob es besser wird ... oder besser gleich utf8mb4)

florian

Administrator

Re: Migration und Umlaute...

@Chio
Nur mal interessehalber, wenn Du versuchsweise auf das Produkt unserer geschätzten Mitbewerber updatest, tritt das Umlautproblem dann auch auf?

---

Code allein macht nicht glücklich. Jetzt spenden!

grindbatzn

Gast

Re: Migration und Umlaute...

@Chio
Nur mal interessehalber, wenn Du versuchsweise auf das Produkt unserer geschätzten Mitbewerber updatest, tritt das Umlautproblem dann auch auf?

Naja: Ich hab auch versucht, auf WebsiteBaker upzugraden.

Menschen mit besonderem Gedächtnis für grausliche Sachen (also ohne Verdrängungsmechanismus) kennen das noch: Bevor man von Version 2.8.1 auf 2.8.3 upgradet, muss man auf 2.8.2 upgraden. Und dazwischen noch diverse Service-Packs. Das erfährt man aber erst, wenn man den ganzen Plunder hochgeladen hat. Und weils so schön ist, gibt es das ganze Zeugs nicht mehr so zum Download - zumindest nicht dort, wo man es suchen würde.

DIe verkürzte Version: Ich habs entnervt aufgegeben, alles wieder gelöscht und von vorne mit WBCE begonnen. Bis auf die Umlaut-Sache hat das auch super funktioniert.

Der Status mittlerweile:
Ich mache auf dieser Site keine Datenbank-Experimente mehr; da kann mir zuviel kaputt gehen.

Ich habe die DB-Felder, die wirklich betroffen waren, umbenannt, (also topics:title zu  topics:title_orig) und title neu angelegt.
In der view.list.php dann:

if ($title == '') {
$title = utf8_encode($topic['title_orig']);
$theq = "UPDATE ".TABLE_PREFIX."mod_".$tablename." SET title = '$title', short_description = '$short_description' WHERE topic_id = '$t_id'";
$database->query($theq);
}

Ich hab also jetzt die 2 Felder mal so und mal so.

In phpMyAdmin wird title_orig richtig angezeigt, title hingegen falsch.
In WBCE ist es genau umgekehrt.
Das erfreut mich nicht.

Beitrag geändert von grindbatzn (11.07.2018 19:15:08)

colinax

Developer

Re: Migration und Umlaute...

@Chio
Welchen Browser verwendest Du bzw. tritt das Verhalten nur in einem Browser auf?

Hab so das Gefühl das dieses Problem mit diesem hier zusammenhängt (selbe Ursache)

grindbatzn

Gast

Re: Migration und Umlaute...

phpMyAdmin sagt mir:
Zeichensatz/Kollation der MySQL-Verbindung: UTF8mb4_unicode_ci
Die Kollation aller Tabellen ist utf8_unicode_ci
Typ ist durchgehend: MyISAM

Im angehängten Bild ist auch die Darstellung der Umlaute zu sehen (*_orig = wie importiert)

grindmobil

Gast

Re: Migration und Umlaute...

Ich hab Chrome und ff verwendet, kein Unterschied.

colinax

Developer

Re: Migration und Umlaute...

So, ich hab mal in meiner Lokalen TE rumgetestet.

So wie es aussieht wird bei den Comments eine Kollation verlangt die es in den aktuellen DB Versionen nicht mehr gibt.

Genauer gesagt möchten die Comments die Kollation 8859-1 haben, bekommst aber nur Windows-1252 (oder anders herum) dass Problem dass Du hast ist folgendes:

Manche Applikationen vermischen die Definition von ISO 8859-1 und Windows-1252. Diese Codierungen unterscheiden sich jedoch im Bereich 8016 bis 9F16, der in ISO 8859-1 nur Steuerzeichen enthält. Da diese beispielsweise in HTML keine Bedeutung haben, werden oft die druckbaren Zeichen aus Windows-1252 verwendet. Aus diesem Grund schreibt der neue HTML5-Standard vor, dass als ISO 8859-1 markierte Texte als Windows-1252 zu interpretieren sind.[2] Im Oktober 2017 verwenden 4,6 % aller Websites ISO 8859-1 bei fallender Tendenz. Latin-1 ist damit nach UTF-8 (89,9 %) die zweithäufigste Kodierung von Websites. Windows-1252 wird von 0,8 % der Websites verwendet.[3][4] Die Unterschiede zwischen all diesen Kodierungen sowie generell mangelnde Konsequenz bei der Unterstützung verschiedener Zeichensätze sind ein häufiges Interoperabilitätsproblem.

Edit: Da wird nur manuelle Behebung über die DB helfen.

Beitrag geändert von colinax (11.07.2018 22:56:53)

grindbatzn

Gast

Re: Migration und Umlaute...

Da gehts aber im wesentlichen nicht um ÖÄÜß, sondern ums €-Zeichen und wenige andere.
Sonst wäre der Unterschied ja weit offensichtlicher und es würde nicht zu "Verwechslungen" kommen.

digitalbricks

Mitglied

Re: Migration und Umlaute...

Hallo in die Runde,

ich hatte heute das gleiche Problem: Habe eine alte WB-Site (genau genommen eine LEPTON 1.x-Site) auf WBCE "gecrossgraded" – lokal war alles prima, in der Datenbank auf dem Live-Server sah auch alles gut aus aber im Frontend gab es Zeichensalat. Nach nicht unerheblichen Rechercheaufwand bezüglich der Fehlerursache, brachte letztlich folgender Eintrag in der config.php Besserung:

[== PHP ==]
define('DB_CHARSET','utf8');

Das bewirkt, dass in der class.database.php nach dem Verbindungsaufbau zur Datenbank via set_charset() in meinem Fall 'utf8' gesetzt wird und somit die korrekten Zeichen aus der Datenbank auch korrekt in PHP ankommen.

Vielleicht hilt das dem Einem oder Anderem.

bodo

Mitglied

Re: Migration und Umlaute...

Hammer, hatte das gleiche Problem beim importieren der Datenbank nach update. Ich hätte einen Riesenzeitaufwand gebraucht, um alles per Hand in Ordnung zu bringen. Danke für diese "Zeile".

Bodo

byteworker

Mitglied

Re: Migration und Umlaute...

Kurze Frage, bei mir taucht das Problem nach Update von WB 3.8.1 auf WBCE 1.4.3 auch auf.

Aus:

Reise nach Temeswar/Temeșvar, Schässburg/Sighișoara

Wird:

Reise nach Temeswar/Teme?var, Schässburg/Sighi?oara

Ich habe im Backend auf utf-8 umgestellt, in der Config.php die Änderung oben vorgenommen. Die Zeichen kann ich als Codeersetzung  Kleinbuchstabe ș: = ș eingeben, werden allerdings beim ersten Aufruf wieder falsch dargestellt.

---

= Templates für WBCE

colinax

Developer

Re: Migration und Umlaute...

@byteworker

hast du die DB auch schon angepasst?

byteworker

Mitglied

Re: Migration und Umlaute...

Uff, nein. Ich schau gleich mal nach welche Tabelle das sein muss, oder die ganze Datenbank?

---

= Templates für WBCE

colinax

Developer

Re: Migration und Umlaute...

einzeln geht auch aber schneller ist die Ganze DB auf auf utf8_unicode_ci oder utf8mb4_unicode_ci umzustellen danach sollte es reichen die Texte die falsch angezeigt werden im BE aufzurufen und erneut speichern.

byteworker

Mitglied

Re: Migration und Umlaute...

Prima, danke. Hat geklappt 

---

= Templates für WBCE