|
Was macht Ihr gerade (Part 6) (pg. 467)
|
View this Thread in Original format
| Nik Novo |
Da is man mal 3 Tage nicht da und ihr spammt wieder alles voll :wtf: :wtf: :wtf:
| 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? :toothless |
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 :toothless
| 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 :happy2: |
|
|
| JeSsY0182 |
Morgen zusammen.
Ich fahr jetzt mal ne Runde bei Ikea shoppen :D |
|
|
| schnegggge |
Morgen
*kaffeeschlürf*:) |
|
|
| XeCUTionER |
| so, eben gespült, jetzt duschen, dann backen und dann in die stadt! |
|
|
| GLD |
| kann mich nicht aufraffen meinen praktikumsbericht weiterzuschreiben. naja, gleich ist eh mittach!:) |
|
|
| Cosmique |
hab grade erfahren, dass ich Donnerstag bis Sonntag auf der eBay Live in Duesseldorf bin.
Gibts irgendwelche netten 'places to be' in Duesseldorf?
Clubs, Bars ..... ? |
|
|
| dj_macgyver |
| quote: | Originally posted by Nik Novo
Irgendwie grad nur dunkel - hilf mir auf die Sprünge... |
chill-smiley? liegestuhl und so? :toothless
| quote: | Originally posted by Nik Novo
Also meine Erfahrung sagt mir, dass Browser PHP Header noch öfter ignorieren als HTML Header :toothless |
also... nur so zur info: die funktion, die ich meine (header()) erzeugt einen http-header. dementsprechend gibt's da keinen unterschied.
| quote: | Originally posted by Nik Novo
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...
|
htmlentities() ist ja eigentlich der saubere weg. damit würden die umlaute in ihre entsprechenden &xuml;-nomenklatur umgewandelt und somit wäre die darstellung zeichensatzunabhängig.
ich glaube, es wurde überhaupt keinen wert darauf gelegt, in welchem zeichensatz die daten in der db gespeichert werden, und dementsprechend sind die daten in der db - je nach regionalität der poster - in anderen zeichensätzen gespeichert. darum hätte jetzt (nachträglich) ein explizites setzen des charsets wohl schlimmere auswirkungen als ein entsprechendes fehlen der angabe...
und ein utf8_encode findet da keins statt. der browser *denkt* die daten wären in utf8, was aber nicht stimmt. wenn man im browser den zeichensatz manuell wieder auf iso-8859-1 umstellt stimmt die darstellung ja wieder. aber diese einstellung wird eben aus irgendwelchen gründen wieder verworfen und durch utf-8 ersetzt, trotz deaktiviertem autodetect. |
|
|
| Nik Novo |
| quote: | Originally posted by Cosmique
hab grade erfahren, dass ich Donnerstag bis Sonntag auf der eBay Live in Duesseldorf bin.
Gibts irgendwelche netten 'places to be' in Duesseldorf?
Clubs, Bars ..... ? |
Hey cool! Ich bin dieses WE auch in Krefeld und da wollten wir an einem Tag/Abend auch ohnehin nach Düsseldorf rein :D |
|
|
| Kasperhauser |
So, Mittag nun.
heute gibt es:
Griechischer Hirtenbraten, gefüllt mit Oliven und Schafskäse, dazu Bratkartoffeln, Tzatziki und Krautsalat :eyes: |
|
|
| Nik Novo |
| quote: | Originally posted by dj_macgyver
chill-smiley? liegestuhl und so? :toothless |
:D
| quote: | | also... nur so zur info: die funktion, die ich meine (header()) erzeugt einen http-header. dementsprechend gibt's da keinen unterschied. |
Ich weiss schon was du meinst ;) Sag doch einer PHP Datei mal mit header(), dass sie nicht gecacht werden soll - meinste den Browser interessiert das? :toothless
| quote: | htmlentities() ist ja eigentlich der saubere weg. damit würden die umlaute in ihre entsprechenden &xuml;-nomenklatur umgewandelt und somit wäre die darstellung zeichensatzunabhängig.
ich glaube, es wurde überhaupt keinen wert darauf gelegt, in welchem zeichensatz die daten in der db gespeichert werden, und dementsprechend sind die daten in der db - je nach regionalität der poster - in anderen zeichensätzen gespeichert. darum hätte jetzt (nachträglich) ein explizites setzen des charsets wohl schlimmere auswirkungen als ein entsprechendes fehlen der angabe...
und ein utf8_encode findet da keins statt. der browser *denkt* die daten wären in utf8, was aber nicht stimmt. wenn man im browser den zeichensatz manuell wieder auf iso-8859-1 umstellt stimmt die darstellung ja wieder. aber diese einstellung wird eben aus irgendwelchen gründen wieder verworfen und durch utf-8 ersetzt, trotz deaktiviertem autodetect. |
Das Problem bei mir mit htmlentities war ja, dass ich in der DB ein VARCHAR Feld mit maximalgröße 255 Zeichen hatte und die Usereingabe ebenfalls 255 Zeichen betragen durfte ;)
Somit hab ich ihn nur bei der Ausgabe
Zum UTF-8: Als ich mein €-Zeichen Problem hatte, war die Seite auch in UTF-8, die Umlaute haben problemlos geklappt nur das Euro-Zeichen nicht - und das sowohl im IE als auch Firefox :conf:
Browser und Kodierungen sind halt immer so ne (spaßige..) Sache :nervous: :nervous: :nervous: :toothless |
|
|
| XeCUTionER |
| quote: | Originally posted by Cosmique
hab grade erfahren, dass ich Donnerstag bis Sonntag auf der eBay Live in Duesseldorf bin.
Gibts irgendwelche netten 'places to be' in Duesseldorf?
Clubs, Bars ..... ? |
harpune!
www.harpune.com |
|
|
|
|
