UTF-8-kodierte URI im Element IMG

    Hallo zusammen!

    Bin völlig verwirrt, wie man das mit den URIs im Attribut SRC beim Element IMG richtig macht. Der Fall: Auf der Platte liegt eine Bilddatei "bläd.jpg" und dieses möchte ich in meinem HTML in Firefox 1.5.0.6 anzeigen.

    Folgendes hab ich probiert, kann aber die Ergebnisse nicht verstehen (das HTML-Dokument selbst hat als Kodierung UTF-8 - in den METAs angegeben -, und im Text werden Sonderzeichen richtig angezeigt):

    (1) Umlaut in UTF-8-Kodierung und escaped (nach meinem Verständnis des RFCs zu URIs und des HTML-Standards sollte das so sein) - Bild wird aber NICHT angezeigt!
    <img src="bl%C3%A4d.jpg">

    (2) Umlaut als UTF-8, kein Escaping (nach dem Buchstaben des Gesetzes ist das eigentlich falsch, weil eine URI nur ASCII-Zeichen enthalten soll) - Bild wird aber trotzdem angezeigt!
    <img src="bläd.jpg" alt="-NOT FOUND-" width="340">

    (3) Umlaut in ISO-8859-1-Kodierung und escaped - Bild wird angezeigt (obwohl das Dokument selbst in UTF-8 kodiert ist)
    <img src="bl%E4d.jpg">

    Warum geht 2, aber nicht 1, obwohl doch beides UTF-8 darstellt und auch der im HTML angegebenen Kodierung entspricht?

    Warum geht 3 überhaupt? Das HTML ist doch UTF-8! Wieso kann Firefox die URI richtig auflösen, obwohl die Zeichen "falsch" (also ANSI) kodiert sind?

    Kann mich jemand aufklären? Danke.

    FF

    PS: Übrigens, die Konkurrenz IE verhält sich wie Firefox. Da scheint man sich wohl abgesprochen zu haben.

    Hi!

    Ich denke (3) funktioniert deswegen, weil der Browser zuerst von utf-8 nach latin rückübersetzt und erst danach die URL unescaped. Aus der umgekehrten Sicht: Wenn man von latin als Standard ausgeht und zuerst Sonderzeichen in Webadressen escaped, verändert die anschliessende Konvertierung des Dokuments nach utf8 an dieser Stelle ja nichts mehr, da die Sonderzeichen ja bereits escaped sind. Das Dokument ist dann zwar utf8, aber sieht trotzdem nicht anders aus als latin.

    Gruss,
    Scheinmensch

    Hi!

    Zitat von Scheinmensch

    Ich denke (3) funktioniert deswegen, weil der Browser zuerst von utf-8 nach latin rückübersetzt und erst danach die URL unescaped.

    Das hört sich für mich so an, als ob der Browser nach Gutdünken bestimmt, nach welcher Kodierung er URLs dekodiert (d.h. die Kodierung des Dokumentes soll dabei keine Rolle spielen?!). Was ist, wenn die Dinge nicht so klar wie hier mit UTF-8 vs. Latin-1 liegen? Z.B. ist das Zeichen %E4 in Latin-1 ein "ä", in Latin-5 (Kyrillisch) aber ein "д". Wenn mein Dokument in Latin-1 kodiert ist, hätte ich wohl an die Datei "bläd.jpg" gedacht, wenn aber in Latin-5, dann wäre mir als Ziel "blдd.jpg" doch lieber gewesen. Was ist, wenn beide Dateien im System liegen?

    Und was passiert, wenn zwar mein Browser (wegen meines westlichen Windows) als "Standard" Latin-1 für URLs verwendet, aber der Browser meines Freundes in Japan doch lieber UTF-8 nimmt und dann mit meinen Latin-1-kodierten (oder gar Latin-5-kodierten) URLs nichts anfangen kann, bzw. sie falsch interpretiert. Das bedeutet doch, dass das HTML nicht mehr universell sondern bloss regional brauchbar ist.

    Zitat von Scheinmensch

    Aus der umgekehrten Sicht: Wenn man von latin als Standard ausgeht und zuerst Sonderzeichen in Webadressen escaped, verändert die anschliessende Konvertierung des Dokuments nach utf8 an dieser Stelle ja nichts mehr, da die Sonderzeichen ja bereits escaped sind. Das Dokument ist dann zwar utf8, aber sieht trotzdem nicht anders aus als latin.

    Mir ist klar, dass die Kodierungen nur verschiedene Repräsentationen desselben Inhaltes sind. Nur, gibt es eine Möglichkeit, im HTML die Möglichkeit, das was Du mit "Standard" bezeichnest, selbst festzulegen, und zwar bezogen auf die URLs (weil für die Inhalte gibt es ja das META-Tag mit ContentType)? Das wäre doch ne schöne Sache.

    wenn ich RFC 1738 richtig verstehe, sind die mit Prozent-Zeichen kodierten URLs immer US-ASCII:

    Zitat

    In addition, octets may be encoded by a character triplet consisting
    of the character "%" followed by the two hexadecimal digits (from
    "0123456789ABCDEF") which forming the hexadecimal value of the octet.
    (The characters "abcdef" may also be used in hexadecimal encodings.)

    Octets must be encoded [...] within the US-ASCII coded character set...

    Zitat von Dr. Evil

    wenn ich RFC 1738 richtig verstehe, sind die mit Prozent-Zeichen kodierten URLs immer US-ASCII

    Richtig. Die %-Zeichen-Geschichte ist aber (zumindest in dem mich hier interessierenden Sinne) keine Zeichenkodierung sondern "nur" ein Byte-Escaping (man beachte die Unterscheidung von Zeichen vs. Bytes/Octets, die auch im RFC 1738 getroffen wird). Der RFC besagt ja, man möge die URI mit den Sonder*zeichen* erst nach UTF-8 umzuwandeln und die daraus resultierenden Bytes mittels %-Escaping nach US-ASCII (also andere Bytes - was im engeren Sinne natürlich eine Umkodierung ist, die mir hier aber nebenranging erscheint) zu bringen.

    Das Escaping ist also dafür da, die Byte(!)-Repräsentation der URL nach US-ASCII zum Zweck der "besseren Transportfähigkeit" zu bringen. Die Bytes der URL ergeben aber nur einen Sinn (sprich, führen in meinem Fall zu einer Bilddatei), wenn sie entsprechend einer Kodierung als Zeichen(!) interpretiert werden. Und darum geht es mir letzlich hier: Firefox findet in Variante #1 die Bilddatei nicht (obwohl nach meiner Meinung alles wunderhübsch verpackt und stimmig ist), in den anderen (nach meinem Verständins nach Standard illegalen (#2) bzw. unzutreffenden (#3) Darstellungen) aber witzigerweise schon. Und genau das hätte ich gerne verstanden, wenn es denn dafür eine bessere Erklärung als "is halt so" gibt.

    Zitat von fackel

    Der RFC besagt ja, man möge die URI mit den Sonder*zeichen* erst nach UTF-8 umzuwandeln und die daraus resultierenden Bytes mittels %-Escaping nach US-ASCII

    Der Vollständigkeit halber hier noch die entsprechende Passage aus RFC 3968:


    Und irgendwie scheint das auch halbwegs zu funktionieren. Wenn ich keine Datei namens C:/ä.jpg besitze, und rufe file:///C:/%C3%A4.jpg oder file:///C:/%E4.jpg oder file:///C:/ä.jpg auf, kommt in allen Fällen die gleiche Fehlermeldung:

    Zitat

    Die Dateien unter /C:/ä.jpg konnten nicht gefunden werden.


    Existiert die Datei, kann ich sie aber nur mit der %E4-Variante anzeigen; mit %C3%A4 oder ä kommt wieder o.g. Meldung.

    Zitat von Pumbaa80

    Existiert die Datei, kann ich sie aber nur mit der %E4-Variante anzeigen; mit %C3%A4 oder ä kommt wieder o.g. Meldung.

    Interessant, und irgendwie konsistenter als im Firefox. Bei mir geht mit Firefox die ä-Variante auch (siehe Fall #2). Bei dir scheinen ja wenigstens die UTF-8-Varianten insgesamt geächtet zu werden.

    Welchem Progrämmsche hast Du denn die Fehlermeldung "Die Dateien ... konnten nicht gefunden werden" entlockt. Firefox gibt bei mir keine explizite Meldung zu nicht vorhandenen/gefundenen Bildern aus (machen glaube ich Web-Browser generell nicht - die stellen ja nur evtl. ein Ersatzbild oder das ALT-Attribut dar).

    Zitat von fackel

    Das hört sich für mich so an, als ob der Browser nach Gutdünken bestimmt, nach welcher Kodierung er URLs dekodiert (d.h. die Kodierung des Dokumentes soll dabei keine Rolle spielen?!).


    Die URL muss am Ende so aussehen, wie es das HTTP-Protokoll vorschreibt, damit der Server den Request versteht. Wessen Gutdünken das war, weiss ich nicht, aber es ist nicht die Erfindung eines Browsers. Und ja, selbstverständlich ist es vollkommen egal, wie das Dokument kodiert ist. Eine URL muss, wenn sie an den Server geschickt wird immer gleich aussehen, ganz egal, wie sie kodiert war, damit sie irgendein, aus unserer Sicht exotischer, Mensch lesen konnte.

    Gruss,
    Scheinmensch

    Hi!

    Zitat von Scheinmensch


    Die URL muss am Ende so aussehen, wie es das HTTP-Protokoll vorschreibt, damit der Server den Request versteht. Wessen Gutdünken das war, weiss ich nicht, aber es ist nicht die Erfindung eines Browsers. Und ja, selbstverständlich ist es vollkommen egal, wie das Dokument kodiert ist. Eine URL muss, wenn sie an den Server geschickt wird immer gleich aussehen, ganz egal, wie sie kodiert war, damit sie irgendein, aus unserer Sicht exotischer, Mensch lesen konnte.

    Vielleicht nochmal zur Klarstellung: Mir geht es hier einzig und allein um den lokalen Zugriff des FireFox auf ein lokal vorhandenes HTML und auf lokal vorhandene Bilddateien. Ich will (momentan) gar nicht erst den Server als weitere Komponente ins Spiel bringen. Die Sache ist so schon verquer genug.

    Danke,
    FF

    Hi!

    Also für mich ist die Sache eindeutig. Version (1) ist falsch, da Du die Reihenfolge der Kodierungen verwechselt hast. Das Escapen ist für das HTTP-Protokoll und nicht für die Ausgabe im Browser. (2) ist falsch, weil nicht escaped wird, da sind wir uns ja einig. Und (3) ist die korrekte und einzig sinnvolle Variante.
    Was allerdings wirklich verquer wäre, wäre, wenn sich URLs zu lokalen Dateien in der Kodierung von solchen zu Dateien auf Servern unterscheiden würden. Das wäre tatsächlich extrem seltsam!

    EDIT: Fehler editiert.

    Gruss,
    Scheinmensch

    Hi!

    Zitat von Scheinmensch

    Version (1) ist falsch, da Du die Reihenfolge der Kodierungen verwechselt hast. Das würde ja bedeuten, das im HTTP-Request utf8 verwendet würde!

    Das sehe ich im Zusammenhang mit deiner Feststellung zu (3), s.u.

    Zitat von Scheinmensch

    Das Escapen ist für das HTTP-Protokoll und nicht für die Ausgabe im Browser.

    Wieso HTTP-Protokoll? Die URL ist in meinem Fall eine file-URL, und wie schon angemerkt, wir reden hier von rein lokalen Zugriffen auf's Dateisystem.

    Zitat von Scheinmensch

    Und (3) ist die korrekte und einzig sinnvolle Variante.

    Du gehts also davon aus, dass Latin-1 *die* Kodierung für URLs ist (vor dem %-Escaping natürlich, denn nach dem Escaping haben wir ja nur mehr ASCII)? Wo steht das (ich frage echt nicht polemisch, sondern möchte es gerne evtl. auch im größeren Zusammenhang nachlesen und hoffentlich kapieren)?

    Zitat von fackel

    Hi!


    Das sehe ich im Zusammenhang mit deiner Feststellung zu (3), s.u.?

    Diesen Satz verstehe ich leider nicht. BTW: Das mit utf8 im HTTP stimmt ja auch nicht. War ein Fehler von mir, den ich nicht schnell genug ediert habe. Sorry!

    Welcher Zeichensatz im HTTP-Protokoll verwendet wird, weiss ich nicht. Jedenfalls ist das der Standard, wenn es vielleicht auch nicht latin ist, wie zuerst von mir angenommen. Jedenfalls muss sichergestellt werden, dass nach dem Anklicken eines Links, aus diesem ein ordentlicher Request wird.

    Zitat von fackel

    Wieso HTTP-Protokoll? Die URL ist in meinem Fall eine file-URL, und wie schon angemerkt, wir reden hier von rein lokalen Zugriffen auf's Dateisystem.


    Weil HTTP das Normale ist, und es wie schon gesagt, keinen Unterschied in der Kodierung gibt. Die Routinen des Browsers, die die Kodierungen bearbeiten wissen garantiert auch noch gar nicht, um was für eine Art Link es sich dabei handelt.

    Gruss,
    Scheinmensch

    Zitat von fackel

    Interessant, und irgendwie konsistenter als im Firefox. Bei mir geht mit Firefox die ä-Variante auch (siehe Fall #2). Bei dir scheinen ja wenigstens die UTF-8-Varianten insgesamt geächtet zu werden.
    Welchem Progrämmsche hast Du denn die Fehlermeldung "Die Dateien ... konnten nicht gefunden werden" entlockt. Firefox gibt bei mir keine explizite Meldung zu nicht vorhandenen/gefundenen Bildern aus (machen glaube ich Web-Browser generell nicht - die stellen ja nur evtl. ein Ersatzbild oder das ALT-Attribut dar).

    Jaja, mir ging es aber darum, zwei verschiedene Probleme anzupacken:
    1. Was passiert im Browser mit dem HTML?
    2. Welche URL ist korrekt?
    Da ich mich zunächst nur auf 2. konzentriert habe, habe ich die URL direkt beim Firefox in die Adressleiste eingegeben. Darum geht es doch bei dieser ganzen Encoding-Geschichte.

    Man kann zum Testen auch diesen Code verwenden:

    Interessant finde ich auch den Unterschied, wenn man das als UTF-8 bzw. ANSI speichert (im Editor): Ist die Datei als UTF-8 gespeichert, sehe ich die Bilder 2,3,5; als ANSI sehe ich 2,3,4.
    Wenn ich ein Bild anklicke, erscheint in der Adressleiste auf jeden Fall "%E4.jpg"

    Lade ich das HTML und die Grafik auf meinen Webspace, dann funktioniert dort nur Bild 2, sonst gar nichts.

    Hier noch ein Auszug aus dem RFC 1738:

    Zitat

    Only alphanumerics [0-9a-zA-Z], the special characters "$-_.+!*'()," [not including the quotes - ed], and reserved characters used for their reserved purposes may be used unencoded within a URL.