|
Da is man mal 3 Tage nicht da und ihr spammt wieder alles voll 
| quote: | Originally posted by dj_macgyver
tach... was für'n tach...
ich chill hier zu irgend'nem 70min-set ohne namen (nur zahlenkombinationen - lol), das ich grad ausgegraben hab - irgendwie totaler sonne-relax-sound... hier is keine sonne... was soll's, relaxen kann ich ja trotzdem :chill:
@domi: does that remind you of something?  |
Irgendwie grad nur dunkel - hilf mir auf die Sprünge...
| quote: | Originally posted by dj_macgyver
hmmmm also problem is jetzt wieder da, wie zuvor: wenn ich auf preview klicke wechselt der mozilla auf utf-8.
leider kann ich das problem momentan nicht weiter analysieren, d.h. ich kann auch nicht genau sagen ob das jetzt schuld des servers oder schuld des browsers ist. mozilla gibt mir die entsprechenden infos nicht raus.
das encoding wird auf der ebene des http-protokolls festgelegt, ist also nicht im html-code zu finden. und genau da komm ich momentan nicht hin (bräucht ich wohl 'nen packet sniffer oder so...). mit php ist aber durchaus eine beeinflussung der header möglich, also denkbar wäre sowohl ein server- als auch clientseitiges problem... |
Also meine Erfahrung sagt mir, dass Browser PHP Header noch öfter ignorieren als HTML Header
| quote: | Originally posted by dj_macgyver
so. ich hab mir jetzt wirklich die mühe gemacht und die geschichte mit den umlauten aufs letzte byte zerlegt. was ist dabei rausgekommen? mehrere punkte.
a) tranceaddict.com verwendet die gzip-kompression hier auf dem webserver, um die leitungsbelastung zu verringern. dagegen ist nichts einzuwenden, aber es spielt irgendwie in dem problem eine rolle. zumindest konnte ich unser umlaut-problem mit deaktivierter kompression nicht nachvollziehen...
b) tranceaddict verwendet keine charset-headers, um den browser explizit auf ein charset-encoding einzustellen.
c) mozilla denkt aus irgendwelchen nicht nachvollziehbaren gründen in der konstellation aus a) und b) dass die daten, die er vom server erhält, im utf-8-charset vorliegen. da dies nicht der fall ist, kommt es auf manchen seiten zu darstellungsfehlern. besonders fatal ist es, wenn der fehler auf den seiten, in denen man seine neuen posts verfasst auftritt, da in dieser situation dann auch noch fehlerhafte daten an den server gesendet und dort in der datenbank gespeichert werden.
so... das bringt mich nun vorerst mal zu der schlussfolgerung, dass es grundsätzlich ein client-seitiges problem ist, da ich in der kommunikation server-client keine entsprechenden hinweise auf code finde, der ein umstellen des clients auf utf-8 bewirken sollte.
dennoch könnte man versuchen, dem serverseitig entgegenzuwirken, in dem man die unter b) erwähnten fehlenden charset-header aktiviert und entsprechend konfiguriert. ich kann allerdings nicht garantieren, dass es einen entsprechenden erfolg bringen würde... |
Also ich hatte letztens das Problem, dass er bei mir alles richtig gespeichert hat, bis auf das € Zeichen, was ich dann durch ein blödes aber funktionelles Workaround lösen konnte (text in html entities umwandeln, euro-zeichen kombination ersetzen lassen, html entities wieder decoden). Da TA aber mehrsprachig ist, wäre das ein irrer Aufwand.
Ich vermute mal, dass Swamper die Daten in der DB in UTF-8 abspeichert und daher auch irgendwo die Probleme kommen. Möglich wäre auch, dass bei der Preview irgendwo ein uf8_encode, aber dann kein utf8_decode mehr stattfindet. Oder es findet bei der Preview ein url_encode statt, denn der hat mir auch schon mal die Umlaute zerschossen...
btw. Moin 
___________________
rate the sound, not the artist.
|
Sag doch einer PHP Datei mal mit header(), dass sie nicht gecacht werden soll - meinste den Browser interessiert das? 
