Umlautproblem

[vendy]

Hallo,

ich habe eine Webseite die auf zwei Scripten basiert. Ich hatte sie damals beide nebeneinander installiert und alles funktionierte wunderbar. Aufgrund eines Serverumzugs musste ich die Datenbank exportieren und auf einen neuen Server transferieren.

Ich habe jetzt folgendes Problem:
- Script A hat eine UTF-8 Codierung (HTML CHARSET)
- Zeigt die Umlaute im Frontend richtig an
- In der Datenbank sind die Umlaute falsch! (für)

- Script B hat eine iso-8859-1 Codierung (HTML CHARSET)
- Zeigt die Umlaute in Frontend falsch an
- In der Datenbank sind die Umlaute allerdings korrekt dargestellt!

Die komplette Datenbank der Scripte A und B habe ich zusammen in UTF-8 Codierung mit einem Webbasierenden SQLdump Script
exportiert, da die Datenbank um die 90MB groß ist.

Auf die alte Datenbank kann ich nicht mehr zugreifen, da der alte Server schon offline ist, sonst hätte ich jeweils die für das Script relevanten Tabellen in einer eigenen Codierung exportiert.

Wie kann ich das jetzt wieder grade biegen, hat da jemand eine Idee?

Grpße,
vendy

 

[Jürgen Auer]

Das

QUOTE (vendy @ Sa 2.02.2008, 12:29)- Script A hat eine UTF-8 Codierung (HTML CHARSET)
- Zeigt die Umlaute im Frontend richtig an
- In der Datenbank sind die Umlaute falsch! (für)


ist alles konsistent. Nur das Tool, mit dem Du die Daten in der Datenbank ansiehst, berücksichtigt UTF-8 nicht (scheint also ein etwas dummes Tool zu sein

).

Also stelle diese Variante


QUOTE (vendy @ Sa 2.02.2008, 12:29)- Script B hat eine iso-8859-1 Codierung (HTML CHARSET)
- Zeigt die Umlaute in Frontend falsch an
- Im Backend sind die Umlaute allerdings korrekt dargestellt!


auch auf UTF-8 um. Bei mySql gibt es entweder eine interne Funktion (ich nutze das nicht, keine Ahnung) oder Du mußt die Zeilen herausholen, innerhalb von PHP die 1-Byte-Zeichenfolgen in UTF-8-Zeichenfolgen umwandeln und das zeilenweise zurückschreiben.

 

[vendy]

Danke für deine Antwort.

Ich habe nun das letzte Script B, welches mit dem CHARSET iso-8859-1 codiert war, auf UTF-8 geändert und als UTF-8 Dokument mit dem Windowseditor gespeichert.

Die Umlaute aus dem Template werden nun korrekt dargestellt. Die Datensätze die mittels MySQL hineingeladen werden sind jedoch immer noch falsch: "f?r" "ver?ffentlichen" etc.

 

[Maik]

Dein Script womit du die Datenbank anschaust, wird wahrscheinlich als ISO ausgeliefert. Daher ist dein Script A und deren Datenbank korrekt.

Bei deinem Script B blick ich nicht durch... Wenn die Daten als UTF importiert wären (wovon du ausgehst), würde es in deinem Datenbankscript genauso aussehen wie beim Fall A.

Ansonsten würde uns sicherlich nur helfen, wenn wir deine Frontend-Scripte live zusehen bekämen, das würde die Fehleranalyse vereinfachen.

 

[Jürgen Auer]

Das
QUOTE (vendy @ Sa 2.02.2008, 15:33)Ich habe nun das letzte Script B, welches mit dem CHARSET iso-8859-1 codiert war, auf UTF-8 geändert und als UTF-8 Dokument mit dem Windowseditor gespeichert.


ist auch bloß die Hälfte der Arbeit, da fehlt noch die Konvertierung aller Datensätze in der Datenbank. Da das fehlt, ist 'ü' als 1-Byte gespeichert und wird beim Ausgeben in einer UTF-8-Umgebung als 'f?r' angezeigt.

Sprich: Du bist erst fertig, wenn da auch in der Datenbank 'für' drinsteht. Roh betrachtet sieht das zwar falsch aus, als UTF-8 wird es aber von einer UTF-8 - erwartenden Umgebung ausgelesen und - weil es ein korrekter UTF-8-Datenstrom ist - auch korrekt dargestellt.

 

[vendy]

Die Datenbank guck ich mittels PHPMyAdmin an.

Geht um folgende Seite: http://www.kinder-archiv.de
Dort findet ihr ein Webkatalogscript, dort funktionieren die Umlaute im Frontend, in der Datenbank sind sie falsch.

In einem Unterverzeichnis liegt das andere Script, eine Topliste: http://www.kinder-archiv.de/topliste/
Hier funktionieren die Umlaute nicht, obwohl sie in der Datenbank korrekt sind. Hier war anfangs CHARSET iso-8859-1 codiert, wie oben erwähnt habe ich es jetzt auf UTF-8 geändert.

 

[vendy]

QUOTE (jAuer @ Sa 2.02.2008, 22:12) Das

QUOTE (vendy @ Sa 2.02.2008, 15:33)Ich habe nun das letzte Script B, welches mit dem CHARSET iso-8859-1 codiert war, auf UTF-8 geändert und als UTF-8 Dokument mit dem Windowseditor gespeichert.


ist auch bloß die Hälfte der Arbeit, da fehlt noch die Konvertierung aller Datensätze in der Datenbank. Da das fehlt, ist 'ü' als 1-Byte gespeichert und wird beim Ausgeben in einer UTF-8-Umgebung als 'f?r' angezeigt.

Sprich: Du bist erst fertig, wenn da auch in der Datenbank 'für' drinsteht. Roh betrachtet sieht das zwar falsch aus, als UTF-8 wird es aber von einer UTF-8 - erwartenden Umgebung ausgelesen und - weil es ein korrekter UTF-8-Datenstrom ist - auch korrekt dargestellt.

Wie kann ich das automatisch umsetzen? Die Datenbank ist viel zu groß um das per Hand zu machen. Weiterhin stellt sich dann die Frage inwiefern neue Einträge in der Topliste auch als 'für' gespeichert werden und nicht wie bisher als 'für'?

 

[Jürgen Auer]

QUOTE (vendy @ Sa 2.02.2008, 22:18)Wie kann ich das automatisch umsetzen? Die Datenbank ist viel zu groß um das per Hand zu machen.


Keine Ahnung, ich verwende ja mySql/PHP nicht.

In server-daten hatte ich kürzlich ein analoges Problem, da kamen Mails von PHP-Scripts als 8-Bit-Datenströme an, die automatisch in Tabellen eingetragen werden sollten. Die Lösung bestand schließlich darin, den Datenstrom über eine Codepage-Encoding einzulesen (damit waren die Umlaute korrekt - liest man das als Ascii ein, dann fehlen alle achten Bits, man sieht bloß ?) und das als String weiterzuverarbeiten. Ab dann muß man sich in .NET nicht mehr um dieses Problem kümmern.

Allerdings kommt mir beim Schreiben: Es gibt doch irgendein Tool um mySql herum, mit dem man eine Tabelle als Sql-Befehle exportieren kann. Nachher sieht das so aus:


CODE Insert Into Tabelle(id, Spalte) Values(5, 'Müller')


für jede Zeile in der Tabelle so eine Scriptzeile. Wenn man das exportiert, dann müßte das Ergebnis zunächst ISO-8859-1 sein. Wenn man jetzt diese Datei per Notepad öffnet, als UTF-8 speichert und dann ausführt, dann könnte das korrekt werden.



QUOTE (vendy @ Sa 2.02.2008, 22:18)Weiterhin stellt sich dann die Frage inwiefern neue Einträge in der Topliste auch als 'für' gespeichert werden und nicht wie bisher als 'für'?


Das andere Script macht das ja auch korrekt. Das dürfte eigentlich kein Problem sein.

PS: Internet ist doch lustig - grade in meinem Protokoll entdeckt: Eine koreanische Seite über hebräische Schriftzeichen verlinkt auf die Hebrew - Seite meiner Unicode-Datenbank. Da sieht man, wofür man Unicode braucht.

 

[vendy]

So, hat letztendlich doch geklappt.
Das Problem lag im Frontend ja nur bei Script B:
CODE - Script B hat eine iso-8859-1 Codierung (HTML CHARSET)
- Zeigt die Umlaute in Frontend falsch an
- In der Datenbank sind die Umlaute allerdings korrekt dargestellt!


Ich habe die Datenbank erneut exportiert, mit Textpad als UTF8-8 gespeichert und erneut als UTF-8 per phpMyAdmin importiert. -> Nun wurden die Umlaute aus der Datenbank im Frontend wieder korrekt dargestellt.

Dann habe ich aus der iso-8859-1 Codierung eine UTF-8 Codierung gemacht und die Languagefiles des Scripts auch als UTF-8 gepspeichert und neu hochgeladen. -> Nun klappt alles.