[CON-1801] Sonderzeichen in Fremdsprachen zerschossen

[homtata]

Hallo Gemeinde,

ich hatte eine funktionierende Version 4.9.2 mit 6 Sprachen, darunter türkisch.
Alle Sprachen sind im Mandanten auf utf-8 eingestellt.
Bis 4.9.2 lief es korrekt.

Nach dem Update sind nun ALLE Texte (Container), Kategorienamen u.ä. in türkisch zerschossen. Gewisse Sonderzeichen sind bis auf die Datenbank runter in Fragezeichen umgewandelt, während sie in 4.9.2. noch korrekt codiert in der Tabelle zu sehen sind.

Bsp: aus "Åžehir rehberi" in der DB wurde "?ehir rehberi", aus "Rezervasyon iÅŸleme" wurde "Rezervasyon i?leme". Die Sprache ist jetzt praktisch unbenutzbar.

Der Fehler schlägt sogar bis in diverse JS-Kalender durch, wo bis 4.9.2 z.B. "März" (auch mit "ä" in der js-Datei) noch korrekt dargestellt wurde, und jetzt nur so eine komische Raute statt des "ä" angezeigt wird.

Was um Gottes willen wurde hier umgestellt, dass die Sonderzeichen so weggepustet werden??

--- Ergänzung:
Es handelt sich hier mal wieder um einen "Fehler" in der falschen Kollation mancher Datenbankfelder. Bei dieser Installation, die aus 4.8 kontinuierlich aktualisiert wurde, ist den meinsten Feldern noch mit latin_german zugewiesen. Stellt man solche "value"-Felder wie z.B. in con_cat_lang oder con_properties um auf utf-8, dann klappt das mit dem Speichern und Auslesen von exotischen Sonderzeichen wie z.B. im Türkischen wieder.
Ich verstehe nur nicht, wie das bis 4.9.2 funktionieren konnte und JETZT plötzlich auf der Datenbankebene völlig zerschiesst. Nicht nur, dass sich keine neuen Inhalte mehr korrekt speichern ließen - auch die alten wurden einfach "umgestellt".

Deshalb hier nochmal die Frage: eine Update-Version stösst bei exotischen Sprachen sofort an ihre Grenzen, weil die Datenbankfelder-Kollationen einfach nicht passen. Selbst bei einer 4.9-Installation werden bei mir aber keine utf-8-Kollationen gesetzt, sondern latin-german. Das ist doch aber - ehrlich gesagt - völliger Humbug!
Oder es müssen Warnungen ausgegeben werden oder was auch immer - aber so ist das doch Käse. Da kann ich den MANDANTEN auf utf-8 umstellen und hab dann auf der Datenbankebene das Nachsehen (!).

[Faar]

Sowas ist mir mal bei einem native PHP-Projekt passiert, da war die Ursache in doppelt utf-8 codiertem Text (in der Datenbank war bereits ein UTF8-Zeichen in Klartext aber das Frontend ging davon aus, es mit UTF8-Code Zeichen zu tun haben und diese nochmal in Klartext umwandeln zu müssen) und einmal in nicht umgewandeltem PHP-Dokument, hab vergessen/übersehen das ANSI Dokument in ein utf8 Dokument beim Speichern umzuwandeln).

[homtata]

Hallo Faar,

in diesem Fall ist das Problem aber m.E., dass wir diverse Artikel im türkischen nachweislich gar nicht mehr angepackt haben seit dem Update. Ich will rauskriegen, ob es sein kann, dass das Update von 4.9.2 auf 4.9.3 tatsächlich eigenmächtig die Sonderzeichen aus der Datenbank geschossen hat... Denn in der 4.9.2 sehe ich die Daten korrekt im DB-Dump. Das System MUSS sie also mal richtig abgespeichert haben, während es mit den unveränderten Einstellungen a) nicht mehr abzuspeichern ging und b) den Bestand wie gesagt geändert hat. Hm.

[Faar]

Naja, doppelt gemoppelt würde hier auch passen, denn es kann ja sein, dass sie die Datenbank-Kommunikation bezüglich utf8 in 4.9.3 leicht geändert haben und vielleicht auch die Kollation der Tabellen umgewandelt haben.
Die Probleme gibt es dann bei Altbestand, also angenommen du hast ein utf8 Zeichen in der DB stehen: ö
Dann ist es ok, wenn die Kollation latin-irgendwas ist, weil die Kommunikation zwischen Datenbank und Server sagt, dass dieses ö in utf8 darzustellen ist. Im Frontend wird dann daraus ein ö.
Wenn aber ein bereits umgewandeltes ö (ö) noch einmal als utf8 umgewandelt wird, kommt kein ö dabei raus, sondern dieses Fragezeichen (Ersatzzeichen), weil es ein solches Zeichen nicht gibt.
Irgendwas in dieser Richtung könnte es sein.
Doppelt gemoppelt, glaube ich

[dominik.ziegler]

Könnten wir ggf. zur PRüfung den Dump der Datenbank vor dem Update bekommen, damit wir das bei uns mal reproduzieren zu versuchen können?

[homtata]

Hallo Dominik,

wie der Teufel es so will, gibts ausgerechnet hier kein Backup direkt vor dem Update. Ich war mir SOOOO sicher, nachdem ich schon mehrere Webseiten aktualisiert hatte, dass ich nicht im Traum daran dachte, dass es jetzt ein Problem geben könnte - und voilà. Werden denn beim Upgrade irgendwelche Tabellenfelder-Kollationen neu gesetzt oder umgeschrieben? Alle Werte in der 4.9.2 standen auf utf8. Alle. In den configs, in den Mandantensprachen... Ich bin mir nur nicht mehr sicher, welche Datenbankfelderkollationen ich bereits im Vorfeld händisch geändert hatte auf utf8 und welche nicht.

Nachtrag:
Ich habe in einem Dump von Dezember (vor Einfügen von türkisch, aber schon eine 4.9.2) gesehen, dass ich z.B. in con_art_lang die Spalte "title" auf utf8 umgestellt hatte. Im ersten Dump NACH dem Update auf 4.9.3 stand diese definitiv wieder auf "latin_german". Ich lasse dir den Dezember-Dump per PN zukommen.

LG

[rethus]

Ja, dass die DB entgegen aller wünsche und Empfehlungen immer noch nicht auf utf-8 (bei installation und upgrade) umgestellt wurde versteht wohl keiner so recht. Hatte mich auch kürzlich damit rumgeschlagen.
Du kannst in der DB auf Datenbank, Tabelle und Felder die collation setzen. Zudem in der jeweiligen Sprache in Contenido.
Im Grunde müsste es dann gehen. (Nicht vergessen den Cache zu leeren).
Wenn die Daten in der DB richtig dargestellt werden direkt mal ein Backup machen ehe du weiterbastelst... dann ist auch noch nicht alles verloren

[frederic.schneider_4fb]

Für alle als Rückmeldung:
Wir konnten die Probleme von homtata auf Anhieb reproduzieren. Und wie rethus auch korrekt darlegt, hilft die Umstellung von Collations der Gesamttabellen (homtata hatte einzelne Spalten auf utf8 umgestellt und durch die Upgrades ist es wieder verschwunden -> Sonderzeichenprobleme in türk. Sprache, da die Gesamttabelle auf latin stand). Als Standardlösung werden wir in Zukunft (Versionsnummer noch offen) mit Bordmitteln von CONTENIDO die individuelle Collation-Definition von Tabellen ermöglichen.

[chris8408]

Hallo,

ich habe bei der oben genannten Contenido-Version den Fehler, dass zwar die Umlaute in den Artikeln korrekt dargestellt werden, jedoch in der Artikel-Liste und in der Kategorien-Liste die Artikeltitel / Kategorientitel mit Umlauten oder Sonderzeichen wie "&" nicht dargestellt werden. In der Breadcrumbleiste ist alles OK. Beim Editieren der Kategorienamen auch.

Dieses Phänomen habe ich bei 2 Contenido-Installation (jeweils Updates).

Hat hier jemand eine Idee oder hängt das mit dem oben genannten Problem evtl. zusammen?

Gruß, Christian

[mischa.holz]

Ich glaube nicht, dass es mit dem Problem hier zusammenhängt.

Gibt es irgendwelche Fehlermeldungen in den logs? Sieht so aus als würde irgendeine Funktion nichts zurückgeben obwohl sie es nicht soll...

[malsdgtac]

Hallo,

wir haben leider auch das Problem mit den Zeichen, in unserem Fall sind es techische, und mein Test die Kollation für das Feld "value" in der Tabelle "smac_content" auf "utf8" zu setzen bringt das erwartete Ergebnis: dann funktionieren diese Zeichen.

Jetzt aber meine Frage dazu: muss ich jetzt die Kollation für alle Tablellen und alle Textfelder von Hand ändern? Oder gibt es eine Möglichkeit alle auf einmal zu ändern bzw. muss ich es nur für bestimmte Tabellen ändern?

Vielen lieben Dank für eure Antwort.

[frederic.schneider_4fb]

Spannende Frage. Per Google habe ich auf Anhieb das gefunden:
http://serversupportforum.de/forum/69306-post5.html
Müsste man ggfls. aber noch um eine Zeichenkonvertierung ergänzen.

Es stellt sich jedoch die Frage, ob man das wirklich will und ob das nicht negative Auswirkungen hat. Ich würde daher empfehlen, die vollständige Umstellung erst einmal lokal mit einem Sql-Dump auszuprobieren. Ab der neuen Version CONTENIDO 4.9.4 ist die Kollation-Definition nun Bestandteil der Installationsroutine.

[malsdgtac]

Vielen Dank für die Info

[malsdgtac]

Für meine bereits installierte Version der 4.9.3 habe ich jetzt einfach einen Export der Datenbank gemacht, dann alles von latin1 auf utf8 in File geändert und wieder importiert - schaut aus, dass es klappt.