Differenza tra barra (/) e barra rovesciata (\) nel percorso del file


153

Mi chiedevo la differenza tra \e /nei percorsi dei file. Ho notato che a volte un percorso contiene /ea volte è con \.

Sarebbe bello se qualcuno potesse spiegare quando usare \e /.


4
Differenza in quale contesto? Un contesto webby? Escaping in stringhe C #? È taggato con ASP.NET.
Peter Mortensen,


6
@Peter chiuderei quello più vecchio come duplo di questo, dal momento che questo ha risposte migliori.
nicael,

6
In che modo c # e asp.net sono correlati alla domanda?
Oriol,

2
@zzzzBov perché questo non è stato semplicemente reindirizzato a quello più vecchio e alle risposte migliori posizionate lì? Non mi piace un sistema in cui una domanda che posso porre potrebbe essere chiusa in un futuro lontano come un "duplicato" di qualcosa che è accaduto in seguito. Almeno chiamalo qualcosa di più descrittivo, come "sostituito" piuttosto che duplicato. "L'uno" originale non può essere un duplicato di nulla, è l'unico.

Risposte:


248

/è il separatore di percorso su sistemi Unix e Unix-like. Le moderne finestre possono generalmente utilizzare entrambi \e in modo /intercambiabile per i percorsi dei file, ma Microsoft ha sostenuto l'uso di \come separatore dei percorsi per decenni.

Questo viene fatto per ragioni storiche risalenti agli anni '70, precedenti a Windows di oltre un decennio. All'inizio, MS-DOS (la base per i primi Windows) non supportava le directory. Unix aveva il supporto di directory usando il /carattere sin dall'inizio. Tuttavia, quando le directory sono state aggiunte in MS-DOS 2.0, Microsoft e IBM stavano già utilizzando il /carattere per le opzioni di comando e, a causa del parser leggero di DOS (discendente da QDOS , progettato per funzionare su hardware di fascia bassa), non riuscivano a trovare un modo fattibile per utilizzare il /personaggio senza interrompere la compatibilità con le loro applicazioni esistenti.

Quindi, per evitare errori su "mancanza di uno switch" o "switch non valido" quando si passano percorsi di file come argomenti a comandi come questi:

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

fu deciso che il \personaggio sarebbe stato usato invece, in modo da poter scrivere quei comandi in questo modo

cd\
dir folder1\folder2

senza errori.

Successivamente, Microsoft e IBM hanno collaborato a un sistema operativo non correlato a DOS chiamato OS / 2 . OS / 2 aveva la capacità di usare entrambi i separatori, probabilmente per attirare più sviluppatori Unix. Quando Microsoft e IBM si separarono nel 1990 , Microsoft prese il codice che avevano e creò Windows NT , su cui si basano tutte le versioni moderne di Windows, portando con sé questo agnosticismo separatore.


Poiché la compatibilità con le versioni precedenti è stata il nome del gioco per Microsoft da tutte le principali transizioni del sistema operativo che hanno intrapreso (da DOS a Win16 / DOS, a Win16 / Win32, a Win32 / WinNT), questa peculiarità è rimasta bloccata e probabilmente sarà esiste già da un po '.

È per questo motivo che esiste questa discrepanza. Non dovrebbe davvero avere alcun effetto su ciò che stai facendo perché, come ho detto, WinAPI può generalmente usarli in modo intercambiabile. Tuttavia, le applicazioni di terze parti probabilmente si interrompono se si passa a /quando si aspettano una \tra i nomi di directory. Se si utilizza Windows, attenersi a \. Se stai usando Unix o URI (che hanno le loro basi nei percorsi Unix, ma questa è completamente un'altra storia), allora usa /.


Nel contesto di C #: Va notato, dal momento che questa è tecnicamente una domanda C #, che se si desidera scrivere un codice C # più "portatile" che funziona sia su Unix che su Windows (anche se C # è prevalentemente un linguaggio Windows), si potrebbe essere necessario utilizzare il Path.DirectorySeparatorCharcampo in modo che il codice utilizzi il separatore preferito su quel sistema e utilizzarlo Path.Combine()per aggiungere correttamente i percorsi.


57
E combina sempre i percorsi usando Path.Combine.
Cheng Chen,

1
Interessante. Pertanto, in DOS o Windows, foo.exe /barpotrebbe essere interpretato come un'opzione della riga di comando, mentre foo.exe \barpotrebbe essere interpretato come riferito a un file / cartella chiamato barche si trova nella directory principale \dell'attuale "unità", come C:\ad esempio.
Jeppe Stig Nielsen,

4
Va notato che questa normalizzazione da /a \ viene eseguita nel livello compatibile Win32, il che significa che se si elude, ci sarà una differenza. L'esempio più noto di questo sono i percorsi di lunghezza estesa: \\?\C:\ funzionerà come previsto su NTFS ma \\?\C:/non lo farà.
Voo,

4
@PC Luddite: che WinAPI può gestire entrambi /e ` is not entirely true. For network path you have to use `(es. \\ <nomeserver> bot non // <nomeserver>)
raznagul,

2
@raznagul True. Non ho davvero menzionato i percorsi di rete nella mia risposta. Mi sono bloccato principalmente con il tipo di filepath comune. Lo aggiungerò io.
PC Luddite,

20

MS-DOS 1.0 ha mantenuto l'opzione di riga di comando (o opzione) di carattere "/" da CP / M. A quel tempo non vi era alcuna struttura di directory nel file system e nessun conflitto.

Quando Microsoft ha sviluppato l'ambiente più simile a Unix con MS-DOS (e PC-DOS) 2.0, era necessario rappresentare il separatore di percorso utilizzando qualcosa che non fosse in conflitto con le opzioni della riga di comando esistenti. Internamente, il sistema funziona ugualmente bene con '/' o '\'. L'elaboratore di comandi (e molte applicazioni) ha continuato a utilizzare '/' come carattere switch.

È possibile utilizzare una CONFIG.SYSvoce SWITCHAR=-per sovrascrivere il /valore predefinito per migliorare la compatibilità con Unix. Questo fa sì che i comandi integrati e le utility standard utilizzino il carattere alternativo. Il separatore di percorso Unix potrebbe quindi essere utilizzato in modo inequivocabile per i nomi di file e directory. Questa voce è stata rimossa nelle versioni successive, ma è stata documentata una chiamata DOS per impostare il valore dopo l'avvio.

Questo era poco usato e la maggior parte degli strumenti di terze parti è rimasta invariata. La confusione persiste. Molte porte degli strumenti Unix mantengono il carattere "-" mentre alcuni supportano entrambe le convenzioni.

Il successivo processore di comandi PowerShell implementa rigorosi parametri di escape e switch ed evita in gran parte la confusione, tranne nel caso in cui vengano utilizzati strumenti legacy.

Né la domanda né la risposta si riferiscono a C #.


2
Come nota storica, l'uso di /come introduttore di opzioni in vari sistemi operativi PDP-11 come RSTS (1970) e RSX (1972) precede quello in CP / M (1973).
PJTraill,

9

Sui sistemi basati su Unix \è presente un carattere di escape, ovvero \indica al parser che si tratta di uno spazio e non della fine dell'istruzione. Sui sistemi Unix /è il separatore di directory.

Su Windows \è il separatore di directory, ma /non può essere utilizzato nei nomi di file o directory.


1
\ e /(così come molti altri simboli) non possono essere usati nei nomi dei file perché DOS non aveva lo stesso parser complesso a cui sono così abituati gli utenti Unix. La mancanza di un buon parser era il risultato del fatto che MS-DOS discendeva da QDOS ("Sistema operativo rapido e sporco"). Avrebbe dovuto far funzionare le cose rapidamente e su hardware limitato. Tutto ciò ovviamente esiste ancora oggi per la compatibilità con le versioni precedenti.
PC Luddite,

2
bene, vale la pena ricordare che nelle versioni successive di Windows è /stato aggiunto come "Alternate_Directory_Separator"
Tomer W

@PCLuddite forse dovremmo pensare invece alla compatibilità futura?

1
@nocomprende E i percorsi dei file sono incompatibili? Incompatibile con cosa? E come ho detto prima, salvare "alcune app DOS" (che erano davvero più simili a migliaia) dalla rottura era molto importante per i consumatori in quel momento. È ciò che ha reso Microsoft di successo oggi e Unix (e tutti gli altri in realtà) hanno iniziato il declino (anche se c'è stata una ripresa nell'ultimo decennio). Non riesco a vedere come questo non lo guardi con buon senso.
PC Luddite,

1
@nocomprende E la tua argomentazione sul non standardizzare i percorsi dei file è completamente nulla. Sono standardizzati su Windows e standardizzati su Unix. Se stai parlando di uno standard multipiattaforma, non è molto utile o facile da implementare. Chi può dire che uno standard sia davvero "migliore" di un altro?
PC Luddite,

8
  • Un URL, standardizzato in RFC 1738, utilizza sempre barre, indipendentemente dalla piattaforma.
  • Un percorso di file e un URI sono diversi. \è corretto in un percorso di file di Windows ed /è corretto in un URI.
  • Diversi browser (vale a dire Firefox e Opera) falliscono in modo catastrofico quando si incontrano URI con barre rovesciate.
  • System.IO.Path.DirectorySeparatorChar per ottenere il separatore del percorso corrente

Questa può essere una risorsa rilevante.


10
Fallire catastroficamente? Firefox si traduce \​​a /automaticamente. Nel mio libro questo si chiama "funziona perfettamente".
Kroltan,

22
la mia casa ha preso fuoco l'ultima volta che ho usato \ in Firefox
user3163495 il

1
@CarstenS, Firefox non converte la barra rovesciata in barra in avanti automaticamente nell'URL e non apre il collegamento. Questo componente aggiuntivo corregge l'URL con barra rovesciata e pagina aperta. addons.mozilla.org/en-US/seamonkey/addon/…
Sami

Cosa intendi esattamente con "fallimento catastrofico"? Che succede? Il browser si arresta in modo anomalo e si chiude?
Peter Mortensen,

7

A parte le risposte fornite, vale la pena ricordare che \è ampiamente usato per caratteri speciali (come\n \t ) in linguaggi di programmazione, editor di testo e sistemi generali che applicano l'analisi lessicale.

Se, ad esempio, stai programmando, a volte è scomodo persino dover sfuggire alla barra rovesciata con un'altra (\\ ) per usarlo correttamente - o devi usare stringhe di escape, come C # @"\test".

Ovviamente, come accennato in precedenza, gli URI Web utilizzano la barra diretta di serie ma entrambe le barre funzionano con gli strumenti più recenti e più comuni della riga di comando.

AGGIORNAMENTO: Dopo aver cercato un po ', sembra che ci sia l'intera storia /e \risale alla "storia del computer", nell'era del DOS e dei sistemi basati su Unix a quel tempo. HowToGeek ha un articolo interessante su questa storia.

In breve, DOS 1.0 è stato inizialmente rilasciato da IBM senza supporto di directory ed è /stato utilizzato per un'altra funzionalità di comando ("switching"). Quando le directory sono state introdotte nella versione 2.0, /era già in uso, quindi IBM ha scelto il simbolo visivamente più vicino, che era \. D'altra parte, Unix veniva utilizzato di norma /per le directory.

Quando gli utenti hanno iniziato a utilizzare molti sistemi diversi, hanno iniziato a confondersi, facendo in modo che gli sviluppatori del sistema operativo tentassero di far funzionare i sistemi in entrambi i casi - questo vale anche nella parte degli URL, poiché alcuni browser supportano http: \\ www.test. formato com \ go . Ciò ha avuto degli inconvenienti, sebbene in generale, ma il tutto rimane fermo per cause di comparabilità all'indietro, con un tentativo di supporto di entrambe le barre su Windows, anche se non sono più basate su DOS.


"entrambe le barre funzionano nei percorsi del file system." non è corretto, perché Unix è piuttosto arrabbiato quando usi ` as well as many make` shells ... hai ragione che Windows recente ha definito la variabile di ambiente ALTERNATE_PATH_SEPARATOR che di default è /quindi Windows può probabilmente accettare entrambi.
Tomer W,

1
@TomerW Windows NT è sempre stato compatibile con POSIX (anche se all'inizio POSIX era un disastro, e alcuni di questi erano bloccati in Windows per compatibilità con le versioni precedenti). Ciò includeva /percorsi di supporto ovunque nel sistema - ovviamente, le applicazioni potevano fraintendere quei percorsi a loro piacimento, quindi non venivano usati troppo. Le applicazioni non CLI che non hanno provato a eseguire la propria convalida (interrotta) dei percorsi hanno funzionato bene sin dall'inizio.
Luaan,

@Luaan Windows aveva la capacità di supportare molte funzionalità POSIX, ma direi a malapena che era "compatibile con POSIX". Certo, c'erano alcuni sottosistemi POSIX che si potevano usare nel corso degli anni, ma quelli erano tutt'altro che ideali. Windows 10 supporterà Ubuntu bash anche se alla fine dell'estate insieme al supporto nativo per gli strumenti Linux forniti con Ubuntu, quindi potresti essere in grado di sostenerlo in futuro, ma di certo non puoi dire "sempre".
PC Luddite,

@Luaan A meno che per "compatibile" si intende "cygwin funziona".
PC Luddite,

@PCLuddite No, era compatibile al 100% con POSIX.1c. Ciò non significa che tutte le applicazioni unix funzionino su di esso - la maggior parte delle applicazioni unix non sono conformi a POSIX :)
Luaan

6

Non dovresti usare nessuno dei due in C #. Dovresti sempre usare la Pathclasse . Questo contiene un metodo chiamato Path.Combineche può essere utilizzato per creare percorsi senza specificare il separatore.

Esempio di utilizzo:

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

5

\ viene utilizzato per percorsi di file locali di Windows e percorsi di rete come in:

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

/ è ciò che è richiesto dagli URI standard come in:

http://www.stackoverflow.com/


2
@NikhilVartak, ho aggiunto degli esempi anche se pensavo che la mia risposta iniziale fosse rivolta a tutte le domande del PO.
Ash,

3
Windows riconosce anche /nei percorsi (almeno 7 lo fa).
Kenneth K.,

Questa risposta è tutt'altro che completa.
reinierpost,

Volevi creare un collegamento ad alcune risorse, oltre alla pagina principale di Stack Overflow?
Tas,

@reinierpost, la mia risposta si basa sulla domanda del PO e sui tag associati. Come alcune delle altre risposte qui, ho potuto copiare qualcosa da stackoverflow.com/questions/1589930/… e incollarlo qui ma sembrava eccessivo. @tas, ho intenzione di collegarmi alla pagina StackOverflow o qualsiasi collegamento ipertestuale del sito Web per illustrare l'uso di /URI standard come ho affermato nella risposta.
Ash,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.