[geloest] Probleme mit Zeichen-Kodierung

[mm231]

Das ist von der Seite, von der die tschechische Übersetzung kopiert wird ...

Stimmt, vergaß ich zu schreiben 

Wenn du für die DB-Verbindung/Results utf-8 vorgibst, deine Tabellen Latin haben, wie schon gesagt der logische Effekt.

Mit anderen Worten: Ich muss/müsste die Kollation ändern.

[NaN]

Dürfte eigentlich nicht so schwer sein.
Das Problem ist, dass, wenn Du die DB auf UTF-8 umstellst, lediglich die Datenbank umgestellt wird. Jedoch nicht die Tabellen in der Datenbank und auch nicht die Inhalte der Tabellen. Das hat nur Auswirkungen auf alle neu erstellten Tabellen. Du müsstest jeden Eintrag in jeder Tabelle einzeln von Hand ändern.
Das ist etwas aufwendig.
Einfacher wäre es, eine neue Datenbank mit Kollation UTF-8 anzulegen, die alte DB zu exportieren und dann nur die Inhalte der alten Datenbank zu importieren.
Möglicherweise muss man da vorher im exportierten SQL-Script alle Anweisungen, die irgendwas mit Kollation Latin zu tun haben entfernen.
Wenn die Kollation der DB von vornherein auf UTF-8 gesetzt ist, werden alle neuen Tabellen + deren Inhalte ebefalls mit dieser Kollation erstellt.

[cyberman]

@mm231

Ändere mal die Kodierung in den Voreinstellungen des Tiny (ist im Normalfall RAW) und gib dann nochmal das Wort neu ein.

Hast du hier alle Optionen durchprobiert?

[mm231]

Ja, numerische Kodierung funktioniert, dann werden die Zeichen korrekt angezeigt. Es werden dann aber auch z.B. Umlaute entsprechend umgewandelt.
(Achja: Offline getestet, also nicht wundern, wenns online noch anders aussieht )

[cyberman]

Ja, numerische Kodierung funktioniert, dann werden die Zeichen korrekt angezeigt. Es werden dann aber auch z.B. Umlaute entsprechend umgewandelt.

Ähmm, ist das ein Problem?

Hauptsache ist doch, dass es im Frontend richtig angezeigt wird ...

[mm231]

Das war nur nebenbei bemerkt, das ist natürlich kein Problem.

@ all: Danke für die Hilfe.

[Wiedmann]

Es werden dann aber auch z.B. Umlaute entsprechend umgewandelt.

Das war nur nebenbei bemerkt, das ist natürlich kein Problem.

Genau genommen ist das schon ein Problem. Es hat schon seinen Grund, dass man keine Entities in der DB haben will  (z.B. wenn man das Search Modul benutzt.).

[mm231]

OK, anderer Lösungsvorschlag?

[Wiedmann]

anderer Lösungsvorschlag?

Die hast du doch schon?
a) du benutzt kein "set names 'utf-8'" in CMSMS und in MySQL sind alle Tabellen latin1
b) oder du benutzt"set names 'utf-8'" in CMSMS und in MySQL sind alle Tabellen utf-8

[cyberman]

Hab jetzt noch nicht im Source nachgeschaut, aber konnte das Search-Modul mit Entitäten nicht umgehen?

[Wiedmann]

aber konnte das Search-Modul mit Entitäten nicht umgehen?

Das geht Zwangsläufig nicht. Dazu müsste es ja wissen, ob ein bestimmter Kontent mit Entities abgespeichert wurde, oder ohne.

Theoretisch könnte man natürlich im Suchfeld anstatt dem Umlaut selbst das Entitie eintippen. Aber da macht einem CMSMS auch einen Strich durch die Rechnung.

(Aber da man Entities eh nicht in einer DB abspeichert, ist das ja eigentlich hinfällig. Nun ja, utf-8 Daten in latin1 tabellen ablegen, wie CMSMS es defaultmässig macht, macht man natürlich normal auch nicht..)

[NaN]

(Aber da man Entities eh nicht in einer DB abspeichert, ist das ja eigentlich hinfällig. Nun ja, utf-8 Daten in latin1 tabellen ablegen, wie CMSMS es defaultmässig macht, macht man natürlich normal auch nicht..)

Das liegt nicht am CMS.
Wenn man die Datenbank von vornherein mit Kollation UTF-8 anlegt, werden die Daten auch richtig in die DB geschrieben.

[Wiedmann]

Das liegt nicht am CMS.

Was genau liegt nicht am CMS?

Immerhin weis dieses CMS ja, das es UTF-8 Daten in die DB schreibt. Also kann es, wie andere Programme auch, beim Installieren dafür sorgen, dass die Tabellen in utf-8 angelegt werden.

Du solltest nicht den selben Fehler wie andere hier machen, und davon ausgehen, dass wenn etwas augenscheinlich zu funktionieren scheint, dieses auch korrekt ist

Wenn man die Datenbank von vornherein mit Kollation UTF-8 anlegt, werden die Daten auch richtig in die DB geschrieben.

a) nur wenn man auch gleichzeitig das "set names 'utf8'" in "include.php" aktiviert. (Eine Stelle wo natürlich gleich jeder nach so einer Einstellung schaut.)
b) in diesem Fall (Datenbank mit utf8) legt der Installer zudem auch nicht alle vorgesehene Indexe an (und merkt das selber nicht mal).


es also 4 Fälle (im Fälle bei z.B. aktuellen MySQL-Versionen):
1) CMS ohne "set names 'utf8'", DB mit"latin1": CMS kann Daten augenscheinlich korrekt schreiben und lesen, es steht aber "Schrott" in der DB (Indexe, Sortierung und textbasierende Vergeiche arbeiten nicht korrekt)

2) CMS ohne "set names 'utf8'", DB mit "utf8": CMS kann Daten augenscheinlich korrekt schreiben und lesen, es steht aber "Schrott" in der DB (Indexe, Sortierung und textbasierende Vergeiche arbeiten nicht korrekt)

3) CMS mit "set names 'utf8'", DB mit "latin1": CMS kann Daten nicht korrekt schreiben und lesen, es steht wirkllich Schrott in der DB. (allerdings fällt das einem US-ASCERIANER oder Latin1ser nicht unbedingt auf.)

4) CMS mit "set names 'utf8'", DB mit "utf8": CMS kann Daten korrekt schreiben und lesen, (Indexe, Sortierung und textbasierende Vergeiche arbeiten korrekt.

Womit wir wieder bei der Ausgangsfrage sind. Wieso sorgt das CMS nicht von sich aus für Fall 4?

[NaN]

es gibt also 4 Fälle (im Fälle bei z.B. aktuellen MySQL-Versionen):

Aha, damit hättest Du für mich endlich mal die Frage geklärt, warum bei mir generell "Schrott" in der DB steht, es aber zum Glück keine Auswirkung auf das Frontend hat

Womit wir wieder bei der Ausgangsfrage sind. Wieso sorgt das CMS nicht von sich aus für Fall 4?

Warscheinlich, weil die DB nicht vom CMS angelegt wird.
Womit wir womöglich mit "set names 'utf8'" in der include.php standardmäßig bei Fall 3 landen würden.
Denn, wenn man bei der Erstellung der Datenbank nicht auf die Kollation achtet, wird z.B. bei mir eine DB mit Kollation latin1_swedish_ci angelegt. Darauf hat doch das CMS keinen Einfluss. Wenn dann "set names 'utf8'" in der include.php aktiviert ist, landet man bei Fall 3.

Gut, man könnte bei der Installation prüfen, welche Kollation die DB hat und diese vor der Erstellung der Tabellen auf UTF-8 setzen. (Oder zumindest eine Meldung ausgeben, dass Zeichenkodierung von CMS und DB nicht 100% kompatibel sind.)
Nun unterstützt CMSms dank AdoDB Lite allerdings mehrere Datenbanken.
Ich weiß nicht wie diese alle funktionieren und ob man da die Kollation der DB einfach ändern kann/darf.
Möglicherweise hat man darauf bisher einfach verzichtet, um so flexibel wie möglich zu sein.

Datenbanken sind eh nicht so mein Fall.

Du solltest nicht den selben Fehler wie andere hier machen, und davon ausgehen, dass wenn etwas augenscheinlich zu funktionieren scheint, dieses auch korrekt ist

Dann kann ich aber besser schlafen 

[cyberman]

4) CMS mit "set names 'utf8'", DB mit "utf8": CMS kann Daten korrekt schreiben und lesen, (Indexe, Sortierung und textbasierende Vergeiche arbeiten korrekt.

Dann nehm ich das mal als Verbesserungsvorschlag - mal sehen, ob sich das in einer der nächsten Versionen unterbringen lässt ...