1. Nachrichten
  2. Forum
    1. Unerledigte Themen
    2. Forenregeln
  3. Spenden
  • Anmelden
  • Registrieren
  • Suche
Alles
  • Alles
  • Artikel
  • Seiten
  • Forum
  • Erweiterte Suche
  1. camp-firefox.de
  2. fackel

Beiträge von fackel

  • UTF-8-kodierte URI im Element IMG

    • fackel
    • 13. September 2006 um 10:39

    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)?

  • UTF-8-kodierte URI im Element IMG

    • fackel
    • 13. September 2006 um 09:50

    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

  • UTF-8-kodierte URI im Element IMG

    • fackel
    • 12. September 2006 um 15:04
    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).

  • UTF-8-kodierte URI im Element IMG

    • fackel
    • 12. September 2006 um 12:58
    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.

  • UTF-8-kodierte URI im Element IMG

    • fackel
    • 12. September 2006 um 10:08

    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.

  • UTF-8-kodierte URI im Element IMG

    • fackel
    • 11. September 2006 um 16:19

    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.

Unterstütze uns!

Jährlich (2025)

92,9 %

92,9% (604,17 von 650 EUR)

Jetzt spenden
  1. Kontakt
  2. Datenschutz
  3. Impressum
Community-Software: WoltLab Suite™
Mastodon