Hallo,

Da ist ein kleines Problem mit Zeichensätzen in Dateipfaden.
Ich weiss jetzt nicht ob's an Linux liegt oder weil's online ist. Lokal unter windows läuft alles prima.

Jedenfalls sind da einige Bilddateien mit Sonderzeichen im Namen:

z.B: das_ist_1_€.jpg

Direkt als

krieg ich kein Bild, obwohl der Dateipfad richtig angeben wird.
Auch in den Bildeigenschaften scheint alles zu stimmen.

mit

geht's dann.

Übergeb ich das Bild roh "das_ist_1_€.jpg" nun jedoch an Javascript krieg ich mit

den Pfad als unicode zurück: 'das_ist_1_%E2%82%AC.jpg'

auch hier schafft

Abhilfe.

Nicht dass mich das irgendwie stört, nur tritt das gleiche Problem bei dem Anführungszeichen (") auf. Hat da jemand eine Liste welche Zeichen genau davon betroffen sind? Das Dollarzeichen ($) funktioniert z.B. einwandfrei.

( btw. dass man / " ' * ; - & ? ( ) [ ] ~ ! $ { } > < # @ nicht in Linux-Dateipfaden benutzen sollte, weiss ich auch. )

( btw 2:Die Quotes sind da , weil der € hier mit dem "[code]"-tag in keiner der 3 Versionen funktioniert. )

Merkwürdigerweise kann man mit php den Dateipfad nur mit "das_ist_1_€.jpg" lesen.
if(!is_file('das_ist_1_€.jpg'))echo 'das funktioniert nie und nimmer';
else echo 'doch das funktioniert';

???

Gruss

Tümmel

Zu schwierig ?

Bis ich eine Liste hab, lass ich halt nur ascii-character zu.

Das hat also keine Eile.

Tuemmel,

das hat nichts mit Server-Gewurstel zu tun, Du hast einfach invaliden HTML-Code. URLs sind genau definiert (http://www.ietf.org/rfc/rfc1738.txt) und erlauben nur die Zeichen 'a' bis 'z', '0' bis '9', '+', '.' und '-'.

Wir haben heute den 18. März 2008.

Seit einigen Jahren sollten urls auch uft8-encoded gelesen werden können.

Die urls komplett als hex-werte zu übergeben, hab ich auch schon überlegt.

Der Artikel war aber ganz erheiternd.

Das das hier nicht wie angeben unicode sondern utf-8 steht, gibt mir mehr umso mehr zu denken, da der Browser eigentlich utf-8 encodete urls lesen sollte.

Ich frage mich nur, wie es kommt dass javascript mit linux zusammen utf-8 nicht lesen kann, während javascript mit windows die url korrekt liest und warum übehaupt einmal der € in hex umgewandelt wird und ein andernmal in utf-8.

Aber an Grundlagenforschung habe ich kein Interesse mehr und das Interesse an Grundlagenforschung für linux befindet sich auf der Höhe meiner letztes Jahresbilanz.

Hätte ja sein können, dass jemand einfach dieses Symptom bereits schon mal umgehen musste.

Tuemmel,

der erheiternde Artikel ist das Dokument, nach dem sich die Browserprogrammierer bei der Implementierung des URL-Parsings richten.

Für eine korrekte Kodierung schau Dir in Javascript mal escape(), bzw. bei php urlencode() oder bei Perl URI::Escape an.

Hallo Profo,

Aha,

... und das bereits seit 1994. Stell dir vor, die Motorenbauer von heute richten sich noch nach dem 1876 erfundenen Ottomotor, will sagen kalten Kaffee wirst du bei mir nicht los.


Das Prob war so:
Die Browserumgebung in der FF oder IE laufen ist beidesmal Windows.

Nur wenn ich einen Server unter Windows laufen lasse und die Seite anschaue, tritt kein Fehler auf, wenn der Server unter Linux läuft, kommt der Fehler, obwohl beidesmal der gleiche php-Code ausgeführt wird.

Und auf beiden Servern ist der Dateiname mit €-Zeichen gespeichert.
Besonders rätselhaft ist hier die Übergabe der url als Javascriptvariable, die anschiessend auf Linux als utf-8 und auf windows als hex zurückgegeben wird. Der Server hat hier aber gar keinen Einfluss. Also muss der Dateipfad bereits beim readdir($bilderordner) anders ausgelesen worden sein.

=>linux-php != windows-php , was die Codierung betrifft, auch wenn's gleich aussieht.
oder linux € != windows €

€ mit Windows funktioniert. € mit linux funktioniert nicht

Im Übrigen, danke ich benutze bereits rawurlencode.

Gruss Tümmel

@Tuemmel
Du weisst aber, dass Du in der php.ini ein default Encoding setzen kannst und dieses meines Wissens nach unter Linux nicht utf-8 ist?

Grundsätzlich würde ich aber Pfade und URLs immer in reinem Ascii codiieren, egal was theoretisch geht oder nicht. Das dürfte Dir diese Probleme ersparen.

Edit: damit das Posting nicht bessewisserisch klingt: Ich habe mich mal sehr intensiv mit einer ähnlichen Frage auseinandergesetzt. Ich hatte ein Problem bei Ajax, dass IE und FF unterschiedliche Daten trotz gleichen Seiten-Encodings lieferten. Es gab einen "Best Practice" Ansatz um dieses Problem zu lösen, aber so eine richtig saubere Lösung kenne ich nicht.

Das

kann eigentlich gar nicht gehen, weil %80 kein korrekt codierter UTF-8 - Code ist.

Man kann das direkt im Firefox an eine beliebige Url anhängen und sieht, daß FF das nicht decodieren kann.

Hängt man dagegen an eine Url das

ran, dann wird gesagt: 'Url ..._€ könne nicht gefunden werden'. Sprich: Diese Zeichenfolge ist korrektes UTF-8.

Da das obige aber funktioniert, scheint die genutzte PHP-Implementierung die Ausdrücke roh zu decodieren, ist selbst wohl als ASCII codiert und reicht das ans Betriebssystem weiter. Dort - in einer 8-Bit - Codepage - ist der Klartextwert = €.

Sprich: Das

ist dann zu erwarten.

Eventuell löst die Speicherung des Scripts als UTF-8 das Problem. Aber ich mußte mich noch nie mit solchen Problemen rumschlagen.

In der Windows-1252 - Codepage (8 Bit) ist das €-Symbol Hex80 zugeordnet. In so einer Umgebung kann natürlich die korrekte UTF-8-Codierung nicht verstanden werden.

PS: Wie man sieht, hat auch die Forensoftware Probleme mit € im CODE-Element.

Das QUOTE-Element kommt damit klar.

Die einzige saubere Lösung scheint mit

$data=base64_encode('das ist 1 €').jpg

und anschliessend:

$data = str_replace(array('+','/','='),array('-','_','.'),$data);

wie bei www.php.net erwähnt

auf linux und windows zu funktionieren.

Mit urlencode und rawurlencode liefern linux und windows immer genau gegensätzliche Ergebnisse beim Abrufen.

Gruss Tümmel

Wenn Dir md5 reicht, kannst Du Dir str_replace sparen.

Witzbold, und wie willst du das dann wieder decodieren?

Egal, das war zwar ein ziemlicher Fotzlejob, ging aber schneller als ich dachte.
Ausserdem kann ich jetzt endlich eine bisschen Sonne in meinen Ordnern scheinen lassen:

ist jetzt:

Asien wartet nicht.