Download von Dateien mit Anführungszeichen im Namen

[atarax]

Hallo!

Mit diesem Skript möchte ich Dateien herunterladen:

if (isset($_GET['download'])) {
  $file = stripslashes(basename($_SESSION['dir'].$_GET['download']));
  header("content-type: ".mime_content_type($_SESSION['dir'].$_GET['download']));
  header("content-disposition: attachment; filename=\"".$file."\"");
  readfile($_SESSION['dir'].stripslashes($_GET['download']));
  exit;
} 

Das funktioniert auch ganz gut, außer dass Dateien, die Anführungszeichen " oder ' im Namen haben, nicht richtig erkannt werden. Der Name, der im Download-Dialog angezeigt wird, wird vor dem Anführungszeichen abgeschnitten, so dass der Download auch nicht funktioniert.

Gibt es eine Möglichkeit, das Skript so zu ändern, dass es auch in diesen Fällen funktioniert?

Vielen Dank!

[AmicaNoctis]

Hallo,

generell ist das keine gute Idee, weil Dateinamen mit " sowieso problematisch sind. Wenn du aber drauf bestehst und auch in Kauf nimmst, dass der Browser es dann z. B. sowieso durch _ ersetzt, dann musst du es doppelt escapen:

header("content-disposition: attachment; filename=\"DATEINAME\\\"MIT\\\"QUOTES\""); 

Gruß,

Amica

[h3ll]

Unter Windows sind keine Dateinamen mit Anführungszeichen erlaubt.

[atarax]

Ich hab's jetzt einfach so gelöst:

if (isset($_GET['download'])) {
  $file = stripslashes(basename($_SESSION['dir'].$_GET['download']));
  header("content-type: ".mime_content_type($_SESSION['dir'].$_GET['download']));
  header("content-disposition: attachment; filename=\"".str_replace("\\'", "'", $file)."\"");
  readfile($_SESSION['dir'].stripslashes($_GET['download']));
} 

Das scheint zu klappen.

@ h3ll:

Danke, ich weiß, unter Linux sind Anführungszeichen kein Problem.

[ezkimo]

Wie kommen die Dateien denn auf den Server? Vielleicht sollte schon beim Upload der Dateiname von Sonderzeichen befreit werden. Die jetzige Lösung ist aus meiner Sicht nichts halbes und nichts ganzes.

[atarax]

Das Skript ist Teil einer browserbasierten Oberfläche zur Verwaltung von Dateien auf einem entfernten Server, ähnlich einem FTP-Client oder einem normalen Dateibrowser, nur eben per HTTP. Es soll dem Benutzer überlassen bleiben, wie er seine Dateien benennt, solange es sich im Rahmen des technisch Machbaren bewegt. Bestimmte Sonderzeichen machen gerade auf der Windows-Plattform offenbar Probleme, aber mit ein paar Tweaks lässt sich das ja regeln, z.B. mit rawurlencode(). Dateien, die auf einer Windows-Plattform erstellt wurden, dürfen ohnehin bestimmte Zeichen nicht enthalten, da dürfte es dann auch beim Up- und Download keine Probleme geben, wenn die auf einem Windows-Server landen. Anders sieht es natürlich aus, wenn Dateien beispielsweise unter Linux erstellt wurden, wo das Dateisystem nur den Slash als Sonderzeichen nicht zulässt. Wenn die dann auf einen Windows-Server hochgeladen werden sollen, muss man den Namen natürlich vorher anpassen, aber das wird in dem eigentlichen Skript überprüft. Im Moment macht mir eigentlich nur noch der Upload von Dateien mit einem Backslash im Namen Probleme, aber ich denke, das kriege ich auch noch in den Griff.

@ ezkimo: Was für ein Szenario kannst du dir denn vorstellen, wo es noch Probleme geben könnte?

[h3ll]

@ ezkimo: Was für ein Szenario kannst du dir denn vorstellen, wo es noch Probleme geben könnte?

Ältere Windows-Versionen haben noch Probleme mit verschiedenen Zeichensätzen. zB. ein deutsches Windows kann bestimmte Zeichen nicht lesen, die ein polnisches Windows problemlos verarbeitet.

[atarax]

Ich glaube, man muss hier unterscheiden, ob man über den Server oder über den Client spricht. Ich kann mir nicht vorstellen, dass es beim Upload auf einen älteren Windows-Server Probleme mit anderen Zeichen als ?:|"/\*<> gibt. Was natürlich sein kann, ist, dass beim Download auf einen Windows-98-Client bestimmte Sonderzeichen nicht dargestellt werden können, weil die Fonts auf dem Rechner die Zeichen nicht enthalten, aber dennoch sollte die Datei doch trotz der Zeichen korrekt im Dateisystem abgelegt werden können???

[h3ll]

Ich glaube, man muss hier unterscheiden, ob man über den Server oder über den Client spricht. Ich kann mir nicht vorstellen, dass es beim Upload auf einen älteren Windows-Server Probleme mit anderen Zeichen als ?:|"/\*<> gibt.

Ich kenn die Server-Versionen von Windows nicht so gut. Könnte also nur raten.

Was natürlich sein kann, ist, dass beim Download auf einen Windows-98-Client bestimmte Sonderzeichen nicht dargestellt werden können, weil die Fonts auf dem Rechner die Zeichen nicht enthalten, aber dennoch sollte die Datei doch trotz der Zeichen korrekt im Dateisystem abgelegt werden können???

Nein. Windows kann dann Dateien mit bestimmten Zeichensätzen einfach nicht öffnen, unabhängig davon welche Schriftarten installiert sind. Das Problem hatte ich früher öfter. Wobei ich jetzt nicht sagen kann, ob das von Windows selber, vom Dateisystem oder aus einer Kombination von beiden abhängig ist.

Außerdem haben unter FAT bestimmte Zeichen auch eine interne Bedeutung. zB. das Byte 0xE5 wird dafür verwendet um eine gelöschte Datei zu markieren. Würde man eine Datei mit diesem Zeichen im Namen erstellen, wäre sie praktisch automatisch gelöscht.

[atarax]

Außerdem haben unter FAT bestimmte Zeichen auch eine interne Bedeutung. zB. das Byte 0xE5 wird dafür verwendet um eine gelöschte Datei zu markieren. Würde man eine Datei mit diesem Zeichen im Namen erstellen, wäre sie praktisch automatisch gelöscht.

0xE5 ist meines Wissens å. Du meinst, wenn ich eine Datei mit einem å unter FAT erzeuge, wird diese gelöscht? Muss ich mal ausprobieren...

OK, hab's ausprobiert. Ich habe eine externe Festplatte mit FAT32. Da gibt es einen Ordner, der heißt "Sånger från 63° N". Wenn ich eine leere Datei mit dem Namen "å" anlege, wird die problemlos erzeugt...

[wahsaga]

0xE5 ist meines Wissens å.

Bytewert != Zeichen

(Zumindest nicht, ohne die verwendete Zeichenkodierung zu kennen.)

[fireweasel]

RFC 2183 - Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field

Irgendwo hab ich in den letzten drei Monaten einen Vergleich gesehen, der die unterschiedlichen Verhaltensweisen der Browser darstellt, wenn im Content-disposition-Header anders kodierte Dateinamen auftauchen. Wenn ich die Seite nur wiederfinden würde ...

Nein. Windows kann dann Dateien mit bestimmten Zeichensätzen einfach nicht öffnen, ... Das Problem hatte ich früher öfter. Wobei ich jetzt nicht sagen kann, ob das von Windows selber, vom Dateisystem oder aus einer Kombination von beiden abhängig ist.

Weder noch. Es liegt an der Anwendung, die eine veraltete Schnittstelle des Betriebssystems nutzt. Seit Windows 98 kann die(?) Windows-API mit Unicode umgehen, auch in Pfaden.

Außerdem haben unter FAT bestimmte Zeichen auch eine interne Bedeutung. zB. das Byte 0xE5 wird dafür verwendet um eine gelöschte Datei zu markieren. Würde man eine Datei mit diesem Zeichen im Namen erstellen, wäre sie praktisch automatisch gelöscht.

Ein ordentliches Betriebssystem sollte solche Eigenheiten abfangen, bevor sie im Dateisystem Schaden anrichten. FAT wäre hier das "Dateisystem"[1] -- also hat es mit der Windows-Version erstmal nicht viel zu tun. Außerdem dürfte spätestens seit VFAT (die mit den "langen" Dateinamen"), also Windows 95 keine Rolle mehr spielen, weil ab da nicht DOS-kompatible Zeichen in speziellen Bereichen kodiert wurden.

Außerdem: Wer sich auf eine FAT-formatierte Festplatte verlässt, hat keine wichtigen Daten. NTFS gibt's mindestenes seit Windows NT 3.5 und für Normal-Nutzer seit Windows 2000. Also seit ca. 10 Jahren.

Beides ist aber für den Download völlig unerheblich, weil ein normaler HTTP-Client (a.k.a. Webbrowser) einen Dateiauswahldialog anbietet, in dem man den Dateinamen im Rahmen gewisser Regeln beliebig ändern kann. Kann Windows (oder das verwendete Dateisystem) nicht mit dem Namen umgehen, erlaubt der Auswahldialog das Speichern nicht. Auf die Festplatte wird gar nicht erst zugegriffen.

--
[1] also so was ähnliches halt. In Wirklichkeit ist FAT/VFAT usw. einfach nur Schrott.

[atarax]

Na, das ist doch mal ne amtliche Quelle. Da hat mich meine Intuition doch nicht getäuscht. Ich wüsste auch nicht, wie man sich ein solches 0xE5-Byte einfangen sollte.... Ok, also meine Frage ist beantwortet. Vielen Dank an alle.

Außerdem: Wer sich auf eine FAT-formatierte Festplatte verlässt, hat keine wichtigen Daten.

So sieht's aus.

In Wirklichkeit ist FAT/VFAT usw. einfach nur Schrott.

Erfrischend ehrlich.

[h3ll]

Außerdem: Wer sich auf eine FAT-formatierte Festplatte verlässt, hat keine wichtigen Daten.

Die meistens USB-Sticks und Speicherkarten sind FAT-formatiert. Außerdem können die meisten Endgeräte kein NTFS lesen/schreiben.

[fireweasel]

Die meistens USB-Sticks und Speicherkarten sind FAT-formatiert.

Ja, aber die haben meist Kapazitäten im maximal einstelligen Gigabyte-Bereich und dienen üblicherweise nur dem Datenaustausch. Es existiert also (meistens) eine Kopie der Dateien auf irgendeiner Festplatte. Und wenn ich mich nicht irre, haben (gute) Flash-Speicher außerdem eine eingebaute Fehlerkorrektur. Herkömmliche Festplatten haben sowas nicht.

Außerdem können die meisten Endgeräte kein NTFS lesen/schreiben.

Welche Endgeräte? Falls du DigiCams, MP3-Player und so'n Kram mit schwachbrüstigen Prozessoren und schwachsinnig programmierten Betriebssystemen meinst: Auf die wird eher selten jemand eine Datei per Browser-Download speichern. Hoffe ich zumindest mal ...