Ich halte hier und jetzt mal fest, dass wir beide wohl nicht da core sind.
@Don83:
Ich meinte damit "öffentlich" posten. Ich mag es gar nicht als "privater Supporter" behandelt zu werden.
Dennoch habe ich mir das ganze aus Neugierde angesehen. Und es scheint, dass irgendwas bei Dir kein UTF8 kann. Denn trotz der gesetzten Header kommt eine ISO-8859-1 kodierte Datei an. Was auch erklärt warum alles andere nur noch mehr Sonderzeichen produziert.
Sieh es positiv: an MySQL liegt es schon mal nicht.
Naja der Grund wieso ich den link nicht öffentlich poste, ist, dass der server nicht mir gehört und nur zu testzwecken angedacht ist. Will deshalb nicht öffentlich und ungefragt die Adresse posten.
Will dich natürlich nicht als personal helper misbrauchen, aber nachdem du ja um den link gebeten hattest habe ich Ihn dir nunmal als pm zugeschickt.
So, dann mal zum Problem:
Und es scheint, dass irgendwas bei Dir kein UTF8 kann. Denn trotz der gesetzten Header kommt eine ISO-8859-1 kodierte Datei an. Was auch erklärt warum alles andere nur noch mehr Sonderzeichen produziert..
Also schonmal vielen Dank, dass du reingeschaut hast. Ich versteh nur einfach nicht wo der Fehler noch liegen könnte. Eine Idee wäre, dass irgendwie die charsets des Systems da Probleme verursachen. Kann das sein?
Ich habe letztens in der my.cnf und debian.cnf geschaut.
Dort waren gar keine Informationen zum charset. Eigentlich solltne dort welche stehen.
Wenn ich unter Plesk eine neue MySql Datenbank anlege, ist die Kollation auf "latin1_swedish_ci" eingestellt. Kann mir jemand sagen, ob und wie ich hier einen anderen Defaut einstellen kann? Gruß flyingoffice
serversupportforum.de
Ich weiß jetzt nicht ob das sonderlich intelligent wäre, aber macht es Sinn, die charset Information nachzutragen? Wie gesagt, in der jetzigen my.cnf fehlt die Im Thread angesprochene Zeile einfach.
Ansonsten habe ich keine Ahnung mehr was und woran es liegen könnte : /.
Offenbar gibt es hier ein Missverständnis. Natürlich sind die empfangenen Header bei beiden Programmen gleich. Aber der Firefox muss den Header irgendwann parsen und wird dann vermutlich bei der semantischen Analyse intern eine Variable für die Zeichenkodierung der Seite anlegen und eben diese Variable wird mit der Option überschrieben. Bei wget gibt es natürlich keine solche Option, denn wget kann die Angabe im Header einfach ignorieren, da es die HTML-Seite gar nicht anzuzeigen versucht und dementsprechend auch keine Zeichen zu interpretieren braucht.
Wie ich bereits sagte: Am MySQL liegt es aktuell erstmal nicht.
Und um ein evtl. Missverständnis auszuschließen:
Nur weil Du einen Charset setzt findet keine Konvertierung statt!
Du musst also erstmal sehen, dass Du auch einen UTF8-Output lieferst.
Z.B. sicherstellen, dass die PHP-Datei UTF8 ist. (siehe auch "man iconv")
Oder ein "utf8_encode('äöüß')", oder oder oder...
Das möchte ich nochmal ausdrücklich bestätigen!!
Ja!
Vorschlag:
Erstmal machst du dich über Zeichensätze kundig.
Beschaffst dir einen Hexeditor (z.B. pspad hat einen dabei)
Dann malst du dir ein Datenflußdiagramm auf.
An jedem Punkt des Diagramms überprüfst du den Zustand/Codierung der Daten mit dem Hexeditor.
Und automatisch führt es dich zur fehlerhaften Stelle.
