Unterschied zwischen Schrägstrich (/) und Schrägstrich (\) im Dateipfad


152

Ich habe mich über den Unterschied zwischen \und /in Dateipfaden gewundert. Mir ist aufgefallen, dass manchmal ein Pfad enthält /und manchmal mit \.

Es wäre toll , wenn jemand erklären kann , wenn verwenden \und /.


4
Unterschied in welchem ​​Kontext? Ein Webby-Kontext? In C # -Strings entkommen? Es ist mit ASP.NET gekennzeichnet.
Peter Mortensen


6
@Peter Ich würde den älteren als Betrüger schließen, da dies bessere Antworten hat.
Nicael

6
Wie hängen c # und asp.net mit der Frage zusammen?
Oriol

2
@zzzzBov warum wurde dieser nicht einfach auf den älteren umgeleitet und die besseren Antworten dort platziert? Ich mag kein System, in dem eine Frage, die ich stelle, in ferner Zukunft als "Duplikat" von etwas geschlossen werden könnte, das später passiert ist. Nennen Sie es zumindest etwas Beschreibenderes, wie "ersetzt" anstatt zu duplizieren. Das ursprüngliche "Eins" kann kein Duplikat von irgendetwas sein, es ist das einzige.

Antworten:


247

/ist das Pfadtrennzeichen auf Unix- und Unix-ähnlichen Systemen. Moderne Windows können im Allgemeinen sowohl \als auch verwenden/ austauschbar für Dateipfade verwenden, aber Microsoft befürwortet \seit Jahrzehnten die Verwendung als Pfadtrennzeichen .

Dies geschieht aus historischen Gründen, die bis in die 1970er Jahre zurückreichen und mehr als ein Jahrzehnt vor Windows liegen. Am Anfang unterstützte MS-DOS (die Grundlage für frühes Windows) keine Verzeichnisse. Unix hatte von /Anfang an Verzeichnisunterstützung mit dem Zeichen. Als jedoch Verzeichnisse in MS-DOS 2.0 hinzugefügt wurden, verwendeten Microsoft und IBM das /Zeichen bereits für Befehlsschalter , und aufgrund des leichten Parsers von DOS (der von QDOS abstammt und für die Ausführung auf Hardware der unteren Preisklasse ausgelegt ist) konnten sie keine finden Machbare Möglichkeit, den /Charakter zu verwenden, ohne die Kompatibilität mit den vorhandenen Anwendungen zu beeinträchtigen.

Um Fehler beim "Überspringen eines Schalters" oder "ungültigen Schalter" beim Übergeben von Dateipfaden als Argumente an Befehle wie diese zu vermeiden:

cd/                        <---- no switch specified
dir folder1/folder2        <---- /folder2 is not a switch for dir

Es wurde beschlossen, \stattdessen das Zeichen zu verwenden, damit Sie diese Befehle wie folgt schreiben können

cd\
dir folder1\folder2

ohne Fehler.

Später arbeiteten Microsoft und IBM an einem Betriebssystem zusammen, das nicht mit DOS zusammenhängt und OS / 2 heißt . OS / 2 konnte beide Trennzeichen verwenden, um wahrscheinlich mehr Unix-Entwickler anzulocken. Als sich Microsoft und IBM 1990 trennten , nahm Microsoft den Code, den sie hatten, und erstellte Windows NT , auf dem alle modernen Windows-Versionen basieren, mit diesem Trennzeichen-Agnostizismus.


Da die Abwärtskompatibilität für Microsoft bei allen wichtigen Betriebssystemübergängen (DOS zu Win16 / DOS, zu Win16 / Win32, zu Win32 / WinNT) das A und O war, blieb diese Besonderheit wahrscheinlich bestehen existieren schon eine Weile.

Aus diesem Grund besteht diese Diskrepanz. Es sollte wirklich keine Auswirkung auf das haben, was Sie tun, da WinAPI sie, wie gesagt, im Allgemeinen austauschbar verwenden kann. Anwendungen von Drittanbietern werden jedoch wahrscheinlich unterbrochen, wenn Sie eine übergeben, /wenn sie einen \zwischen Verzeichnisnamen erwarten . Wenn Sie Windows verwenden, bleiben Sie bei \. Wenn Sie Unix oder URIs verwenden (die ihre Grundlage in Unix-Pfaden haben, aber das ist eine ganz andere Geschichte), verwenden Sie /.


Im Zusammenhang mit C #: Es sollte beachtet werden, da dies ist technisch gesehen eine C # Frage, dass , wenn Sie wollen mehr „tragbar“ C # -Code zu schreiben , dass die Arbeiten sowohl auf Unix und Windows (auch wenn C # überwiegend eine Windows - Sprache ist), Sie Möglicherweise möchten Sie das Path.DirectorySeparatorCharFeld verwenden, damit Ihr Code das bevorzugte Trennzeichen auf diesem System verwendet und Path.Combine()Pfade ordnungsgemäß anfügt.


57
Und kombinieren Sie Pfade immer mit Path.Combine.
Cheng Chen

1
Interessant. Unter DOS oder Windows kann foo.exe /bardies als Befehlszeilenschalter interpretiert werden, während es sich foo.exe \barmöglicherweise auf eine Datei / einen Ordner bezieht, die / barder sich im Stammverzeichnis \des aktuellen "Laufwerks" befindet, wie C:\zum Beispiel.
Jeppe Stig Nielsen

4
Es sollte beachtet werden, dass diese Normalisierung von /bis \ in der Win32-kompatiblen Schicht erfolgt, was bedeutet, dass es einen Unterschied gibt, wenn Sie sie umgehen. Das bekannteste Beispiel hierfür sind Pfade mit erweiterter Länge: \\?\C:\ Funktioniert unter NTFS wie erwartet, jedoch \\?\C:/nicht.
Voo

4
@PC Luddite: Dass WinAPI sowohl mit /als auch ` is not entirely true. For network path you have to use `(z. B. \\ <Servername> Bot nicht // <Servername>)
umgehen kann

2
@raznagul Richtig. Ich habe in meiner Antwort Netzwerkpfade nicht wirklich erwähnt. Ich habe mich hauptsächlich an den gängigen Dateipfadtyp gehalten. Ich werde das hinzufügen.
PC Luddite

20

MS-DOS 1.0 die Zeichenkonvention für Befehlszeilenoptionen (oder Schalter) von '/' von CP / M beibehalten. Zu diesem Zeitpunkt gab es keine Verzeichnisstruktur im Dateisystem und keinen Konflikt.

Als Microsoft die Unix-ähnliche Umgebung mit MS-DOS (und PC-DOS) 2.0 entwickelte, mussten sie das Pfadtrennzeichen mit etwas darstellen, das nicht mit den vorhandenen Befehlszeilenoptionen in Konflikt stand. Intern funktioniert das System mit '/' oder '\' gleich gut. Der Befehlsprozessor (und viele Anwendungen) verwendeten weiterhin das '/' als Schaltzeichen.

Ein CONFIG.SYSEintrag SWITCHAR=-könnte verwendet werden, um das zu überschreiben/ Standardeinstellung zu und die Unix-Kompatibilität zu verbessern. Dadurch verwenden integrierte Befehle und Standarddienstprogramme das alternative Zeichen. Das Unix-Pfadtrennzeichen könnte dann eindeutig für Datei- und Verzeichnisnamen verwendet werden. Dieser Eintrag wurde in späteren Versionen entfernt, aber ein DOS-Aufruf wurde dokumentiert, um den Wert nach dem Booten festzulegen.

Dies wurde wenig genutzt und die meisten Tools von Drittanbietern blieben unverändert. Die Verwirrung bleibt bestehen. Viele Ports von Unix-Tools behalten den Schaltercharakter '-' bei, während einige beide Konventionen unterstützen.

Der nachfolgende PowerShell-Befehlsprozessor implementiert strenge Escape- und Switch-Parameter und vermeidet die Verwirrung weitgehend, außer wenn ältere Tools verwendet werden.

Weder die Frage noch die Antwort beziehen sich auf C #.


2
Historisch gesehen geht die Verwendung /eines Optionseinführers in verschiedenen PDP-11-Betriebssystemen wie RSTS (1970) und RSX (1972) der in CP / M (1973) voraus.
PJTraill

9

Auf Unix-basierten Systemen \ist ein Escape-Zeichen, das \dem Parser mitteilt, dass dies ein Leerzeichen und nicht das Ende der Anweisung ist. Auf Unix-Systemen/ ist das Verzeichnistrennzeichen.

Unter Windows \ist das Verzeichnistrennzeichen, das /jedoch nicht in Datei- oder Verzeichnisnamen verwendet werden kann.


1
\ und /(sowie mehrere andere Symbole) können nicht in Dateinamen verwendet werden, da DOS nicht den gleichen komplexen Parser hatte, den Unix-Benutzer so gewohnt sind. Das Fehlen eines guten Parsers war das Ergebnis einer Abstammung von MS-DOS von QDOS ("Quick and Dirty Operating System"). Es sollte die Dinge schnell und auf begrenzter Hardware zum Laufen bringen. All dies existiert natürlich noch heute aus Gründen der Abwärtskompatibilität.
PC Luddite

2
Nun, erwähnenswert, dass in späteren Windows-Versionen das /als "Alternate_Directory_Separator" hinzugefügt wurde
Tomer W

@PCLuddite Vielleicht sollten wir stattdessen an Vorwärtskompatibilität denken?

1
@nocomprende Was ist mit Dateipfaden, die nicht kompatibel sind? Inkompatibel mit was? Und wie ich bereits sagte, war es für die Verbraucher zu dieser Zeit sehr wichtig, "ein paar DOS-Apps" (die eigentlich eher Tausenden ähnelten) vor dem Brechen zu bewahren. Dies hat Microsoft heute erfolgreich gemacht und Unix (und alle anderen wirklich) sind rückläufig (auch wenn es im letzten Jahrzehnt eine Wiederbelebung gegeben hat). Ich verstehe nicht, wie das nicht mit gesundem Menschenverstand betrachtet wird.
PC Luddite

1
@nocomprende Und Ihr Argument, dass Dateipfade nicht standardisiert werden, ist völlig ungültig. Sie sind unter Windows und unter Unix standardisiert. Wenn Sie von einem plattformübergreifenden Standard sprechen, ist dieser nicht wirklich nützlich oder einfach zu implementieren. Wer soll sagen, dass ein Standard wirklich "besser" ist als ein anderer?
PC Luddite

8
  • Eine in RFC 1738 standardisierte URL verwendet unabhängig von der Plattform immer Schrägstriche.
  • Ein Dateipfad und ein URI sind unterschiedlich. \ist in einem Windows-Dateipfad /korrekt und in einem URI korrekt.
  • Mehrere Browser (Firefox & Opera) versagen katastrophal, wenn URIs mit Backslashes auftreten.
  • System.IO.Path.DirectorySeparatorChar, um das aktuelle Pfadtrennzeichen abzurufen

Dies kann eine relevante Ressource sein.


10
Katastrophal scheitern? Firefox übersetzt , \​​um /automatisch. In meinem Buch heißt das "funktioniert nahtlos".
Kroltan

22
Mein Haus brannte, als ich das letzte Mal \ in Firefox benutzte
user3163495

1
@CarstenS, Firefox konvertiert Backslash nicht automatisch in Forward Slash in URL und öffnet den Link nicht. Dieses Add-On korrigiert die URL mit Backslash und geöffneter Seite. addons.mozilla.org/en-US/seamonkey/addon/…
Sami

Was genau meinst du mit "katastrophal scheitern"? Was geschieht? Stürzt der Browser ab und wird beendet?
Peter Mortensen

7

Neben den gegebenen Antworten ist zu erwähnen, dass diese \häufig für Sonderzeichen (z. B. \n \t) in Programmiersprachen, Texteditoren und allgemeinen Systemen verwendet werden, die lexikalische Analysen anwenden.

Wenn Sie beispielsweise programmieren, ist es manchmal unpraktisch, sogar einen Backslash mit einem anderen ( \\) zu umgehen, um ihn ordnungsgemäß zu verwenden - oder Escape- Zeichenfolgen wie C # zu verwenden @"\test".

Wie bereits erwähnt, verwenden Web-URIs standardmäßig Schrägstriche Beide Schrägstriche funktionieren jedoch in den neuesten und gebräuchlichsten Befehlszeilentools.

UPDATE: Nach einigem Suchen scheint die ganze Geschichte zwischen /und \in der "Computergeschichte", im Zeitalter von DOS und den Unix-basierten Systemen zu dieser Zeit, zurück zu gehen. HowToGeek hat einen interessanten Artikel über diese Geschichte.

Kurz gesagt, DOS 1.0 wurde ursprünglich von IBM ohne Verzeichnisunterstützung veröffentlicht und /für eine andere ("Switching") Befehlsfunktionalität verwendet. Als Verzeichnisse in der Version 2.0 eingeführt wurden, /wurde sie bereits verwendet, sodass IBM das visuell am nächsten liegende Symbol auswählte \. Auf der anderen Seite wird Unix standardmäßig /für Verzeichnisse verwendet.

Als Benutzer anfingen, viele verschiedene Systeme zu verwenden, wurden sie verwirrt und veranlassten die Betriebssystementwickler, in beiden Fällen zu versuchen, die Systeme zum Laufen zu bringen. Dies gilt sogar für URLs, da einige Browser den http: \\ www.test unterstützen. com \ go Format. Dies hatte zwar im Allgemeinen Nachteile, aber das Ganze steht heute noch aus Gründen der Abwärtskompartibilität, mit dem Versuch, beide Schrägstriche unter Windows zu unterstützen, obwohl sie nicht mehr auf DOS basieren.


"Beide Schrägstriche funktionieren in Dateisystempfaden." ist falsch, weil Unix ziemlich wütend ist, wenn Sie ` as well as many make`-Shells verwenden ... Sie haben Recht, dass Windows kürzlich die Umgebungsvariable ALTERNATE_PATH_SEPARATOR definiert hat, die standardmäßig verwendet wird, sodass /Windows wahrscheinlich beide akzeptieren kann.
Tomer W

1
@TomerW Windows NT war schon immer POSIX-kompatibel (obwohl frühes POSIX ohnehin ein Chaos war und einige davon aus Gründen der Abwärtskompatibilität in Windows steckten). Dazu gehörte die Unterstützung von /Pfaden überall im System - natürlich konnten Anwendungen diese Pfade nach Belieben missverstehen, sodass sie nicht zu häufig verwendet wurden. Nicht-CLI-Anwendungen, die nicht versucht haben, ihre eigene (fehlerhafte) Validierung von Pfaden durchzuführen, funktionierten von Anfang an einwandfrei.
Luaan

@Luaan Windows hatte die Fähigkeit, viele POSIX-Funktionen zu unterstützen, aber ich würde kaum sagen, dass es "POSIX-kompatibel" war. Sicher, es gab einige POSIX-Subsysteme, die man im Laufe der Jahre verwenden konnte, aber diese waren alles andere als ideal. Windows 10 wird Ubuntu Bash jedoch später in diesem Sommer zusammen mit nativer Unterstützung für die mit Ubuntu gelieferten Linux-Tools unterstützen, sodass Sie dies möglicherweise in Zukunft argumentieren können, aber Sie können sicherlich nicht "immer" sagen.
PC Luddite

@Luaan Mit "kompatibel" meinen Sie "cygwin works".
PC Luddite

@PCLuddite Nein, es war 100% POSIX.1c-kompatibel. Das bedeutet nicht, dass alle Unix-Anwendungen darauf arbeiten - die meisten Unix-Anwendungen sind nicht POSIX-kompatibel :)
Luaan

6

Sie sollten auch nicht in C # verwenden. Sie sollten immer die PathKlasse verwenden . Diese enthält eine Methode namens Path.Combine, mit der Pfade erstellt werden können, ohne das Trennzeichen selbst anzugeben.

Anwendungsbeispiel:

string fullPath = System.IO.Path.Combine("C:", "Folder1", "Folder2", "file.txt");

5

\ wird für lokale Windows-Dateipfade und Netzwerkpfade wie folgt verwendet:

C:\Windows\Temp\ oder \\NetworkSharedDisk\Documents\Archive\

/ ist das, was von Standard-URIs wie folgt verlangt wird:

http://www.stackoverflow.com/


2
@NikhilVartak, ich habe Beispiele hinzugefügt, obwohl ich dachte, meine erste Antwort bezog sich auf alle Fragen des OP.
Ash

3
Windows erkennt auch /in Pfaden (mindestens 7).
Kenneth K.

Diese Antwort ist bei weitem nicht vollständig.
Reinierpost

Wollten Sie neben der Hauptseite "Stapelüberlauf" auch auf einige Ressourcen verlinken?
Tas

@reinierpost, meine Antwort basiert auf der Frage des OP und den zugehörigen Tags. Wie einige der anderen Antworten hier konnte ich etwas von stackoverflow.com/questions/1589930/… kopieren und hier einfügen, aber es schien übertrieben. @tas, ich wollte auf eine Stackoverflow-Seite oder einen Website-Hyperlink verlinken, um die Verwendung /in Standard-URIs zu veranschaulichen, wie ich in der Antwort angegeben habe.
Ash
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.