Différence entre la barre oblique (/) et la barre oblique inverse (\) dans le chemin du fichier

153

Je me demandais la différence entre \et /dans les chemins de fichiers. J'ai remarqué que parfois un chemin contient /et parfois il est avec \.

Ce serait formidable si quelqu'un pouvait expliquer quand utiliser \et /.

— Homme araignée
source

4

Différence dans quel contexte? Un contexte webby? Échappement dans les chaînes C #? Il est étiqueté avec ASP.NET.

— Peter Mortensen

9

Reproduction possible de la différence entre la barre oblique avant et la barre oblique inverse

— Peter Mortensen

6

@Peter Je fermerais l'ancien comme dupe de cela, car cela a de meilleures réponses.

— nicael

6

Comment c # et asp.net sont-ils liés à la question?

— Oriol

2

@zzzzBov pourquoi celui-ci n'a-t-il pas été simplement redirigé vers l'ancien et les meilleures réponses placées là-bas? Je n'aime pas un système où une question que je pose pourrait être fermée dans un avenir lointain comme un «double» de quelque chose qui s'est passé plus tard. Au moins, appelez-le quelque chose de plus descriptif, comme "remplacé" plutôt que dupliqué. Le "un" original ne peut être un duplicata de quoi que ce soit, c'est le seul.

248

/est le séparateur de chemin sur les systèmes Unix et de type Unix. Windows moderne peut généralement utiliser les deux \et de /manière interchangeable pour les chemins de fichiers, mais Microsoft préconise l'utilisation de \comme séparateur de chemin depuis des décennies.

Ceci est fait pour des raisons historiques qui remontent aux années 1970, précédant Windows de plus d'une décennie. Au début, MS-DOS (la base des premiers Windows) ne prenait pas en charge les répertoires. Unix a pris en charge les répertoires en utilisant le /caractère depuis le début. Cependant, lorsque des répertoires ont été ajoutés dans MS-DOS 2.0, Microsoft et IBM utilisaient déjà le /caractère pour les commutateurs de commande , et en raison de l'analyseur léger de DOS (descendant de QDOS , conçu pour s'exécuter sur du matériel inférieur), ils ne pouvaient pas trouver un moyen pratique d'utiliser le /personnage sans rompre la compatibilité avec leurs applications existantes.

Donc, pour éviter les erreurs de "manque un commutateur" ou "commutateur invalide" lors du passage des chemins de fichiers comme arguments à des commandes telles que celles-ci:

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

il a été décidé que le \caractère serait utilisé à la place, vous pouvez donc écrire ces commandes comme ceci

cd\
dir folder1\folder2

sans erreur.

Plus tard, Microsoft et IBM ont collaboré sur un système d'exploitation sans rapport avec DOS appelé OS / 2 . OS / 2 avait la capacité d'utiliser les deux séparateurs, probablement pour attirer plus de développeurs Unix. Lorsque Microsoft et IBM se sont séparés en 1990 , Microsoft a pris le code dont ils disposaient et a créé Windows NT , sur lequel toutes les versions modernes de Windows sont basées, emportant avec lui cet agnosticisme du séparateur.

Comme la rétrocompatibilité a été le nom du jeu pour Microsoft de toutes les transitions majeures du système d'exploitation qu'ils ont entreprises (DOS vers Win16 / DOS, vers Win16 / Win32, vers Win32 / WinNT), cette particularité est restée, et elle le sera probablement existent depuis un certain temps encore.

C'est pour cette raison que cet écart existe. Cela ne devrait vraiment avoir aucun effet sur ce que vous faites car, comme je l'ai dit, WinAPI peut généralement les utiliser de manière interchangeable. Cependant, les applications tierces seront probablement interrompues si vous réussissez /quand elles attendent un\ entre les noms de répertoire. Si vous utilisez Windows, respectez \. Si vous utilisez Unix ou des URI (qui ont leur fondement dans les chemins Unix, mais c'est une toute autre histoire), alors utilisez /.

Dans le contexte de C #: Il convient de noter, puisqu'il s'agit techniquement d'une question C #, que si vous voulez écrire plus de code C # «portable» qui fonctionne à la fois sous Unix et Windows (même si C # est principalement un langage Windows), vous peut souhaiter utiliser le Path.DirectorySeparatorCharchamp pour que votre code utilise le séparateur préféré sur ce système et l'utiliser Path.Combine()pour ajouter correctement les chemins.

— PC Luddite
source

57

Et combinez toujours les chemins en utilisant Path.Combine.

— Cheng Chen

1

Intéressant. Ainsi, sous DOS ou Windows, foo.exe /barpourrait être interprété comme un commutateur de ligne de commande, alors qu'il foo.exe \barpourrait être interprété comme faisant référence à un fichier / dossier appelé barqui se trouve dans le répertoire racine \du "lecteur" actuel, comme C:\par exemple.

— Jeppe Stig Nielsen

4

Il convient de noter que cette normalisation de /à \ est effectuée dans la couche de compatibilité Win32, ce qui signifie que si vous la contournez, il y aura une différence. L'exemple le plus connu est celui des chemins de longueur étendue: \\?\C:\ fonctionnera comme prévu sur NTFS mais \\?\C:/ne le fera pas.

— Voo le

4

@PC Luddite: Que WinAPI peut gérer à la fois /et ` is not entirely true. For network path you have to use `(par exemple. \\ <servername> bot not // <servername>)

— raznagul

2

@raznagul True. Je n'ai pas vraiment mentionné les chemins réseau dans ma réponse. Je suis resté principalement avec le type de chemin de fichier commun. J'ajouterai cela.

— PC Luddite

20

MS-DOS 1.0 a conservé la convention de caractères d'option de ligne de commande (ou commutateur) de «/» de CP / M. À cette époque, il n'y avait aucune structure de répertoire dans le système de fichiers et aucun conflit.

Lorsque Microsoft a développé l'environnement plus Unix avec MS-DOS (et PC-DOS) 2.0, ils ont dû représenter le séparateur de chemin en utilisant quelque chose qui n'était pas en conflit avec les options de ligne de commande existantes. En interne, le système fonctionne aussi bien avec «/» que «\». Le processeur de commandes (et de nombreuses applications) a continué à utiliser le «/» comme caractère de commutation.

Une CONFIG.SYSentrée SWITCHAR=-peut être utilisée pour remplacer la /valeur par défaut afin d'améliorer la compatibilité Unix. Cela fait que les commandes intégrées et les utilitaires standard utilisent le caractère alternatif. Le séparateur de chemin Unix pourrait alors être utilisé sans ambiguïté pour les noms de fichiers et de répertoires. Cette entrée a été supprimée dans les versions ultérieures, mais un appel DOS a été documenté pour définir la valeur après le démarrage.

Cela a été peu utilisé et la plupart des outils tiers sont restés inchangés. La confusion persiste. De nombreux ports des outils Unix conservent le caractère de commutateur «-» tandis que certains prennent en charge les deux conventions.

Le processeur de commandes PowerShell de suivi implémente des paramètres d'échappement et de commutation rigoureux et évite en grande partie la confusion, sauf lorsque des outils hérités sont utilisés.

Ni la question ni la réponse ne concernent C #.

— Pekka
source

2

À titre de note historique, l'utilisation de /comme introducteur d'options dans divers systèmes d'exploitation PDP-11 tels que RSTS (1970) et RSX (1972) précède celle de CP / M (1973).

— PJTraill

9

Sur les systèmes Unix, il \y a un caractère d'échappement, c'est-à-dire qu'il \indique à l'analyseur qu'il s'agit d'un espace et non de la fin de l'instruction. Sur les systèmes Unix /est le séparateur de répertoire.

Sous Windows \est le séparateur de répertoire, mais /ne peut pas être utilisé dans les noms de fichier ou de répertoire.

— PaysRabbit
source

1

\ et /(ainsi que plusieurs autres symboles) ne peuvent pas être utilisés dans les noms de fichiers car DOS n'avait pas le même analyseur complexe auquel les utilisateurs Unix sont si habitués. L'absence d'un bon analyseur était le résultat de MS-DOS descendant de QDOS («Quick and Dirty Operating System»). Il était destiné à faire fonctionner les choses rapidement et sur du matériel limité. Tout cela existe bien sûr encore de nos jours pour des raisons de compatibilité ascendante.

— PC Luddite

2

Eh bien, il convient de mentionner que dans les versions ultérieures de Windows, le a /été ajouté en tant que "Alternate_Directory_Separator"

— Tomer W

@PCLuddite peut-être devrions-nous plutôt penser à la compatibilité ascendante?

1

@nocomprende Et les chemins de fichiers sont-ils incompatibles? Incompatible avec quoi? Et comme je l'ai déjà dit, sauver "quelques applications DOS" (qui ressemblaient plus à des milliers) à la rupture était vraiment important pour les consommateurs à l'époque. C'est ce qui a fait le succès de Microsoft aujourd'hui et Unix (et tous les autres vraiment) a commencé à décliner (même s'il y a eu une résurgence au cours de la dernière décennie). Je ne vois pas comment cela ne regarde pas les choses avec bon sens.

— PC Luddite

1

@nocomprende Et votre argument sur le fait que les chemins de fichiers ne sont pas normalisés est complètement nul. Ils sont standardisés sous Windows et standardisés sous Unix. Si vous parlez d'une norme multiplateforme, ce n'est pas vraiment utile ou facile à mettre en œuvre. Qui peut dire qu'une norme est vraiment «meilleure» qu'une autre?

— PC Luddite

8

Une URL, normalisée dans la RFC 1738, utilise toujours des barres obliques, quelle que soit la plate-forme.
Un chemin de fichier et un URI sont différents. \est correct dans un chemin de fichier Windows et /est correct dans un URI.
Plusieurs navigateurs (à savoir, Firefox et Opera) échouent de manière catastrophique lorsqu'ils rencontrent des URI avec des barres obliques inverses.
System.IO.Path.DirectorySeparatorChar pour obtenir le séparateur de chemin actuel

Cela peut être une ressource pertinente.

— Sami
source

10

Un échec catastrophique? Firefox se traduit \à /automatiquement. Dans mon livre, cela s'appelle «fonctionne de manière transparente».

— Kroltan

22

ma maison a pris feu la dernière fois que j'ai utilisé \ dans Firefox

— user3163495

1

@CarstenS, Firefox ne convertit pas automatiquement la barre oblique inverse en barre oblique dans l'URL et n'ouvre pas le lien. Ce module complémentaire corrige l'URL avec une barre oblique inverse et ouvre la page. addons.mozilla.org/en-US/seamonkey/addon/…

— Sami

Qu'entendez-vous exactement par «échouer de façon catastrophique»? Ce qui se produit? Le navigateur plante-t-il et se ferme-t-il?

— Peter Mortensen du

7

Outre les réponses données, il convient de mentionner qu'il \est largement utilisé pour les caractères spéciaux (tels que\n \t ) dans les langages de programmation, les éditeurs de texte et les systèmes généraux qui appliquent l'analyse lexicale.

Si vous programmez par exemple, il est parfois peu pratique d'avoir même besoin d'échapper une barre oblique inverse avec un autre ( \\) pour l'utiliser correctement - ou d'utiliser des chaînes d'échappement, telles que C # @"\test".

Bien sûr, comme mentionné précédemment, les URI Web utilisent une barre oblique par défaut ~~mais les deux barres obliques fonctionnent dans les outils de ligne de commande les plus récents et les plus courants~~.

MISE À JOUR: Après avoir cherché un peu, il semble que toute l'histoire entre /et \retourne dans «l'histoire de l'ordinateur», à l'époque du DOS et des systèmes Unix à cette époque. HowToGeek a un article intéressant sur cette histoire.

En bref, DOS 1.0 a été initialement publié par IBM sans prise en charge d'annuaire, et a /été utilisé pour une autre fonctionnalité de commande ("commutation"). Lorsque les répertoires ont été introduits dans la version 2.0, /étaient déjà utilisés, alors IBM a choisi le symbole le plus proche visuellement, qui était \. D'autre part, Unix est généralement utilisé /pour les répertoires.

Lorsque les utilisateurs ont commencé à utiliser de nombreux systèmes différents, ils ont commencé à devenir confus, obligeant les développeurs de systèmes d'exploitation à tenter de faire fonctionner les systèmes dans les deux cas - cela s'applique même dans la partie des URL, car certains navigateurs prennent en charge le http: \\ www.test. format com \ go . Cela avait cependant des inconvénients en général, mais le tout reste aujourd'hui encore pour des causes de compartimentation arrière, avec une tentative de support des deux barres obliques sous Windows, même si elles ne sont plus basées sur DOS.

— Nick L.
source

"les deux barres obliques fonctionnent dans les chemins du système de fichiers." est incorrect, car Unix est assez en colère lorsque vous utilisez les ` as well as many shells make` ... vous avez raison de dire que Windows récent a défini la variable d'environnement ALTERNATE_PATH_SEPARATOR qui par défaut est /donc Windows peut probablement accepter les deux.

— Tomer W

1

@TomerW Windows NT a toujours été compatible avec POSIX (même si le début de POSIX était de toute façon un désordre, et une partie restait bloquée dans Windows pour des raisons de compatibilité ascendante). Cela incluait la prise en charge des /chemins partout dans le système - bien sûr, les applications pouvaient mal comprendre ces chemins à leur guise, donc ce n'était pas trop utilisé. Les applications non-CLI qui n'ont pas essayé de faire leur propre validation (cassée) des chemins ont bien fonctionné dès le départ.

— Luaan

@Luaan Windows avait la capacité de prendre en charge de nombreuses fonctionnalités POSIX, mais je dirais à peine qu'il était "compatible POSIX". Bien sûr, il y avait quelques sous-systèmes POSIX que l'on pouvait utiliser au fil des ans, mais ceux-ci étaient loin d'être idéaux. Windows 10 prendra en charge Ubuntu bash plus tard cet été avec un support natif pour les outils Linux fournis avec Ubuntu, vous pourrez donc peut-être faire valoir cela à l'avenir, mais vous ne pouvez certainement pas dire «toujours».

— PC Luddite

@Luaan Sauf si vous entendez par «compatible», «cygwin fonctionne».

— PC Luddite

@PCLuddite Non, il était 100% compatible POSIX.1c. Cela ne veut pas dire que toutes les applications Unix fonctionnent dessus - la plupart des applications Unix ne sont pas compatibles POSIX :)

— Luaan

6

Vous ne devriez pas utiliser non plus en C #. Vous devez toujours utiliser la Pathclasse . Cela contient une méthode appelée Path.Combinequi peut être utilisée pour créer des chemins sans spécifier le séparateur vous-même.

Exemple d'utilisation:

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

— TheLethalCoder
source

5

\ est utilisé pour les chemins de fichiers locaux Windows et les chemins de réseau comme dans:

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

/ est ce qui est requis par les URI standard comme dans:

http://www.stackoverflow.com/

— Cendre
source

2

@NikhilVartak, j'ai ajouté des exemples même si je pensais que ma réponse initiale répondait à toutes les questions du PO.

— Ash

3

Windows reconnaît également /dans les chemins (au moins 7 le font).

— Kenneth K.

Cette réponse est loin d'être complète.

— reinierpost

Étiez-vous censé créer un lien vers certaines ressources, en plus de la page principale de Stack Overflow?

— Tas

@reinierpost, ma réponse est basée sur la question du PO et les balises associées. Comme quelques-unes des autres réponses ici, je pourrais copier quelque chose de stackoverflow.com/questions/1589930/… et le coller ici mais cela semblait excessif. @tas, j'avais l'intention de créer un lien vers la page stackoverflow ou tout lien hypertexte de site Web pour illustrer l'utilisation des /URI standard comme je l'ai indiqué dans la réponse.

— Ash