Biiiiiiiiiitte – benennt Dateien vernünftig! Leerzeichen sind böse! Und Doppelpunkte auch. Und erst der anführende Strich … Warum? Seht selbst.

An dieser Stelle meldet sich ein nörgelnder Choleriker zu Wort – bittend, bettelnd, flehentlich ersucht er Euch zur Wahrung der Vernunft. Hört einfach auf! Hört auf, Dateien so zu benennen, als wäret Ihr Dadaisten. Leerzeichen gehören nicht in Dateinamen. Umlaute gehören nicht in Dateinamen. Anührende Striche? Also bitte!. Bitte, im Nammen aller Menschen …

… die möglicherweise jemals mit Euren Dateien umgehen sollen, benennt Dateien mit Verstand. „20170302 Östern mit Lehrer*/-innen.jpg“ ist kein guter Dateiname – und die Slashes und das Sternchen würde Windows auch von vorne herein verbieten! Aber Windows und Linux erlauben durchaus Namen, die man guten Gewissens als beschissen kategorisieren darf – drei einfache Beispiele: super übel.txt, 2017:04:05_volldoof.txt und -fuck.txt.

Die Probleme: Stapelverarbeitung, Verarbeitung aus Skripten oder im Terminal und das Stöbern in und Teilen von Dateien.

Punkt 1: Sprechende Namen

Schlechter Name: „20170303-4022.jpg“. Guter Name: „2017-03-03_belgien_bruegge_statue-1.jpg“. Viele Menschen schreiben das Datum in den Dateinamen – diese Information steckt aber auch in den Metadaten, Windows „weiß“ selbst von wann die Datei ist. Das lohnt sich jedoch, wenn die Dateien geteilt oder beispielsweise nach Verlust wiederhergestellt werden. Unter Linux sieht das schon wieder anders aus, da gibt es zwar immer das Bearbeitungsdatum, nicht aber immer das Erstelldatum.

Sprechende Namen sorgen dafür, dass Ihr die Bilder später auch wieder finden könnt – denn wer bastelt schon in Tausende Urlaubsfotos gewissenhaft manuell Metadaten ein? Und selbst, wenn Ihr nur durch Eure Bestände stöbert: Mit sprechenden Namen seht Ihr sofort, was sich in den Dateien befindet – ohne sie in einer Vorschau öffnen zu müssen.

Punkt 2: Nichts Verrücktes

Sauer wird der Choleriker aber nicht bei mieser Semantik, sondern bei mieser Syntax – um es kurz zu machen: Leerzeichen und Doppelpunkte gehören nicht in Dateinamen und Sonderzeichen generell nicht an den Anfang. Dateinamen wie „super übel.txt“, „-fuck.txt“ oder „2017:04:05_volldoof.txt“ gehen einfach gar nicht. Problematisch werden die Namen immer dann, wenn man sie in der Kommandozeile oder über Skripte aufrufen will.

Das „super übel.txt“-Problem: Mit so einem ollen Leerzeichen muss der Dateiname immer in Anführungszeichen eingegeben werden – ansonsten würden Befehle und Skripte immer erst „super“ und dann gegebenenfalls noch „übel.txt“ ansprechen. Auch auf Umlaute solltet Ihr verzichten. Das funktioniert zwar meistens, aber es gibt immer wieder Situationen, in denen unsere exklusiven Buchstaben Probleme verursachen.

dateinamen

Leerzeichen und anführende Bindestriche – DAS GRAUEN!

Das „-fuck.txt“-Problem: Wer einen Bindestrich an den Anfang eines Dateinamens setzt, sollte sofort mit dem Linux-Kommando „sudo rm -rf“ behandelt werden. Wenn Ihr zum Beispiel die Inhalte aller Text-Dateien eines Ordners in eine einzige Datei schreiben wollt, würde das Kommando „cat *.txt > zieldatei.txt“ lauten. cat würde nacheinander jede einzelne Datei verarbeiten. Und wenn dann -fuck.txt an der Reihe ist, würde der Befehl also lauten: cat -fuck.txt Seht Ihr das Problem? Mit dem Bindestrich werden Optionen übergeben – und in diesem Fall käme die Fehlermeldung, dass „-f“ keine Bekannte cat-Option ist. Aber auch alle anderen Programme würden in dieser Konstellation eine Option vermuten. Auch hier gibt es wieder die Möglichkeit, das Ganze abzufangen, über den Pfad: cat ./*.txt ist die saubere Variante und sie funktioniert. (Ob das in jeder Situation mit jedem Programm funktioniert, sei mal dahingestellt.)

Das „2017:04:05_volldoof.txt“-Problem: Auf einem hiesigen Linux wurden einst Screenshots gemacht und in die Dropbox geladen – sie kamen aber in der Windows-Dropbox nie an. Online waren sie vorhanden. Warum? Windows kann mit den Doppelpunkten nicht umgehen … Doppelpunkte sind also unter Linux legitim, aber es ist völlig gaga, sowas in das Namensschema eines Screenshot-Tools zu bauen.

Das sind jetzt nur drei Beispiele für miese Namen, es gibt etliche weitere. Im Explorer habt Ihr solche Probleme in der Regel nicht, aber im Terminal oder wenn Skripte oder Programme Dateien verarbeiten sollen – es kann Euch jederzeit treffen, auch wenn Ihr weder Linux noch Skripte nutzt!

Gute Namen

Am besten legt Ihr Euch irgendein Muster für Dateien zurecht. Hier mal ein Kann-Euch-auch-treffen-Beispiel: Wenn Ihr zum Beispiel einen Haufen Serien in einem Mediacenter wie Kodi verwaltet, wollt Ihr diese auch scrapern lassen, sie also mit Informationen und schicken Cover-Bildern bestücken. Dazu guckt sich der Scraper den Dateinamen an. Für Scraper schlecht: „DSN_-ST06_Epi_01-_Dt-Engl.avi“ – findet Kodi nicht. Für Scraper gut: „Deep-Space-Nine_S06E01.avi“ – Kodi findet es.

Das ist auch gleich ein schönes Muster: Namen mit Bindestrichen und weitere Dateinamensteile mit Unterstrichen verbinden – etwa „HDR-Testreihe_Koeln-Deutz_Canon-EOS-600_Motiv-123.jpg“.

dateinamen

Mit einem halbwegs einheitlichen Muster wird das Finden deutlich einfacher.

Wenn Ihr Dateien für immer und ewig ausschließlich selbst und ausschließlich auf dem Ursprungssystem und ausschließlich manuell im Explorer verarbeitet – herrgottnochmal, macht doch was Ihr wollt. Wenn aber auch nur die geringste Chance besteht, dass jemals jemand anderes eine der Dateien bekommt, sie auf einem anderen System landen oder von einem Programm, einer App, einem Skript aufgerufen werden, dann lasst in Eurem eigenen Sinne bitte etwas Verstand walten. Besonders übel: Eine einzige mies benannte Datei kann dafür sorgen, dass Skripte ganze Ordner nicht verarbeiten können, weil sie mit einer Fehlermeldung aussteigen!

Das erhöht übrigens auch die Chance, nicht irgendwann von einem cholerischen Admin mit einer 20-Kilo-IBM-Tastatur aus den 80ern erschlagen zu werden.

Übrigens: Boris hat hier einen super Tipp ausgegraben, wie man beim Umbenennen mehrerer Dateien unter Windows viel Zeit spart. Oder soll es gleich eine große Menge verarbeitet werden? Oder lieber im Linux-Terminal?

Über den Autor

Mirco Lang

Mirco Lang

Freier Journalist, Exil-Sauerländer, (ziemlich alter) Skateboarder, Dipl.-Inf.-Wirt, Einzelhandelskaufmann, Open-Source-Nerd, Stichwortschreiber. Ex-Saturn'ler, Ex-Data-Becker'ler, Ex-BSI'ler.

Computer-Erstkontakt: ca. 1982 - der C64 des großen Bruders eines Freunds.

Wenn ich Dir helfen konnte und/oder Du hier mehr über Open Source, Linux, Bastelkram oder auch Windows-Basics lesen möchtest:
Spendier mir einen Kaffee via Paypal.

Kommentieren:

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

12 Kommentare

    • Ob Du’s glaubst oder nicht – das gilt alles auch für Apple-Quatsch. Nur erwähne ich den Käse gar nicht erst – Euereins hört ja eh nicht. Zudem: Wie gesagt, wenn’s für immer und ewig nur und auschließlich auf Deinem System bleibt, OK. Aber manchmal schickst Du auch zum Beispiel mir Dateien – ich freue mich ja alleine schon immer über diese behämmerten Apple-Ordner, die offenbar bei jeder fucking Datei mitgeliefert werden …

  • Alle, die in einem vernünftigen Terminal operieren, können sich Dateinamen durch Drücken der tab-Taste vervollständigen lassen, egal wie häufig da %20 drinsteht.
    Wohingegen der Unterstrich einen vielleicht gewichtigeren Nachteil hat: Die Suchfunktionen vieler Computersysteme finden Dateien nicht, wenn man nach einem Wort mit vorangestelltem Unterstrich sucht.
    „2019_Hiddensee.jpg“ findet das System nicht, wenn man nach „Hiddensee“ sucht. Und das ist ziemlich mies.

    • Ach ja, und man weiß ja, wenn eine Datei für die Veröffentlichung auf einer Website gedacht ist. Da macht mans dann anders. Aber auf dem eigenen Rechner oder in ner Dropbox, wo ich noch andere Leute mit meinem Dateinamen beglücke, gibts einfach keinen Nachteil von Leerzeichen, dafür aber den o.g. Nachteil.

      • Eben – weiß ich heute, ob ich die Datei vielleicht morgen in eine Website einbauen will? Oder jemand anderes? Nein. Ein Grund, warum es in meinen Dateien auch – fast – nie Grauseligkeiten wie Umlaute gibt. Eine Datei umbenennen zu müssen, nur um sie woanders hin zu kopieren, spricht aus meiner Sicht für einen miesen Dateinamen.

    • Im Terminal bei einzelnen Dateien ist das mit Tab natürlich kein riesiges Problem – aber bei der Verarbeitung durch Skripte schon. Eigentlich bei jeder Art von Bearbeitung, bei der es eben nicht um diese eine Datei, sondern um ganz viele, wie auch immer gefilterte Dateien geht. Klar lassen sich Lösungswege finden, beispielsweise mit Anführungszeichen oder escapen, aber das macht es doch nur unnötig kompliziert. Wenn ich zum Beispiel per Skript Dateien anderer Nutzer verarbeiten soll/muss, bekomme ich derlei Konflikte im schlimmsten Fall gar nicht mit – weil das Skript vielleicht nicht darauf gemünzt ist. Klar ist dann auch das Skript nicht der Hit, aber ein schlechtes Skript rechtfertigt keine möglicherweise problematischen Dateinamen.

      Wer Dateien nur manuell und einzeln verarbeitet und sie nur mit Menschen teilt, die das auch so handhaben, und am besten noch alle auf dem gleichen Betriebssystem, und das auch niemals niemals niemals anders sein wird – tja, dann spielt es im Grunde überhaupt keine Rolle, was in Dateinamen vorkommt.

      Es tut niemandem weh, auf Leerzeichen und Doppelpunkte und dergleichen zu verzichten – aber es kann für andere Nutzer oder zukünftige Anwendungen enorm hilfreich sein. Insofern bleibe ich bei der Empfehlung, auf Leerzeichen zu verzichten.

      Das mit dem Unterstrich fände ich auch doof – allerdings wäre mir das neu. Gerade mein Windows-7-Startmenü angeworfen und nach Ubuntu gesucht und auch foo_ubuntu_bar.jpg wird gefunden – oder habe ich Dich da falsch verstanden?

      Suchergebnisse unter Win 7

      • Was das Suchproblem angeht, hast Du mich richtig verstanden. Das Problem existiert bloß nicht auf allen Betriebsystemen und Plattformen. In OS X find ich die Sachen auch. Aber irgendwo hab ich das Problem. Wenns nur bei Google Drive ist, oder so, dann ist es vielleicht zu spezifisch und nicht der Rede wert.
        Ich versuche bisher immer Leute, mit denen ich Workflows teile, zu Leerzeichen in Dateinamen zu erziehen. Einfacher zu tippen, schöner zu lesen, und im Zweifelsfall besser suchbar. In Dropbox-URLs nervts auch nicht. Und bevor ich Dir einen Ordner voller Dateien übergebe, lass ich einfach den Befehl

        rn *<em>%20</em>.* *<em>_</em>.*
        

        drüberlaufen. Deal?
        :-)

      • Freilich! Das ist der rename-Terminalbefehl unter Unix/Linux/MacOS.
        Aber Deine Kommentarfunktion hat mir bei Ausgangsdateiname und Zieldateiname jeweils nen Asterisk am Anfang weggekürzt

      • Die Asterike habe ich korrigiert – WordPress und Code ist ein Grrrraus …

        Gerade unter Ubuntu, Debian und OpenSuse probiert: Nirgends ein rn, auch nicht in den Paketquellen. Vielleicht nur Unix/MacOS? Oder ein vergessener Alias für das Tool „rename“? In Archiven kann man mit zum Beispiel „winrar rn“ umbenennen, wenn ich mich recht entsinne. Und Google zeigt mir auf Anhieb auch nichts zu rn an.

      • Ach ja, gewiss, der richtige Befehl ist mv. Weil Bewegen und Umbenennen ja so ziemlich derselbe Vorgang sind.
        Ich habe mich vertan 🎶

  • Ich hatte immer Probleme mit Anführungszeichen, Windows verweigert das Speichern solcher Namen bei Umbenennung. Jetzt habe Ich mit einem Programm eine Datei gespeichert, und die enthielt Anführungszeichen. Ich dachte das ganze Dateisystem etc. macht diese Zeichen unmöglich, aber scheinbar ist es nur Windows oder der Datei Explorer?
    Wenn Ich die Datei zum „umbenennen“ anklicke, kann ich sie gleich wieder mit Enter so belassen.
    Wenn Ich dann versuche ein weiteres Anführungszeichen einzusetzen, kommt die Meldung welche Zeichen nicht gehen. Was drin ist, bleibt also drin.

    Warum darf man unter Windows diese Zeichen nicht verwenden, obwohl sie in Dateinamen enthalten sein können?:
    /, \, :, *, „, <, >, |

    Jetzt habe Ich es nochmal versucht, aber es geht nicht mehr.
    Keine Ahnung wie Ich das gemacht hatte. Ich meine als Ich das Bild abspeicherte.
    Jetzt geht das nicht mehr…