dedlfix: Just another »Schei? encoding«-Frage ;) - Social Bookmarks

Beitrag lesen

Hi!

Ich denke, das Problem ist, dass das verlinkte Javascript zuerst zu der Dienstleister-Seite leitet, bevor man einen Bookmark-Dienst auswählen kann; und besagte Seite ist auch ISO-Kodiert.

Die Zeichenkodierung, in der eine Response verfasst ist, muss nicht zwingend die gleiche sein, in der der Server zu verarbeitende Daten erwartet. Es gibt da keinen Zusammenhang, den man einfach so herstellen kann.

Javascript ist ISO (direkt vom Dienstleister)
Javascript ist UTF-8

Die Kodierung einer Webseite ist für Javascript nicht von Belang, weil es immer mit Unicode arbeitet. Ein Browser dekodiert jede Webseite in eine interne auf Unicode basierende Form. Etwas anderes wäre sowieso nicht sinnvoll, weil als Zeichensatz für Webseiten Unicode festgelegt wurde. Javascript als im Webseitenkontext laufende Sprache läuft praktischer- und logischerweise auch mit Unicode.

In dem vorliegenden Problemscript wird die Funktion encodeURIComponent() verwendet, bei der definiert ist, dass sie die Daten erst nach UTF-8 kodiert und anschließend URL-encodet. Der Bookmarkdienst sollte dies wissen und die empfangenen Daten entsprechend behandeln.

Aber was sieht man da? Welchen Link man von den beiden obigen nimmt ist egal, weil die Bookmarkseite stets mit der selben URL aufgerufen wird. Als Antwort bekommt man eine Seite mit

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

Der Link zu beispielsweise Mr. Wong jedoch sieht so aus:

<a href="#" rel="nofollow" onClick="window.open('http://www.mister-wong.de/index.php?action=addurl&amp;bm_url=http://dj-tut.de/z_test/selfhtml/bookmarks-utf.html&amp;bm_notice=&amp;bm_description=Lörem ipsüm dölär sit amet, cönsetetär; Script: UTF-8&amp;bm_tags=');">

Zu sehen ist also UTF-8-kodierter Text. Firefox ruft beim Click diese URL auf (mit livehttpheaders mitgeschrieben):

GET /index.php?action=addurl&bm_url=http://dj-tut.de/z_test/selfhtml/bookmarks.html&bm_notice=&bm_description=L%C3%83%C2%B6rem%20ips%C3%83%C2%BCm%20d%C3%83%C2%B6l%C3%83%C2%A4r%20sit%20amet,%20c%C3%83%C2%B6nsetet%C3%83%C2%A4r;%20Script:%20UTF-8&bm_tags= HTTP/1.1

Firefox konnte nicht anders als die UTF-8-Daten gemäß ihrer Deklaration als ISO-8859-1 als solche zu interpretieren, und hat sie UTF-8- und URL-encodiert, weswegen man beim L%C3%83%C2%B6rem 4 kodierte Byte für das ö sieht. Der IE8 hingegen fordert laut der DebugBar jedoch dies an:

GET /index.php?action=addurl&bm_url=http://dj-tut.de/z_test/selfhtml/bookmarks.html&bm_notice=&bm_description=Lörem%20ipsüm%20dölär%20sit%20amet,%20cönsetetär;%20Script:%20UTF-8&bm_tags= HTTP/1.1

Er URL-kodiert zwar Leerzeichen richtig nach %20, lässt aber die anderen Zeichen unkodiert, das heißt, er kodiert sie nur einmal von ISO-8859-1 nach Richtung UTF-8, lässt aber die URL-Kodierung weg.

Beide Varianten sehen aber verkorkst aus, weil zweimal UTF-8-kodiert wurde. Der FF bringt lediglich noch die URL-kodierung hinzu. Es ist auf alle Fälle schon fast ein Wunder, dass wenigstens einmal Mister Wong richtige Umlaute erkennen konnte. Jedenfalls glaube ich nicht, dass das was der Bookmarksdienst da veranstaltet, so seine Richtigkeit hat.

Lo!