파일 경로에서 슬래시 (/)와 백 슬래시 (\)의 차이점

153

파일 경로 \와 /파일 경로 의 차이점에 대해 궁금했습니다 . 나는 때때로 경로가 포함되어 /있고 때로는 경로가 있음을 알았 습니다 \.

누구나 사용할 때 설명 할 수 있다면 그것은 좋은 것 \하고 /.

— 스파이더 맨
소스

4

어떤 맥락에서 차이가 있습니까? 웹비 컨텍스트? C # 문자열에서 탈출? ASP.NET으로 태그되어 있습니다.

— Peter Mortensen

9

슬래시와 백 슬래시

— Peter Mortensen

6

@ 피터 더 나은 답변을 가지고 있기 때문에 나는 이것의 속임수로 오래된 것을 닫을 것입니다.

— nicael

6

방법입니다 C #을 하고 asp.net 질문에 관련이?

— Oriol

2

@zzzzBov 왜 이것이 단순히 오래된 것으로 리디렉션되지 않고 더 나은 답변이 거기에 배치 되었습니까? 저는 나중에 질문이 "중복 된"문제로 폐쇄 될 수있는 시스템이 마음에 들지 않습니다. 적어도 그것을 복제하기보다는 "대체 된"과 같은보다 설명적인 것으로 부르십시오. 원래의 "하나"는 아무것도 복제 할 수 없으며 유일한 것입니다.

248

/유닉스 및 유닉스 계열 시스템에서 경로 구분 기호입니다. 현대 윈도우는 일반적으로 모두 사용할 수 있습니다 \및 /상호 교환 filepaths을 위해,하지만 마이크로 소프트의 사용을 옹호했다 \수십 년의 경로 구분 기호로.

이는 1970 년대로 거슬러 올라가는 역사적인 이유로 Windows를 10 년 이상 앞질렀습니다. 처음에는 MS-DOS (초기 Windows의 기초)가 디렉토리를 지원하지 않았습니다. 유닉스는 /처음부터 문자를 사용하여 디렉토리를 지원했습니다 . 그러나 디렉토리가 MS-DOS 2.0에 추가되었을 때, Microsoft와 IBM은 이미 명령 스위치/ 문자를 사용하고 있었고 DOS의 경량 구문 분석기 ( QDOS 에서 다운 스트림 하드웨어에서 실행되도록 설계됨)로 인해 디렉토리를 찾을 수 없었습니다. 기존 응용 프로그램과의 호환성을 유지하면서 캐릭터 를 사용할 수있는 방법 입니다./

따라서 파일 경로를 다음과 같은 명령에 인수로 전달할 때 "스위치 누락"또는 "잘못된 스위치"에 대한 오류를 피하려면 다음을 수행하십시오.

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

\대신 문자를 사용 하기로 결정 했으므로 다음과 같은 명령을 작성할 수 있습니다

cd\
dir folder1\folder2

오류없이.

나중에 Microsoft와 IBM은 OS / 2 라는 DOS와 관련이없는 운영 체제에서 협업했습니다 . OS / 2는 두 구분 기호를 모두 사용할 수 있었으며 아마도 더 많은 유닉스 개발자들을 유치 할 수있었습니다. 마이크로 소프트와 IBM이 1990 년에 헤어 졌을 때 , 마이크로 소프트는 보유하고있는 코드를 취하여 Windows NT를 만들었으며, 모든 최신 버전의 Windows가 기반을두고이 구분 기호에 무관심 함을 나타냅니다.

이전 버전과의 호환성은 그들이 수행했던 모든 주요 OS 전환 (DOS에서 Win16 / DOS, Win16 / Win32, Win32 / WinNT로)에서 Microsoft의 게임 이름 이었으므로,이 특성은 고착 될 것입니다. 한동안 존재합니다.

이런 이유로이 불일치가 존재합니다. 내가 말했듯이 WinAPI는 일반적으로 상호 교환 적으로 사용할 수 있기 때문에 실제로 수행중인 작업에는 영향을 미치지 않습니다. 그러나 타사 응용 프로그램은 디렉토리 이름 사이 /를 예상 할 때 a를 전달하면 중단 될 수 \있습니다. Windows를 사용하는 경우를 사용하십시오 \. 유닉스 또는 URI (유닉스 경로에 기초가 있지만 완전히 다른 이야기)를 사용하는 경우을 사용하십시오 /.

C 번호의 맥락에서 : 이 때문에 그것은 주목해야한다 이고 , 기술적으로는 C # 질문이 더 많은 "휴대용"C # 코드를 작성하려는 경우 그 유닉스 및 Windows (C 번호가 Windows 언어가 주로 경우에도) 모두에서 작품을 Path.DirectorySeparatorChar코드가 해당 시스템에서 선호하는 구분 기호를 사용 Path.Combine()하고 경로를 올바르게 추가 하는 데 사용하도록 필드 를 사용하려고 할 수 있습니다 .

— PC 루디 테
소스

57

그리고 항상을 사용하여 경로를 결합하십시오 Path.Combine.

— Cheng Chen

1

흥미 롭군 따라서 DOS 또는 Windows에서는 foo.exe /bar명령 줄 스위치 foo.exe \bar로 해석 될 수 있지만 , 예 를 들어 현재 "드라이브" bar의 루트 디렉토리 \에 있는 파일 / 폴더를 참조하는 것으로 해석 될 수 있습니다 C:\.

— Jeppe Stig Nielsen

4

에서이 정상화 주목해야한다 /로는 \ 당신이 그것을 회피하는 경우 차이가있을 것이라는 점을 의미 계층 (호환)는 Win32에서 이루어집니다. 가장 잘 알려진 예는 확장 길이 경로입니다. \\?\C:\ NTFS에서 예상대로 작동하지만 작동 \\?\C:/하지 않습니다.

— Voo

4

@PC Luddite : WinAPI는 둘 다 /및 ` is not entirely true. For network path you have to use `를 처리 할 수 있습니다 (예 : // <servername>가 아닌 \\ <servername> bot)

— raznagul

2

@raznagul 맞습니다. 내 대답에 네트워크 경로를 언급하지 않았습니다. 나는 주로 공통 파일 경로 유형을 고수했습니다. 추가하겠습니다.

— PC Luddite

20

MS-DOS 1.0 은 CP / M에서 '/'의 명령 행 옵션 (또는 스위치) 문자 규칙을 유지했습니다. 그 당시에는 파일 시스템에 디렉토리 구조가 없었으며 충돌이 없었습니다.

Microsoft가 MS-DOS (및 PC-DOS) 2.0으로 더 유닉스와 유사한 환경을 개발할 때 기존 명령 줄 옵션과 충돌하지 않는 것을 사용하여 경로 구분 기호를 나타내야했습니다. 내부적으로 시스템은 '/'또는 '\'와 동일하게 작동합니다. 명령 프로세서 (및 많은 응용 프로그램)는 계속 '/'를 스위치 문자로 사용했습니다.

CONFIG.SYS항목은 SWITCHAR=-무시하는 데 사용할 수 /유닉스 호환성을 개선하기 위해 기본. 내장 명령과 표준 유틸리티는 대체 문자를 사용합니다. 그러면 Unix 경로 구분 기호를 파일 및 디렉토리 이름에 명확하게 사용할 수 있습니다. 이 항목은 이후 버전에서 제거되었지만 부팅 후 값을 설정하기 위해 DOS 호출이 문서화되었습니다.

이것은 거의 사용되지 않았으며 대부분의 타사 도구는 변경되지 않았습니다. 혼란이 지속됩니다. 많은 유닉스 도구 포트는 '-'스위치 문자를 유지하지만 일부는 두 규칙을 모두 지원합니다.

후속 PowerShell 명령 프로세서는 엄격한 이스케이프 및 스위치 매개 변수를 구현하며 레거시 도구가 사용되는 경우를 제외하고는 혼란을 피합니다.

질문이나 대답 모두 C #과 관련이 없습니다.

— 페카
소스

2

역사적 /으로 RSTS (1970) 및 RSX (1972)와 같은 다양한 PDP-11 운영 체제에서 옵션 도입 자로 사용 하는 것이 CP / M (1973)보다 우선합니다.

— PJTraill

9

유닉스 기반 시스템 \에서 이스케이프 문자 \는 구문 분석기에게 이것이 공백이 아니라 명령문의 끝이 아님을 알려줍니다. 유닉스 시스템 /에서는 디렉토리 구분자가 있습니다.

Windows \에서는 디렉토리 분리자가 있지만 /파일 또는 디렉토리 이름에 사용할 수 없습니다.

— 국가 토끼
소스

1

\ 및 /DOS 유닉스 사용자가 그렇게하는 데 사용되는 것과 같은 복잡한 파서를 가지고 있지 않았기 때문에 (물론 여러 다른 기호로) 파일 이름에 사용할 수 없습니다. 좋은 파서가 부족한 것은 MS-DOS가 QDOS ( "빠르고 더러운 운영 체제")에서 내려온 결과였습니다. 제한된 하드웨어에서 빠르게 실행되도록하는 것이 었습니다. 이 모든 것은 물론 이전 버전과의 호환성을 위해 현재에도 존재합니다.

— PC Luddite

2

이후 Windows 버전에서는 /"Alternate_Directory_Separator"로 추가 되었다는 사실을 언급 할 가치가 있습니다.

— Tomer W

@PCLuddite 어쩌면 우리는 앞으로 호환성을 생각해야합니까?

1

@nocomprende 비교할 수없는 파일 경로는 어떻습니까? 무엇과 호환되지 않습니까? 그리고 내가 전에 말했듯이, "몇몇 DOS 앱"(실제로 수천에 가까운)을 구하는 것을 막는 것은 당시 소비자들에게 정말 중요했습니다. 오늘날 Microsoft가 성공한 것은 유닉스 (및 다른 모든 것)가 쇠퇴를 시작합니다 (최근 10 년 동안 부활이 있었음에도 불구하고). 나는 그것이 상식적으로 그것을 보지 않는 방법을 보지 못합니다.

— PC Luddite

1

@nocomprende 그리고 표준화되지 않은 파일 경로에 대한 당신의 주장은 완전히 무효입니다. Windows에서 표준화되었으며 Unix에서 표준화되었습니다. 크로스 플랫폼 표준에 대해 이야기하고 있다면 실제로 그렇게 유용하거나 구현하기 쉽지 않습니다. 누가 한 표준이 다른 표준보다 실제로 더 낫다고 말할까요?

— PC Luddite

8

RFC 1738에서 표준화 된 URL은 플랫폼에 관계없이 항상 슬래시를 사용합니다.
파일 경로와 URI가 다릅니다. \Windows 파일 경로 /에서 정확하고 URI에서 정확합니다.
백 슬래시가있는 URI를 발견하면 여러 브라우저 (즉, Firefox 및 Opera)가 치명적으로 실패합니다.
현재 경로 구분 기호를 가져 오는 System.IO.Path.DirectorySeparatorChar

이것은 관련 자원이 될 수 있습니다.

— 사미
소스

10

치명적인 실패? Firefox \가 /자동으로 번역 됩니다. 내 책에서는 이것을 "완벽하게 작동"이라고합니다.

— Kroltan

22

Firefox에서 \를 마지막으로 사용할 때 내 집에 불이 붙었습니다

— user3163495

1

@CarstenS, Firefox는 URL 자동 분석에서 백 슬래시를 슬래시로 변환하지 않으며 링크를 열지 않습니다. 이 부가 기능은 백 슬래시와 열린 페이지로 URL을 수정합니다. addons.mozilla.org/en-US/seamonkey/addon/…

— Sami

"실패"라고 정확히 무엇을 의미합니까? 무슨 일이야? 브라우저가 충돌하고 종료됩니까?

— Peter Mortensen

7

주어진 답변 외에도 프로그래밍 언어, 텍스트 편집기 및 어휘 분석을 적용하는 일반 시스템의 \특수 문자 (예 :) 에 널리 사용되는 것은 언급 할 가치 \n \t가 있습니다.

예를 들어 프로그래밍하는 경우 다른 슬래시로 백 슬래시를 이스케이프 처리해야하는 경우가 종종 있습니다 (\\ 해야 할 필요가 있거나 C #과 같은 이스케이프 문자열을 사용해야하는 경우가 종종 불편합니다 @"\test".

물론 앞에서 언급했듯이 웹 URI는 표준에 따라 슬래시를 사용합니다. ~~두 슬래시는 최신의 가장 일반적인 명령 줄 도구에서 작동합니다.~~.

업데이트 : 약간의 검색 후,이 사이의 전체 이야기를 보인다 /그리고 \그 당시 DOS의 나이와 유닉스 기반의 시스템에서, "컴퓨터의 역사"로 돌아갑니다. HowToGeek 는 이 이야기에 관한 흥미로운 기사를 가지고 있습니다.

간단히 말해서, DOS 1.0은 처음에 디렉토리 지원없이 IBM에 의해 릴리스되었으며 /다른 ( "전환") 명령 기능에 사용되었습니다. 디렉토리가 2.0 버전으로 도입되었을 때 /이미 사용 중이었기 때문에 IBM은 시각적으로 가장 가까운 기호 인을 선택했습니다 \. 반면, 유닉스 /는 디렉토리에 표준으로 사용 되었습니다.

사용자가 많은 다른 시스템을 사용하기 시작했을 때 혼란스러워지기 시작하여 OS 개발자가 두 경우 모두 시스템을 작동 시키려고 시도했습니다. 일부 브라우저는 http : \\ www.test를 지원하므로 URL의 일부에도 적용됩니다 . com \ go 형식. 이것은 일반적으로 단점이 있었지만 더 이상 DOS를 기반으로하지 않더라도 Windows의 두 슬래시를 지원하려는 시도와 함께 오늘날의 모든 것이 여전히 하위 호환성 문제를 나타냅니다.

— 닉 L.
소스

"두 슬래시는 파일 시스템 경로에서 작동합니다." ` as well as many make` 셸 을 사용할 때 Unix가 매우 화가 났기 때문에 잘못되었습니다 ... 최근 Windows에서 ALTERNATE_PATH_SEPARATOR 환경 변수를 정의 /했으므로 Windows가 기본값으로 둘 다 허용 할 수 있습니다.

— Tomer W

1

@TomerW Windows NT는 항상 POSIX와 호환되었습니다 (초기 POSIX는 혼란 스러웠으며 일부는 Windows와의 호환성을 위해 Windows에 멈췄습니다). 여기에는 /시스템의 모든 곳에서 경로를 지원하는 것이 포함됩니다. 물론 응용 프로그램은 여가 시간에 경로를 잘못 이해할 수 있으므로 너무 많이 사용되지 않았습니다. 경로에 대한 자체 (깨진) 유효성 검사를 시도하지 않은 비 CLI 응용 프로그램은 처음부터 제대로 작동했습니다.

— Luaan

@Luaan Windows는 많은 POSIX 기능을 지원할 수 있었지만 "POSIX 호환"이라고는 거의 말할 수 없습니다. 물론 몇 년 동안 사용할 수있는 POSIX 하위 시스템이 몇 개 있었지만 이상적이지는 않았습니다. Windows 10은 올 여름 후반에 Ubuntu와 함께 제공되는 Linux 도구에 대한 기본 지원과 함께 Ubuntu bash를 지원하므로 앞으로는 논쟁의 여지가 있지만 "항상"이라고 말할 수는 없습니다.

— PC Luddite

@Luaan "호환"이 아니라면 "cygwin works"를 의미합니다.

— PC Luddite

@PCLuddite 아니요, 100 % POSIX.1c 호환이었습니다. 그렇다고 모든 유닉스 응용 프로그램이 작동한다는 의미는 아닙니다. 대부분의 유닉스 응용 프로그램은 POSIX와 호환 되지 않습니다 :)

— Luaan

6

C #에서 둘 중 하나를 사용해서는 안됩니다. 항상 Path클래스를 사용해야합니다 . 여기에는 Path.Combine구분 기호를 직접 지정하지 않고 경로를 만드는 데 사용할 수 있는 메소드가 포함되어 있습니다 .

사용법 예 :

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

— TheLethalCoder
소스

5

\ 다음과 같이 Windows 로컬 파일 경로 및 네트워크 경로에 사용됩니다.

C:\Windows\Temp\ 또는 \\NetworkSharedDisk\Documents\Archive\

/ 다음과 같이 표준 URI에 필요한 것입니다.

http://www.stackoverflow.com/

— 금연 건강 증진 협회
소스

2

@ NikhilVartak, 나는 초기 답변이 OP의 모든 질문에 대한 답변이라고 생각했지만 예제를 추가했습니다.

— Ash

3

Windows는 /경로를 인식 합니다 (최소한 7 개).

— Kenneth K.

이 답변은 완전하지 않습니다.

— reinierpost

스택 오버플로 기본 페이지 외에 일부 리소스에 연결하려고 했습니까?

— Tas

@reinierpost, 내 대답은 OP의 질문과 관련 태그를 기반으로합니다. 여기에있는 다른 답변 중 일부와 마찬가지로 stackoverflow.com/questions/1589930/ 에서 무언가를 복사 하여 여기에 붙여 넣을 수는 있지만 과도한 것처럼 보입니다. @tas, 나는 /대답에서 언급 한 표준 URI에서의 사용을 설명하기 위해 stackoverflow 페이지 또는 웹 사이트 하이퍼 링크에 링크하려고했습니다 .

— Ash