NamingThingsLikeThis.txt내가 아는 누군가는 오늘날 파일 이름 에 공백을 지원하는 대부분의 최신 운영 체제에도 불구하고 파일 이름에 공백을 사용하지 않는 경향이 있는 사람들에 대해 짜증을 표현했습니다 .
거기 있어요기술적인 이유(적절한) 공백이 없는 파일 이름을 보는 것이 여전히 일반적이라는 사실을 알고 계시나요? 그렇다면 파일 이름에 공백을 피하거나 권장하지 않는 기술적인 이유는 무엇이며 어떤 상황에서 관련이 있습니까?
제가 생각할 수 있는 가장 분명한 이유와 일반적으로 이를 피하는 이유는 해당 파일을 처리할 때 명령줄에 추가 따옴표가 필요하기 때문입니다. 다른 중요한 기술적인 이유가 있나요?
답변1
파일 이름의 공백 문자는 명령줄의 여러 상황과 스크립트에서 제대로 이스케이프되어 명령에 대한 구분 기호처럼 보이지 않도록 주의해야 하는 속담에서 진정한 골칫거리가 될 수 있습니다. 달리기.
파일/디렉터리/무엇이든 그러한 컨텍스트에서 절대 사용되지 않을 것이라고 확신하더라도 거기에 두지 않는 것이 더 안전합니다.
그것과 오래된 습관은 쉽게 죽지 않습니다.
답변2
명령줄 및 오래된 습관에 대한 다른 답변 외에도 공백이 포함된 파일 이름을 처리할 때 특별한 주의가 필요한 네트워크 프로토콜도 많이 있습니다.
(웹사이트에서 "Product List.pdf"를 다운로드하려고 시도하여 "Product"라는 파일만 생성된 경우 상대방의 프로그래머가 알지 못하거나 할 수 없기 때문에 이에 물린 것입니다. http Content-Disposition 헤더에 대한 인용 규칙을 알아내지 못했습니다.)
답변3
많은 이유는 역사적입니다. 그렇다고 그들이 오늘날 이해가 되지 않는다는 의미는 아닙니다.
이식성의 문제
파일 이름을 지정할 때 다른 (파일) 시스템이 해당 파일 이름을 처리하는 방법도 고려해야 합니다. 파일 이름의 문자는 해당 시스템에서는 문제가 되지 않을 수 있지만 다른 시스템에서는 문제가 될 수 있습니다.
따라서 이전 시스템에서 파일에 쉽게 액세스할 수 있는 가능성이 조금이라도 있는 한 다음을 선택합니다.안전한성격. 여기에는 이전 복구 시스템으로 부팅하거나 최신 Windows 버전이 여전히 MS-DOS 기반이라는 두려움이 포함될 수 있습니다.
길이
파일 시스템은 파일이 가질 수 있는 길이를 제한할 수 있습니다. 이는 MS-DOS가 다음으로 제한되었던 시절에는 더욱 심각했습니다.8.3 파일 이름. 따라서 공백을 없애면 이름에 더 의미 있는 문자를 넣을 수 있습니다.
다른 여러 파일 시스템도 파일 이름 길이에 대해 엄격한 제한을 정의했습니다. Wikipedia에는 다음과 같은 테이블이 있습니다.파일 시스템 비교에 관한 기사세부 사항을 원하는 사람들을 위해.
예약된 문자
MS-DOS도 공백 문자를 예약 문자로 정의했습니다. 이는 공백 문자를 사용했기 때문입니다.FAT에 패딩. 또한 MS-DOS는 셸에서 이스케이프 시스템을 제공하지 않았습니다.
명령줄 해석
내가 아는 대부분의 명령줄은매개변수 구분 기호로 사용되는 공백 문자. 파일 이름을 적절하게 이스케이프하는 것을 무시하면 파일 이름의 일부가 호출하려는 응용 프로그램에 대한 매개 변수로 해석될 수 있으므로 심각한 결과를 초래할 수 있습니다.
다음의 차이점을 고려해보세요.
rm foo bar
그리고
rm "foo bar"
위에 링크된 WikiPedia 기사에서는 명령을 적절하게 이스케이프 처리하지 않아 발생하는 모호함을 지적합니다.
처음부터 파일 및 디렉터리 이름에 포함된 공백을 금지하거나(예: 공백을 밑줄 '_'로 대체), 명령줄 해석기와 프로그램에서 지원하는 경우 이러한 매개변수를 다음과 같이 사용하여 모호성을 방지할 수 있습니다. 인용 문자 사이에 공백을 포함하여 이름을 묶거나 공백 앞에 이스케이프 문자(일반적으로 백슬래시('\'))를 사용하여 인수를 지정합니다. 예를 들어
Long path/Long program name Parameter one Parameter two ...모호합니다("프로그램 이름"이 프로그램 이름의 일부입니까, 아니면 두 개의 매개변수입니까?). 하지만
Long_path/Long_program_name Parameter_one Parameter_two ..., LongPath/LongProgramName ParameterOne ParameterTwo ..., "Long path/Long program name" "Parameter one" "Parameter two" ...및 Long\ 경로/Long\ 프로그램\ 이름 Parameter\ 1 Parameter\ 2 ...
모호하지 않습니다.
URL(Uniform Resource Locator)
URL을 사용하여 파일 위치를 설명하려고 할 때 공백을 이스케이프해야 합니다.
캐릭터는 여러 가지 이유로 안전하지 않을 수 있습니다. URL을 복사하거나 조판하거나 워드 프로세싱 프로그램에서 처리할 때 중요한 공백이 사라지고 중요하지 않은 공백이 포함될 수 있으므로 공백 문자는 안전하지 않습니다.
원천:RFC1738
따라서 공백은 대신으로 대체되어야 합니다 %20. 이렇게 하면 URL의 파일 이름 부분을 읽기가 어려워지므로 사람들이 애초에 해당 부분을 피하게 됩니다.
답변4
때때로 공백은 명령줄에서 처리할 때, 이전 OS를 사용할 때, 다른 OS에서 컴파일될 프로그램을 작성할 때, 또는... 문제를 일으킬 수 있는 많은 이유가 있을 때 문제를 나타낼 수 있습니다. 실제로 다음과 같이 파일을 작성하는 것이 그렇게 문제가 된다고 생각하지 않습니다.공백 없는 파일.txt또는file_without_blanks.txt. 예를 들어 밑줄이 그어진 글꼴을 다룰 때 밑줄이 때때로 보이지 않을 수 있기 때문에 나는 dask를 선호합니다.
하지만 대부분은 노년기부터 습관이 되어온 문제이다. 충분하다고 생각하지 않는 것찬성포기할 이유.
관련이 없을 수도 있는 추가 메모이지만 그럼에도 불구하고 여기에 넣겠습니다. 공백을 사용하여 파일 이름을 지정하는 사람들은 일반적으로 그것에 대해 크게 생각하지 않습니다. 파일 이름에 피하는 것이 왜 좋은지 잘 모르는 사람들이 있습니다.
그리고 우리 모두 동의할 수 있습니다. "친애하는 선생님이나 부인께, 나는 당신에게 yo.doc에 대해 알리기 위해 이 편지를 쓰고 있습니다"라는 이름의 파일보다 더 나쁜 것은 없습니다.
공백뿐만 아니라 파일 길이도 중요합니다. IMHO, 예를 들어 30자를 초과하면 안 됩니다. 내부에 공백이 있는 긴 파일 이름의 경우 이전 OS 및 Win과 *nix 플랫폼 사이에서 읽어야 하는 CD, DVD 등을 기록할 때에도 도움이 됩니다.