Frage zum Wiki-Artikel „Konventionen für Dateinamen“

[simsus]

Moin Moin

Im Abschnitt "Dateinamen im Hinblick auf Kompatibilität" steht:

Vermeiden Sie aber nach Möglichkeit deutsche Umlaute und ß in den Dateinamen.

Wieso entspricht nicht die Adresse der Empfehlung?
HTML/Regeln/Konventionen für Dateinamen
😉

Gruss
Marcel

[Julius]

Hallo simsus,

Wieso entspricht nicht die Adresse der Empfehlung?
HTML/Regeln/Konventionen für Dateinamen

Weil das eine URL ist :-) MediaWiki speichert die Inhalte mittels MySQL und das kann Unicode.
(Ich kann weder ein ß noch einen umlaut in der URL finden, ich denke mal, du beziehst dich auf das Leerzeichen.)

Dank URL-Kodierung ist das nicht mehr sooo ein Problem. Für ein internationales, nicht-deutschsprachiges Publikum und zum Abtippen bestimmte URLs setze ich persönlich allerdings lieber auf den alphanummerische-Zeichen im Umfang von ASCII minus Großbuchstaben.

Gruß
Julius

[Regina Schlauklug]

Konventionen_für_Dateinamen

[Julius]

Hallo Regina,

Konventionen_für_Dateinamen

Äh *erfolglos nach Ausreden kram* Ja, stimmt.

Gruß
Julius

[Tabellenkalk]

Hallo,

(Ich kann weder ein ß noch einen umlaut in der URL finden, ich denke mal, du beziehst dich auf das Leerzeichen.)

Üb mal mit Fs

Gruß
Kalk

[Julius]

Hallo Tabellenkalk,

(Ich kann weder ein ß noch einen umlaut in der URL finden, ich denke mal, du beziehst dich auf das Leerzeichen.)

Üb mal mit Fs

Bin auch drauf rein gefallen...

Ebenfalls eine beliebte Täuschung: https://www.youtube.com/watch?v=vJG698U2Mvo

Gruß
Julius

[kackb00n]

Also ich zahle keine Fs SCNR

Bin auf 5 gekommen (ja ich hab das OF auch überlesen >.<)

[Matthias Scharwies]

Servus!

Wieso entspricht nicht die Adresse der Empfehlung?
HTML/Regeln/Konventionen für Dateinamen

Weil das eine URL ist :-)

Dank URL-Kodierung ist das nicht mehr sooo ein Problem. Für ein internationales, nicht-deutschsprachiges Publikum und zum Abtippen bestimmte URLs setze ich persönlich allerdings lieber auf den alphanummerische-Zeichen im Umfang von ASCII minus Großbuchstaben.

Ich habe deine Antwort mal ins Wiki aufgenommen:

• HTML/Regeln/Konventionen_f%C3%BCr_Dateinamen#Dateinamen_im_Hinblick_auf_Kompatibilität

Herzliche Grüße

Matthias Scharwies

[TS]

Hello,

Ich habe deine Antwort mal ins Wiki aufgenommen:

• HTML/Regeln/Konventionen_f%C3%BCr_Dateinamen#Dateinamen_im_Hinblick_auf_Kompatibilität

Das würde ich gerne nochmal überprüft wissen!
Wichtig ist die maximale Datei-Pfad-Länge.

Selbstverständlich habe ich selber schon gesucht, kann aber jetzt spontan keine allgemeingültigen (also für minestens Unix/Linux, MAC, WinDOS) verbindlichen Aussagen finden. Ich habe das ja alles schon einmal durchsucht für den PHP-Upload-Artikel. Wenn man die dort beschriebenen Kriterien auch noch berücksichtigt, bleibt es nicht bei "erlaubten Zeichen", sondern es kommen auch nich unerlaubte Zeichenfolgen hinzu!

MMn dürfen Dateinamen nur bis zu 254 Bytes Länge beanspruchen. Das erste Byte enthält die genutzte Länge in Bytes, das letzte ist aus Kompatibilitätsgründen trotzdem noch eine NUL (Nul-terminated String). Da meistens gilt Zeichen ≠ Bytebedarf, können die Namen also in der maximalen Zeichenzahl stark differieren.

Unter Berücksichtigung der Interoperabilität zwischen den diversen Systemen (auch Anwendungen) möchte ich aber dringend empfehlen, nur druckbare Zeichen auch dem ASCII(-7-Bit-)Bereich zu wählen, ohne Sonderzeichen der Shells der wichtigsten Betriebssysteme.

Liebe Grüße
Tom S.

[TS]

Hello,

Ergänzung zum bereits Erwähnten:

Wikipedia

NTFS scheint also per Default 256 Bytes für jeden Namen zur Verfügung zu stellen. Das Datenfeld wird mit NUL initialisiert. Bei Auftreffen auf eine NUL ist der Name ein Byte vorher zuende.

Ob EXT3 nun ein Längenbyte benutzt, oder auch eine terminating NUL, konnte ich noch nicht feststellen. Da müsste man in die untersten Schichten reinschauen, was ich immer schon mal tun wollte ;-O

Wichtig ist immer noch, wie groß die maximale Pfadlänge im OS und im jeweiligen Dateisystem ist. Der Environment-Block muss den Pfad unterbringen können.

Liebe Grüße
Tom S.

[TS]

Hello,

Es ist immer noch nichts Offizielles, aber die Kreise werden enger:

lange Dateinamen: Dateinamen können im Gegensatz zu FAT16 auch nativ (ohne VFAT) bis zu 255 Zeichen lang sein und aus fast beliebigen Unicode-Zeichen bestehen. NTFS unterscheidet zwischen Groß- und Kleinschreibung; dies wird zwar von Win32-Anwendungen nicht unterstützt, POSIX-Anwendungen können aber auch Dateien, die sich ausschließlich in der Groß- und Kleinschreibung unterscheiden, korrekt verwalten.[10]

Zitat aus der Wikipedia zum Thema NTFS

Es wäre schön, wenn wir tatsächlich ins Eingemachte gucken könnten, bevor wir mainstreammäßig falsche Informationen verbreiten. ;-)
Jetzt sag bitte nicht "mach"; ich wusste bei DOS noch, wo man gucken muss, für Windows, Linux und die neuen Dateisysteme fehlen mir (nicht nur) die Sourcen.

Letzte Meldung:

Wie mir ein Freund eben mailte, hat Windows 10 gravierende Probleme mit Groß-/Kleinschreibung von Dateinamen (NTFS kann ja beides). Die haben da wohl eine halbfertige Idee im OS (nicht im Filesystem) freigelassen. Es kann unter bestimmten Umständen passieren, dass man die Dateien in unterschiedlichen Schreibweisen auf der Platte hat und dann aber an eine von den beiden mit den normelen Werkzeugen nicht mehr herankommt.

So einen Fehler hatte das gute alte DOS auch schon mal. Da kam man dann nur per FCB-Zugriff an die Dateien heran, nicht aber mit den Handle-Methoden.

Könnte hiermit zu tun haben.

Liebe Grüße
Tom S.

[Rolf b]

Also prinzipiell kann eine Pfadangabe unter NTFS bis ca 32k UTF16-Zeichen lang sein, aber bis vor kurzem war das Windows API an vielen Stellen auf 260 Zeichen limitiert (MAX_PATH Angabe im SDK). Viele der "Classic" API Funktionen haben ein Unicode-Gegenstück, in dem die Begrenzung schon länger nicht gilt.

Um lange Pfade zu nutzen, muss man aber bekanntgeben, dass man weiß was man tut. Deswegen gibt es ein opt-in Verfahren: Man muss dem Pfad ein UNC-Präfix voranstellen: \\?\.

Unter Win10 1607 hat sich das geändert, das API wurde erweitert, aber wie es der Kompatibilitätsteufel so will, muss Microsoft auf die Alt-Anwendungen achten die nicht umgestellt sind.

Unter Windows 10 sind auch viele Funktionen des "klassischen" API auf 32K Pfade erweitert worden, aber auch dafür muss man sich bereiterklären. Entweder zentral über einen Registry Eintrag, oder über ein Application Manifest.

So weit ich weiß, ist aber jeder einzelne Namensteil immer noch auf 255 Zeichen begrenzt (was man im Zweifelsfall per GetVolumeInformation abfragen kann).

Quelle

Rolf

[Julius]

Hallo Tom,

MMn dürfen Dateinamen nur bis zu 254 Bytes Länge beanspruchen.

Manchmal sind es auch Zeichen. Beispielsweise bei Dateisystemen, die die Dateinamen mittels UTF-16 speichern.

Gruß
Julius

[Camping_RIDER]

Aloha ;)

• HTML/Regeln/Konventionen_f%C3%BCr_Dateinamen#Dateinamen_im_Hinblick_auf_Kompatibilität

„Auch auf Leerzeichen sollten Sie unbedingt verzichten. (Diese werden z.B. von der Mediawiki-Software in Unterstriche umgewandelt.)“

Das funktioniert auch andersrum. Verwende einen Unterstrich und MediaWiki macht dir ein Leerzeichen draus. Der Camping_RIDER muss es wissen.

Ich hatte damit in der Vergangenheit sogar schon Probleme beim Einloggen deshalb (MediaWiki hat mir den Benutzernamen immer falsch ins Formular eingetragen), die sind inzwischen (zum Glück) allerdings nicht mehr reproduzierbar.

Grüße,

RIDER

[TS]

Hello,

ich habe den Artikel mal auf meinen Zettel genommen. Er ist zu oberflächlich und teilweise vermutlich sogar falsch. Rolf b hat ja in diesem Thread auch schon Verbindliches beigetragen.

Liebe Grüße
Tom S.

[Matthias Scharwies]

Servus!

Hello,

ich habe den Artikel mal auf meinen Zettel genommen. Er ist zu oberflächlich und teilweise vermutlich sogar falsch. Rolf b hat ja in diesem Thread auch schon Verbindliches beigetragen.

Vielen Dank für Deine Bereitschaft. Der Artikel war irgendwann mal Teil einer Serie zur Einführung in HTML, welche Zeichen man verwenden darf und was man sonst noch beachten sollte.

Hier wäre heute imho eine Trennung in '''Einführungsabsatz''' mit grundlegenden Sachen wie Namenskonventionen und Dateiendung .html und und in '''weiterführende Kapitel''' mit mehr Informationen für Profis angebracht.

Liebe Grüße
Tom S.

Herzliche Grüße

Matthias Scharwies

[Julius]

Hallo Matthias,

ich habe den Artikel mal auf meinen Zettel genommen. Er ist zu oberflächlich und teilweise vermutlich sogar falsch. Rolf b hat ja in diesem Thread auch schon Verbindliches beigetragen.

Vielen Dank für Deine Bereitschaft. Der Artikel war irgendwann mal Teil einer Serie zur Einführung in HTML, welche Zeichen man verwenden darf und was man sonst noch beachten sollte.

Das spiegelt sich auch darin wieder, dass nicht zwischen Konventionen zu URLs und Dateipfaden unterschieden wird. – Als der Text geschrieben wurde, waren die Seiten in der Regel als Dateien im Document-Root eines Webservers abgelegt und der Webserver „übersetzte“ dann die URL aufs Dateisystem und lieferte dann die passende Datei aus. Heute wird das in der Regel durch ein CMS wie MediaWiki, WordPress oder etwas selbst Geschriebenes erledigt und denen sind Dateinamenskonventionen herzlich egal, sofern sie die Inhalte aus einer Datenbank holen.

Hier wäre heute imho eine Trennung in '''Einführungsabsatz''' mit grundlegenden Sachen wie Namenskonventionen und Dateiendung .html und und in '''weiterführende Kapitel''' mit mehr Informationen für Profis angebracht.

Genau.
So würde ich es machen: Folgendes in Bezug auf Dateinamen thematisieren und dann für weitere Informationen auf Wikipedia verlinken:

• Alle ASCII-Zeichen ohne < > ? " : | \ / * gehen immer, prinzipiell zwar auch alle Unicode-Zeichen, aber bei einem internationalen Publikum sollte man über einen Verzicht darauf nachdenken, weil nicht alle beispielsweise ein ß auf der Tastatur haben (Schweizer auch nicht!) bzw. das Zeichen überhaupt erkennen können
• Großschreibung sollte man meiden oder zumindest Groß- und Kleinschreibung konsistent handhaben, was aber letztlich komplizierter ist, als einfach alles klein zu schreiben. Verbessert Interoperabilität zwischen Windows und Unix
• Unter Windows sind außerdem folgende Dateinamen verboten: CON, PRN, AUX, NUL COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9 LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9 – eine Datei namens NUL.txt kann also unter Windows nicht existieren, sollte daher auch unter anderen Systemen vermieden werden, um die Interoperabilität zu erhöhen.
• Dateiendungen sind im Prinzip Schall und Rauch, helfen aber dem Websserver, den passenden Content-Type zu senden. Für HTML also .htm oder .html verwenden.
• Dateinamen bzw. Pfade habe eine bestimmte Maximallänge, die meist bei 255 Bytes (bei Verwendung von Nicht-ASCII entsprechend weniger Zeichen möglich) oder Zeichen liegt - so lange Dateinamen vergibt man in der Praxis nicht, die Limitierung der Länge sollte aber bekannt sein.
• Auf die Eigenschaften von URLs eingehen, bzw. auf einen passenden Artikel verlinken und ggf. erklären, dass URLs nicht zwangsläufig vom Weberver in Dateien aufgelöst werden, sondern die Inhalte auch aus einer Datenbank kommen können:
  • internationalisierte Domains (IDN) via Punycode
  • Prozent-Kodierung für reservierte Zeichen, Unicode-Zeichen müssen im Allgemeinen nicht kodiert werden – Systeme, die kein Unicode beherrschen, sind ausgestorben
  • Für optimale Kompatibilität max. 255 Zeichen, längere scheinen aber auch kein Problem zu sein, müsste man noch mal im dazugehörigen RFC nachsehen

In der Kürze liegt die Würze und das Rad neu erfinden müssen wir auch nicht...

Gruß
Julius

[TS]

Hello,

darum habe ich das im Kapitel "Schädliche Dateinamen ausschließen" des PHP-Artikels "File-Upload" schon alles thematisiert.

Der Artikel ist sowieso zu lang geraten und trotzdem immer noch nicht fertig. Wir müssten also mal überlegen, wie das "Modul Dateinanmen" eigenständig werden könnte, aber dann bitte auch vollständig bleiben muss, weil man im Artikel mandatorisch darauf verweisen müsste.

Liebe Grüße
Tom S.

[Julius]

Hallo Tom,

darum habe ich das im Kapitel "Schädliche Dateinamen ausschließen" des PHP-Artikels "File-Upload" schon alles thematisiert.

Ist mir bekannt, unter Dateinamenskonventionen sollte es aber auch vorhanden oder verlinkt sein.

Der Artikel ist sowieso zu lang geraten und trotzdem immer noch nicht fertig.

Stimme zu. Vor allem die MIME-Type-Dateiendung-Liste ist ziemlich lang. Bei einem Whitelist-Vorgehen braucht man eine solche Zuordnung nur in dem Umfang wie man auch Dateitypen hochladen können möchte – Wenn ich nur Bilder und PDFs brauche, dann brauche ich nur dafür auch Zuordnungen. Falls das nur ein Beispiel war, kann man das auch kürzen und auf eine MIME-Type-liste verlinken, beispielsweise die in der Wikipedia.

Vielleicht wäre auch eine Trennung nach Theorie und Praxis alternativ zu einzelnen Unterkapiteln denkbar.

Wir müssten also mal überlegen, wie das "Modul Dateinanmen" eigenständig werden könnte, aber dann bitte auch vollständig bleiben muss, weil man im Artikel mandatorisch darauf verweisen müsste.

Auch von der Thematik „URLs“ müsste man das sauber trennen.

Gruß
Julius

[TS]

Hello,

die MIME-Typ-Funktion sollte schon möglichst komplett bleiben. Es ist ja ein Artikel für die Praxis, und kein theoretisches Beispiel. Selbstverständlich sollte man dazuschreiben, dass man sich bei Whitelisting nur die relevanten Zeilen rausschneiden kann.

Später mehr ...

Liebe Grüße
Tom S.