분류
1. 개요
2. 용도
2.1. 프로그래밍
프로그래밍 언어에서 이스케이프 문자를 나타낼 때 주로 쓰인다. 예를 들어서 \n은 많은 프로그래밍 언어에서 줄 바꿈을 의미한다. Microsoft Windows에서는 경로명의 디렉터리와 파일 이름을 구분하는 데 쓰인다(예: C:\Users\NamuWiki\Documents\merong.txt) 유닉스와 여기서 파생된 리눅스에서는 이 용도로 슬래시(/)를 쓴다. 다만 호환성을 위해 Windows에서도 슬래시(/)를 지원하기는 한다. 그리고 인터넷의 경우에는 서버 운영체제와 관계 없이 무조건 슬래시(/)만을 사용한다.
PHP에서는 \를 특수 문법으로 취급한다. \ 뒷부분에 오는 문자를 일반 텍스트로 인식시키는 기능인데, \와 같은 문자가 프로그래밍적인 기능을 하지 않고 일반 텍스트로 취급시키기 위하여 주로 사용한다. 5.3 이후부터는 이름공간(Namespace)의 하위 요소를 나타내는 구분자로 사용한다. 나무위키에서도 \ 문법이 먹힌다. \라고 편집창에 입력하면 쓰이지 않고 \\으로 2번 써야 \가 나온다.
PHP에서는 \를 특수 문법으로 취급한다. \ 뒷부분에 오는 문자를 일반 텍스트로 인식시키는 기능인데, \와 같은 문자가 프로그래밍적인 기능을 하지 않고 일반 텍스트로 취급시키기 위하여 주로 사용한다. 5.3 이후부터는 이름공간(Namespace)의 하위 요소를 나타내는 구분자로 사용한다. 나무위키에서도 \ 문법이 먹힌다. \라고 편집창에 입력하면 쓰이지 않고 \\으로 2번 써야 \가 나온다.
- 예시: 나무위키 편집창에
[[\]]라고 입력하면[[]]와 같은 형태로 바뀌는 것을 알 수 있다. 이는 세 번째]가 일반 텍스트로 인식되었기 때문이다. 이러한 방법으로 일부 특수 문서들을 링크걸 수 있다. 예를 들면 [E\]가 있다. 텍스트로 보여 주자면[[[E\]]]와 같은 형태이다.
2.2. 기타
3. 글꼴 표기 문제
3.1. Microsoft Windows
마이크로소프트의 기본 한국어 글꼴[1]과 기본 일본어 글꼴[2]은 백슬래시를 각각 원화 기호(₩)와 엔화 기호(¥)로 그려 놓는데, 이걸 싫어하는 사람들이 많다. 이유는 국제적인 소통에 혼동을 일으키기 십상이기 때문. 이 관행을 따를 경우, 천원을 나타내기 위해 '\1000'이라고 써 놓으면 읽는 사람의 국적에 따라 ₩1000으로도 ¥1000으로도 보일 수 있어서 1000원인지 1000엔인지 알 수 없으며, 한국인도 일본인도 아닌 영어 사용자들은 숫자 앞에 백슬래시를 적은 정체불명의 기행으로 보일 수밖에 없다.
특히 프로그래머들은 이러한 현상을 매우 싫어한다. 사실 이 문자는 프로그래밍이 아니면 쓰일 일이 거의 없는데, 프로그래머 입장에서는 불필요한 혼동만 유발하니 싫어할 수밖에 없다. 그래서인지 이쪽에 쓰이는 코딩용 글꼴은 반드시 백슬래시로 렌더링되도록 하는 불문율이 있다.
유니코드에는 \(U+005C), ₩(U+20A9), ¥(U+00A5)가 엄연히 따로 존재하고, \를 백슬래시라는 용도 외에 다른 용도로 사용할 수 있다고 정의되어 있지도 않다. 이 백슬래시 혼란을 일으킨 장본인은 일본의 JIS 코드인데, 1969년에 제정된 8비트짜리 JIS X 0201의 표준 ASCII 부분에서 백슬래시를 엔화 기호로 바꿔놓았고 물결표(~)를 오버라인(‾)으로 바꿔 놓았다. 한국 역시 1998년에 KS X 1003이라는 로마자 집합을 제정할 때 JIS X 0201과 비슷하게 백슬래시를 원화 기호로 바꿔놓았다.
이는 일반인의 입장에서 잘 쓰이지 않는 백슬래시 대신 상대적으로 많이 쓰이는 화폐 기호를 키보드로 쉽게 입력하기 위한 면이 크다. 당연히 이 첫 단추를 잘못 꿴 시점이 유니코드 개발보다 앞섰기 때문에 이게 고착된 것. 거기다 반각 문자인 ₩(U+20A9), ¥(U+00A5)는 EUC-KR, Shift_JIS 인코딩에 포함되어 있지도 않다.[3] 다만 HTML의 경우 해당 기호가 들어갈 자리에 ₩은
혼동을 방지하기 위해 화폐 단위를 쓸 때 백슬래시 대신 반각 원화 기호 ₩(U+20A9) 또는 전각 원화 기호 ￦(U+FFE6)[A], 반각 엔화 기호 ¥(U+00A5) 또는 전각 엔화 기호 ￥(U+FFE5)[A]를 쓰는 것이 좋다. 만약 특수문자 자체를 입력하기 어려운 상황이라면 KRW나 JPY와 같이 영문 이니셜로 적는 것도 좋다.
맑은 고딕 같은 몇몇 글꼴들은 혼동을 줄이기 위해 백슬래시로 쓰인 경우에는 가로줄을 한 개만 긋고, 실제 원화 기호로 쓰인 경우에는 가로줄을 두 개를 긋는다.
특히 프로그래머들은 이러한 현상을 매우 싫어한다. 사실 이 문자는 프로그래밍이 아니면 쓰일 일이 거의 없는데, 프로그래머 입장에서는 불필요한 혼동만 유발하니 싫어할 수밖에 없다. 그래서인지 이쪽에 쓰이는 코딩용 글꼴은 반드시 백슬래시로 렌더링되도록 하는 불문율이 있다.
유니코드에는 \(U+005C), ₩(U+20A9), ¥(U+00A5)가 엄연히 따로 존재하고, \를 백슬래시라는 용도 외에 다른 용도로 사용할 수 있다고 정의되어 있지도 않다. 이 백슬래시 혼란을 일으킨 장본인은 일본의 JIS 코드인데, 1969년에 제정된 8비트짜리 JIS X 0201의 표준 ASCII 부분에서 백슬래시를 엔화 기호로 바꿔놓았고 물결표(~)를 오버라인(‾)으로 바꿔 놓았다. 한국 역시 1998년에 KS X 1003이라는 로마자 집합을 제정할 때 JIS X 0201과 비슷하게 백슬래시를 원화 기호로 바꿔놓았다.
이는 일반인의 입장에서 잘 쓰이지 않는 백슬래시 대신 상대적으로 많이 쓰이는 화폐 기호를 키보드로 쉽게 입력하기 위한 면이 크다. 당연히 이 첫 단추를 잘못 꿴 시점이 유니코드 개발보다 앞섰기 때문에 이게 고착된 것. 거기다 반각 문자인 ₩(U+20A9), ¥(U+00A5)는 EUC-KR, Shift_JIS 인코딩에 포함되어 있지도 않다.[3] 다만 HTML의 경우 해당 기호가 들어갈 자리에 ₩은
₩, ¥은 ¥(또는 ¥)이라고 적으면 된다.혼동을 방지하기 위해 화폐 단위를 쓸 때 백슬래시 대신 반각 원화 기호 ₩(U+20A9) 또는 전각 원화 기호 ￦(U+FFE6)[A], 반각 엔화 기호 ¥(U+00A5) 또는 전각 엔화 기호 ￥(U+FFE5)[A]를 쓰는 것이 좋다. 만약 특수문자 자체를 입력하기 어려운 상황이라면 KRW나 JPY와 같이 영문 이니셜로 적는 것도 좋다.
맑은 고딕 같은 몇몇 글꼴들은 혼동을 줄이기 위해 백슬래시로 쓰인 경우에는 가로줄을 한 개만 긋고, 실제 원화 기호로 쓰인 경우에는 가로줄을 두 개를 긋는다.
3.2. 다른 운영 체제
4. 기타
나무위키를 비롯한 몇몇 웹사이트들은 환경에 상관 없이 백슬래시를 '＼'로 보이게 하기 위해 영문 글꼴을 최상위로 지정해둔다. 윈도우 XP에서는 Tahoma나 Arial을, 윈도우 비스타 이상에서는 Segoe UI를 최상위에 두면 된다.
한/글 97의 경우에도 자체적인 글꼴을 사용해서 화면을 표시하기 때문에 백슬래시가 온전하게 나온다. 시스템 글꼴을 기본으로 사용하는 2002 이상 버전이라도 한/글 전용 글꼴(HFT)을 사용하면 백슬래시가 온전하게 나오며, 2010부터 추가된 함초롬체도 백슬래시가 온전하게 나온다.
U+FF3C에 전각 백슬래시(＼)가 있고 이는 글꼴에 따라 모양이 바뀌는 문제는 없으나, 프로그래밍 언어에서도 사용할 수 없고, MS 윈도의 디렉터리 구분자로도 사용할 수 없는 그냥 일반 문자일 뿐이다. 즉 백슬래시 모양을 표시해야 하는 상황이면 이걸, 프로그래밍을 할 때는 \를 쓰자.
Shift_JIS 인코딩에서는 위의 글꼴 문제 이외에 다른 문제가 존재하는데, 이 백슬래시 문자(0x5C)를 MBCS 영역에 집어넣은 것이다. 이것 때문에 일본어 윈도우에서 압축한 ZIP 파일을 외국 윈도우에서 열면 이 백슬래시 문제 때문에 압축을 풀지 못하는 경우가 많다. 글꼴 문제는 단순히 글꼴을 바꾸기만 하면 해결되지만, 이건 Shift_JIS 인코딩 자체가 워낙 기형적이어서 발생하는 문제인지라, 유니코드로 완전히 바뀌고 MBCS 인코딩 체제가 멸종하지 않는 이상 완전한 해결이 불가능하다. 이후 마이크로소프트에서 Windows-949라는 확장완성형 인코딩을 만들 때에는 백슬래시 문제가 발생하지 않도록 바이트 범위를 조정했다. 아무튼 ZIP 파일의 경우에는 인코딩 지정이 가능한 반디집을 사용하면 정상적으로 풀 수 있으며, 텍스트 파일의 경우에는 Notepad++라는 텍스트 편집기를 사용해서 인코딩을 지정해 주면 정상적으로 읽어낸다.
여담이지만, 나무위키에서는 이 문서에서 아무 링크나 들어간 다음에 뒤로가기를 누르면 어째서인지 / 문서로 가졌다. 그리고 문서 제목은 '/'(%2F)인데 URL부분은 %5C('\')로 되어있는 신기한 광경을 볼 수 있었다. 나무위키 기능 업데이트로 수정되었다.
한/글 97의 경우에도 자체적인 글꼴을 사용해서 화면을 표시하기 때문에 백슬래시가 온전하게 나온다. 시스템 글꼴을 기본으로 사용하는 2002 이상 버전이라도 한/글 전용 글꼴(HFT)을 사용하면 백슬래시가 온전하게 나오며, 2010부터 추가된 함초롬체도 백슬래시가 온전하게 나온다.
U+FF3C에 전각 백슬래시(＼)가 있고 이는 글꼴에 따라 모양이 바뀌는 문제는 없으나, 프로그래밍 언어에서도 사용할 수 없고, MS 윈도의 디렉터리 구분자로도 사용할 수 없는 그냥 일반 문자일 뿐이다. 즉 백슬래시 모양을 표시해야 하는 상황이면 이걸, 프로그래밍을 할 때는 \를 쓰자.
Shift_JIS 인코딩에서는 위의 글꼴 문제 이외에 다른 문제가 존재하는데, 이 백슬래시 문자(0x5C)를 MBCS 영역에 집어넣은 것이다. 이것 때문에 일본어 윈도우에서 압축한 ZIP 파일을 외국 윈도우에서 열면 이 백슬래시 문제 때문에 압축을 풀지 못하는 경우가 많다. 글꼴 문제는 단순히 글꼴을 바꾸기만 하면 해결되지만, 이건 Shift_JIS 인코딩 자체가 워낙 기형적이어서 발생하는 문제인지라, 유니코드로 완전히 바뀌고 MBCS 인코딩 체제가 멸종하지 않는 이상 완전한 해결이 불가능하다. 이후 마이크로소프트에서 Windows-949라는 확장완성형 인코딩을 만들 때에는 백슬래시 문제가 발생하지 않도록 바이트 범위를 조정했다. 아무튼 ZIP 파일의 경우에는 인코딩 지정이 가능한 반디집을 사용하면 정상적으로 풀 수 있으며, 텍스트 파일의 경우에는 Notepad++라는 텍스트 편집기를 사용해서 인코딩을 지정해 주면 정상적으로 읽어낸다.
여담이지만, 나무위키에서는 이 문서에서 아무 링크나 들어간 다음에 뒤로가기를 누르면 어째서인지 / 문서로 가졌다. 그리고 문서 제목은 '/'(%2F)인데 URL부분은 %5C('\')로 되어있는 신기한 광경을 볼 수 있었다. 나무위키 기능 업데이트로 수정되었다.