Hm... ist mit "verstümmelt" nun gemeint, dass in der Datenbank die utf-8 Hiroglyphen stehen oder wirklich verstümmeltes Zeugs?
Dass in der DB utf-8 nicht als Reinschrift vorhanden ist, das ist auch bei Wordpress so. Man kann in der DB die utf-8 Daten bei Wordpress nicht editieren, weil es eben diese Hieroglyphen sind.
Aber verstümmelt sind diese Daten nicht, denn alles ist vorhanden und wird auf der Seite dank des UTF-8 Hinweises als Reinschrift wieder ausgegeben.
Der Zeichensatz in der DB muss also gar nicht auf utf-8 eingestellt sein, weil am Ende die utf-8 Hieroglyphe mit dem richtigen utf-8 Zeichensatz dargestellt wird.
Ich hatte mich in einem nativen Projekt (also ohne CMS von der Stange) mal lange genug damit herum geschlagen und man "sieht" nicht, wann welche Zeichencodierung wirksam ist (das ist eines der größten Schwierigkeiten mit utf-8).
Steht nämlich in der Datenbank alles auf utf-8 und auch die Zeichen sind in utf-8 als Reinschrift in der DB, dann kann man diese z.B. auch nicht mit phpMyAdmin ändern, wenn dieses nicht auch als utf-8 arbeitet, sondern z.B. mit ISO 8859-1.
Dann gibt es echten Datenmischmasch und auf der Seite erscheinen dann z.B. dunkle Rauten mit Fragezeichen drinne.
Nun kannst du dir vorstellen, dass die Suchfunktion im Zweifel nichts finden kann, weil sie nach A (ля) sucht, aber in der Datenbank die utf-8 Hieroglyphen vorhanden sind.
Folglich müsste man dafür sorgen, dass bei der Suche in der DB entweder auch nach den Hieroglyphen gesucht wird oder aber in Reinschrift nach ля.
Bei mir half in meinem Beispiel, dass alle Dokumente auch als utf-8 abgespeichert werden, also besonders die Dateien in denen die utf-8 Zeichen eingegeben werden.
Dabei muss man darauf achten, dass nicht der utf-8 BOM mitgespeichert wird!
In der Folge sind dann die Zeichen die mit str_replace verarbeitet werden, auch utf-8 Zeichen.
Gleiche Erfahrung hat einer gemacht, der in php.net schrieb:
Before spending hours searching your application why it makes UTF-8 encoding into some malformed something with str_replace, make sure you save your PHP file in UTF-8 (NO BOM).
This was at least one of my problems.
Contenido macht das eigentlich auch, dass die eigenen Dateien in UTF-8 umgewandelt werden. Daher findet man dann Plötzlich hier und da die geliebte Raute, besonders im Backend bei den ü = � (dass das immer noch nicht repariert wurde, liebes Contenido Team?
).
Fatal wird es in manchen Modulen, wo z.B. als Trennzeichen drei ßßß stehen (z.B. in der Lightbox Galerie) und die dann als drei ��� dargestellt werden.
So funktioniert der Programmcode dann natürlich nicht mehr.
Aber sobald das Dokument utf-8 ist, hilft es dann, einfach das Zeichen markieren und � wieder als ü zu schreiben und ��� als ßßß, sofern man weiß, was drin stehen sollte.
Ich denke mal, wenn alles andere stimmt, sollte es helfen, die Programm-Datei mit dem str_replace in utf-8 Zeichencode statt ANSI abzuspeichern.
Aber darauf achten, ob irgendwo im Code vielleicht noch Umlaute oder Sonderzeichen stehen, die danach zu � werden könnten.
VG,
Frank
Dort wird auch erwähnt, dass es sich um einen Bug handelt. Meine MySQL-Datenbank und das CMS sind utf8 gestellt. Daran sollte es also nicht liegen.