nicht angemeldet
Umlaute im src-Attribut
0 0
Umlaute im src-Attribut
Der MartinHello,
durch ein kleines Musterscript bin ich eben auf ein Denkspiel gestoßen.
Das Script gibt dieses HTML aus:
<img id="img1"
class="odd"
src="bilder/Drei.png"
alt="Bild Nr. 1">
<img id="img3"
class="even"
src="bilder/Eins.png"
alt="Bild Nr. 3">
<img id="img5"
class="odd"
src="bilder/Fuenf.png"
alt="Bild Nr. 5">
<img id="img7"
class="even"
src="bilder/Fünf.png"
alt="Bild Nr. 7">
<img id="img9"
class="odd"
src="bilder/Vier.png"
alt="Bild Nr. 9">
<img id="img11"
class="even"
src="bilder/Zwei.png"
alt="Bild Nr. 11">
Der IE zeigt alle Bilder an.
Der Firefox kann das Bild 'Fünf.png' nicht abrufen vom WAMPP-Server.
Nach dem Hochladen auf meinen Linux-Host hat es allerdings geklappt.
Ist das jetzt eine Macke vom XAMPP oder vom Firefox?
Auch ein urlencode() oder rawurlencode() (PHP) hilft nicht.
Wie wäre es denn richtig?
Beispiel unter:
http://selfhtml.bitworks.de/scripts/bilder_einbinden/show_pictures.php
http://selfhtml.bitworks.de/scripts/bilder_einbinden/show_pictures.php.txt
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo,
Wie wäre es denn richtig?
Beispiel unter:
http://selfhtml.bitworks.de/scripts/bilder_einbinden/show_pictures.php
Es ist schon ziemlich frech, einfach HTML-Elemente ohne jeden Dateikopf, body usw. auzuliefern und eine korrekte Anzeige zu erwarten.
Mein FF3 tippt einfach auf den Zeichensatz ISO-8859-1, und ein Bild namens "bilder/Fünf.png" kann er nunmal nicht laden. Wenn man ihm via Ansicht->Zeichenkodierung sagt, dass die Kodierung UTF-8 ist, dann lädt er auch brav das Bild "bilder/Fünf.png".
Gruß, Don P
-
Hello,
Es ist schon ziemlich frech, einfach HTML-Elemente ohne jeden Dateikopf, body usw. auzuliefern und eine korrekte Anzeige zu erwarten.
*hups*
Stimmt irgendwie. Daran habe ich eben nicht gedacht.
Der XAMPP hat eine andere Voreinstellung als der Linux-Host.Aber es ist eigentlich anders herum. Der Linux fährt iso-8859-1 und der Xampp müsste dann utf-8 fahren. Das muss ich nochmal untersuchen.
Bleibt nur die Frage, wieso der IE es bei beiden kann.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo,
Bleibt nur die Frage, wieso der IE es bei beiden kann.
Der IE kann so zeimlich alles irgendwie. Er hält sich nicht an Standards und erwartet auch keine standardkonformen Dokumente. Wahrscheinlich benutzt er eine Fuzzy-Logic um herauszufinden, was der Schöpfer der Seite wohl am wahrscheinlichsten gemeint haben könnte.
Somit ist er m.E. dafür verantworlich, dass so viele technisch miserable Seiten überhaupt im Netz sind. Jeder Anfänger erstellt irgend eine Seite und denkt sich "der IE zeigt's an, dann kann's ja nicht falsch sein. Die anderen Browser taugen eben nichts. Es lebe M§!"
Gruß, Don P
-
Hello,
Der IE kann so zeimlich alles irgendwie. Er hält sich nicht an Standards und erwartet auch keine standardkonformen Dokumente. Wahrscheinlich benutzt er eine Fuzzy-Logic um herauszufinden, was der Schöpfer der Seite wohl am wahrscheinlichsten gemeint haben könnte.
Es liegt wohl auch am FTP-Programm Filezilla, das beim Hochladen aus ???? vom Windows-XP-Host utf-8 auf dem Linux-Host gemacht hat.
Nachdem ich das richtig gestellt habe (der Linux-Host benutzt noch ISO-8859-1), kann es der IE nicht mehr.
Und siehe da, was ist in /extras/internetoptionen/erweitert eingestellt gewsen?
URLs immer als utf-8 senden. Na, wer _das_ wohl mal gemacht hat? *tztz*Aber was wird die Konsequenz aus dieser kleinen Ehrenrunde sein?
Das gibt nochmal mächtig zu denken.- welche Codierung und welche Zeichensätze verwenden die Filesysteme?
- wie kann man die Codierung der Filesysteme beiinflussen?
- Was ist bei den Browsern eingestellt?
- Wie kann man das beim request erkennen?
- muss man in Scripten darauf Rücksicht nehmen, oder ist es Sache des HTTP-Dienstes
- ...
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hello,
Aber was wird die Konsequenz aus dieser kleinen Ehrenrunde sein?
Das gibt nochmal mächtig zu denken.- welche Codierung und welche Zeichensätze verwenden die Filesysteme?
- wie kann man die Codierung der Filesysteme beiinflussen?
- Was ist bei den Browsern eingestellt?
- Wie kann man das beim request erkennen?
- muss man in Scripten darauf Rücksicht nehmen, oder ist es Sache des HTTP-Dienstes
- ...
Ich bastel da nun schon die ganze Zeit, aber auf dem XAMPP bekomme ich es nicht hin, eine einschätzbare Lösung zu finden.
AddDefaultCharset UTF-8
oder
AddDefaultCharset ISO-8859-1haben zwar manchmal Auswirkungen, aber nicht immer und bisher nicht nachvollziehbar, wann.
An Neustart des Webservers und Schließen/Öffnen aller Browserfesnter wurde selbstverständlich gedachtLiebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hello,
Ich bastel da nun schon die ganze Zeit, aber auf dem XAMPP bekomme ich es nicht hin, eine einschätzbare Lösung zu finden.
AddDefaultCharset UTF-8
oder
AddDefaultCharset ISO-8859-1haben zwar manchmal Auswirkungen, aber nicht immer und bisher nicht nachvollziehbar, wann.
An Neustart des Webservers und Schließen/Öffnen aller Browserfesnter wurde selbstverständlich gedachtDie Live-Headers sehen so aus:
---------------------------------------------------------- = XAMPP
http://testserver.lan/bilder_einbinden/bilder/F%FCnf.pngGET /bilder_einbinden/bilder/F%FCnf.png HTTP/1.1
Host: testserver.lan
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20
Accept: image/png,*/*;q=0.5
Accept-Language: de-de,de;q=0.8,en-us;q=0.6,en;q=0.4,fr-fr;q=0.2
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://testserver.lan/bilder_einbinden/show_pictures.php
Pragma: no-cache
Cache-Control: no-cacheHTTP/1.x 403 Forbidden
Date: Sun, 24 May 2009 19:46:23 GMT
Server: Apache/2.2.11 (Win32) DAV/2 mod_ssl/2.2.11 OpenSSL/0.9.8i PHP/5.2.9
Vary: accept-language,accept-charset
Accept-Ranges: bytes
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
Content-Language: de---------------------------------------------------------- = Debian 4.0 - Pakete
http://selfhtml.bitworks.de/scripts/bilder_einbinden/bilder/F%FCnf.pngGET /scripts/bilder_einbinden/bilder/F%FCnf.png HTTP/1.1
Host: selfhtml.bitworks.de
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20
Accept: image/png,*/*;q=0.5
Accept-Language: de-de,de;q=0.8,en-us;q=0.6,en;q=0.4,fr-fr;q=0.2
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://selfhtml.bitworks.de/scripts/bilder_einbinden/show_pictures.php
Pragma: no-cache
Cache-Control: no-cacheHTTP/1.x 200 OK
Date: Sun, 24 May 2009 19:43:35 GMT
Server: Apache/2.2.3 (Debian) PHP/5.2.6-1+lenny2 with Suhosin-Patch
Last-Modified: Sun, 24 May 2009 12:30:29 GMT
Etag: "10ef41-b50c-a8af8340"
Accept-Ranges: bytes
Content-Length: 46348
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: image/pngDas bedeutet also nun, dass ich ein Problem mit dem Apache im XAMPP habe.
Müsste der nicht den URL-codierten Request wieder umwandeln in das angegebene Character-Set?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hello,
Das bedeutet also nun, dass ich ein Problem mit dem Apache im XAMPP habe.
Müsste der nicht den URL-codierten Request wieder umwandeln in das angegebene Character-Set?
Weiß denn irgend jemand, ob das nun vorgesehenes Verhalten, falsche Einstellung oder ein Bug ist?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
echo $begrüßung;
Das bedeutet also nun, dass ich ein Problem mit dem Apache im XAMPP habe.
Bei Dateinamen spielt das Datei-/Betriebssystem ebenfalls eine Rolle.
Müsste der nicht den URL-codierten Request wieder umwandeln in das angegebene Character-Set?
Welches Charset? Das im Content-Type-Header gilt für den Content. Für URLs oder allgemein den Request gibt der Client kein Encoding an. Und ich weiß auch nicht, was die HTTP-RFC zu dem Thema sagt.
echo "$verabschiedung $name";
-
Hello,
Welches Charset? Das im Content-Type-Header gilt für den Content. Für URLs oder allgemein den Request gibt der Client kein Encoding an. Und ich weiß auch nicht, was die HTTP-RFC zu dem Thema sagt.
Die sagt: eingeschränktes Character Set, ein Subset von ASCII.
Ich muss das mal suchen, habe es aber noch irgendwo von einer Diskussion um urlencode versa rawurlencode
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hello,
Welches Charset? Das im Content-Type-Header gilt für den Content. Für URLs oder allgemein den Request gibt der Client kein Encoding an. Und ich weiß auch nicht, was die HTTP-RFC zu dem Thema sagt.
http://www.faqs.org/rfcs/rfc1738.html -> Abschnitt 2.2
Also nur druckbare Zeichen des ASCII-Character Sets sind gestattet.
Alle anderen sollen durch hexadezimal codierte "Triplets" (die mit dem führenden %) codiert werden.
Das % ist zwar auch druckbar, muss dann aber folglich ebenfalls kodiert werden, sozusagen als Kollateralschaden ;-)Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
echo $begrüßung;
http://www.faqs.org/rfcs/rfc1738.html -> Abschnitt 2.2
Also nur druckbare Zeichen des ASCII-Character Sets sind gestattet.Alle anderen sollen durch hexadezimal codierte "Triplets" (die mit dem führenden %) codiert werden.
Das % ist zwar auch druckbar, muss dann aber folglich ebenfalls kodiert werden, sozusagen als Kollateralschaden ;-)Soweit so klar, aber da bleibt immer noch offen, was die hexadezimalen Werte darstellen sollen. UTF-8-Sequenzen oder ISO-8859-1 oder ...? Mir ist nicht bekannt, dass man dem Apachen sagen könnte, gemäß welcher Kodierung er das zu interpretieren hat, und obendrein, mit welcher er das Dateisystem ansprechen soll.
Der allgemein gültige Rat lautet immer noch: Nicht-ASCII-Zeichen in URLs und Dateinamen vermeiden (egal ob umkodiert oder nicht). (Ausnahme ist der Querystring, der meist nicht vom Webserver ausgewertet werden muss.
echo "$verabschiedung $name";
-
Hello,
Soweit so klar, aber da bleibt immer noch offen, was die hexadezimalen Werte darstellen sollen. UTF-8-Sequenzen oder ISO-8859-1 oder ...? Mir ist nicht bekannt, dass man dem Apachen sagen könnte, gemäß welcher Kodierung er das zu interpretieren hat, und obendrein, mit welcher er das Dateisystem ansprechen soll.
Der allgemein gültige Rat lautet immer noch: Nicht-ASCII-Zeichen in URLs und Dateinamen vermeiden (egal ob umkodiert oder nicht). (Ausnahme ist der Querystring, der meist nicht vom Webserver ausgewertet werden muss.
Scheint mir auch so.
Entweder, ich habe eine Einstellmöglichkeit beim Apachen übersehen, oder sie fehlt einfach.Aber auch die PHP-Funktion utf8_encode() macht mir noch Kopfzerbrechen. Von welcher Ausgangscodierung geht die denn aus?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
echo $begrüßung;
Aber auch die PHP-Funktion utf8_encode() macht mir noch Kopfzerbrechen. Von welcher Ausgangscodierung geht die denn aus?
utf8_encode — Encodes an ISO-8859-1 string to UTF-8.
Nicht alles, was wie ISO-8859-1 oder Latin1 aussieht ist auch solches, manches ist Windows-1252.
echo "$verabschiedung $name";
-
Hello,
Aber auch die PHP-Funktion utf8_encode() macht mir noch Kopfzerbrechen. Von welcher Ausgangscodierung geht die denn aus?
utf8_encode — Encodes an ISO-8859-1 string to UTF-8.
Nicht alles, was wie ISO-8859-1 oder Latin1 aussieht ist auch solches, manches ist Windows-1252.
Ja, das steht zu vermuten.
Zum Thema, was dem Apachen fehlt, habe ich noch einen interessanten Thread gefunden.
http://groups.google.com/group/de.comm.software.webserver/browse_thread/thread/be4ffda7fa90678f
Demnach müsste man also beim Apache-Team anfordern, dass die ein Filesystem-Modul zur Verfügung stellen, in dem man dann die Codierung im Filesystem und diejenige in der URL angeben kann und das dann für die Transformation sorgt.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hello,
Ab PHP 6.x übernimmt PHP einen Teil der Arbeit.
unicode.fallback_encoding NULL PHP_INI_ALL Available since PHP 6.0.0.
unicode.filesystem_encoding NULL PHP_INI_ALL Available since PHP 6.0.0.
unicode.http_input_encoding NULL PHP_INI_ALL Available since PHP 6.0.0.Der Eingriff ist aber mMn dort gar nicht an der richtigen Stelle.
Zugriffe auf das Filesystem dürften gar nicht direkt von den Script-Engines stattfinden, sondern müssten über den Webserver abgewickelt werden, in dessen Auftrag sie ja tätig werden!
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
echo $begrüßung;
Ab PHP 6.x übernimmt PHP einen Teil der Arbeit.
unicode.fallback_encoding NULL PHP_INI_ALL Available since PHP 6.0.0.
unicode.filesystem_encoding NULL PHP_INI_ALL Available since PHP 6.0.0.
unicode.http_input_encoding NULL PHP_INI_ALL Available since PHP 6.0.0.Das ist für dein Problem eher nebensächlich bis belanglos, weil zuerst der Apache die URL auswerten muss und erst dann PHP zum Zuge kommen kann.
Der Eingriff ist aber mMn dort gar nicht an der richtigen Stelle.
Zugriffe auf das Filesystem dürften gar nicht direkt von den Script-Engines stattfinden, sondern müssten über den Webserver abgewickelt werden, in dessen Auftrag sie ja tätig werden!
Achwas! Zum einen ist PHP nicht nur ein Webserver-Plugin, zum anderen: wie soll das bei CGI-Anbindung gehen? Und zum dritten müsste PHP den Konfigurationsbeschränkungen des Webservers gehorchen, was dazu führen dürfte, dass Aufrufe außerhalb des Documentroots nicht möglich wären.
echo "$verabschiedung $name";
-
Hello,
Achwas! Zum einen ist PHP nicht nur ein Webserver-Plugin, zum anderen: wie soll das bei CGI-Anbindung gehen? Und zum dritten müsste PHP den Konfigurationsbeschränkungen des Webservers gehorchen, was dazu führen dürfte, dass Aufrufe außerhalb des Documentroots nicht möglich wären.
Na, dann mach Dir mal Gedanken :-)
Dass der Webserver für manche Aufgaben unter einem bestimmten User läuft und HTTP-Zugriffe auf die Document-Root beschränkt, hat aber nichts damit zu tun, dass andere seiner Funktionen direkt einen Logserver ansprechehn können, mit einem Mailserver korrespondieren können (ich meine hier nicht die Script-Engines) oder sogar selber in Logverzeichneissen Schreibrechte haben...
Fehlende Dienste oder Kindprogramme, die unter anderen Rechten laufen könnten, ließen sich da sicherlich einbauen. Das würde allerdings konzeptionelle Ergänzungen erforderlich machen.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
-
-
-
-
Hallo,
»» http://www.faqs.org/rfcs/rfc1738.html -> Abschnitt 2.2
»» Also nur druckbare Zeichen des ASCII-Character Sets sind gestattet.
»» [...]
Soweit so klar, aber da bleibt immer noch offen, was die hexadezimalen Werte darstellen sollen. UTF-8-Sequenzen oder ISO-8859-1 oder ...?natürlich bleibt das offen, denn das ist dann schon nicht mehr der URL-Kontext, sondern dessen Abbildung auf das Filesystem oder andere lokale Eigenschaften des Servers. Die Eigenschaften dieses serverinternen Kontexts (also z.B. die Zeichencodierung oder eine eventuelle Beschränkung auf ein Subset) muss man daher schon beim Erzeugen der Roh-URL beachten, noch bevor die URL-Codierung mit dem %-Prefix greift.
Die Post schreibt uns ja auch nicht vor, wie wir einen Briefbogen zu beschreiben haben, sondern nur die Beschriftung des Umschlags.
Mir ist nicht bekannt, dass man dem Apachen sagen könnte, gemäß welcher Kodierung er das zu interpretieren hat
Er muss das gar nicht interpretieren, sondern die URLs nach der URL-Decodierung uninterpretiert an das Subsystem übergeben, dessen er sich bedient (Filesystem, Handlerfunktion, CGI-Schnittstelle). Auch bei internen URL-Operationen (z.B. mod_rewrite) muss der Apache nicht wissen, was die Bytes bedeuten, die er da vergleicht. Er behandelt sie Byte für Byte, ohne sich dafür zu interessieren, für welches Zeichen diese Bytes stehen.
Der allgemein gültige Rat lautet immer noch: Nicht-ASCII-Zeichen in URLs und Dateinamen vermeiden (egal ob umkodiert oder nicht).
Ja. Auch wenn in einem gegebenen Kontext vielleicht eine Menge Sonderzeichen erlaubt sein mögen, tut man gut daran, sie zu vermeiden, solange man die Schnittstellen zu anderen Systemen nicht exakt kennt.
Ciao,
Martin--
Niemand ist überflüssig: Er kann immer noch als schlechtes Beispiel dienen.-
Hello,
Er muss das gar nicht interpretieren, sondern die URLs nach der URL-Decodierung uninterpretiert an das Subsystem übergeben, dessen er sich bedient (Filesystem, Handlerfunktion, CGI-Schnittstelle). Auch bei internen URL-Operationen (z.B. mod_rewrite) muss der Apache nicht wissen, was die Bytes bedeuten, die er da vergleicht. Er behandelt sie Byte für Byte, ohne sich dafür zu interessieren, für welches Zeichen diese Bytes stehen.
DAS ist aber ein Problem, wenn man Webanwendungen von einer Plattform auf die andere portieren will.
Dadurch bin ich doch erst auf diese Thematik aufmerksam geworden. Es kann hier nicht Aufgabe der Applikation sein, die URLs passend für das darunterliegende Filesystem zu codieren, das ist Aufgabe der Schnittstelle zwischen Webserver und Filesystem.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
-
-
-
-
-
-