2024-03-08T13:01:03 GwenDragon

Klar können PHP, Perl, JSP u.ä. vielleicht auch das Encoding des Dateinamens erraten, aber das ist auch fehlerträchtig.

Fehlerträchtig vielleicht, aber pragmatisch durchaus möglich. Was sich korrekt als UTF-8 dekodieren läßt, ist mit einiger Sicherheit auch UTF-8. Für alles andere ist ISO-Latin-1 eine brauchbare Annäherung.

Ich mache ja schon lange nichts mehr mit Web, aber ich weiß noch, dass RFC2047 nicht sonderlich genau auf das Thema eingeht. Recht spezifisch für das Problem ist RFC7578 "Returning Values from Forms: multipart/form-data". Das interessante daran: Der RFC verweist darauf, dass es einen Mechanismus gibt, das Encoding von Parameter-Werten zu spezifizieren (genannt wird RFC5987, inzwischen aktualisiert zu RFC8187), der aber auf die Content-Disposition einzelner Teile nicht angewendet werden darf. Verwirrend, oder?

Mit HTML5 wurde (endlich!) eine Möglichkeit geschaffen, wie ein Browser das von ihm verwendete Encoding an einen Server schicken kann. Dazu braucht das Formular ein hidden Feld mit dem Namen _charset_, aber ohne Wert. Den soll nämlich weder der Benutzer noch das Formular, sondern der Browser einsetzen (->Standard). Ob die Browser da mitspielen und ob sie das auf Dateinamen anwenden, weiß ich nicht.

Dass man Dateinamen, die beim Webserver ankommen, mit entsprechender Vorsicht genießen muss, ist sowieso klar. Wir hatten in unseren Testsuiten gern mal einen Dateinamen mit einem Linefeed im Namen, das wirft alle möglichen Programme über ihren eigenen Haufen. Und natürlich gilt auch die Warnung von Larry Wall, man möge eine Datei nicht -rf . nennen (alles ASCII!).