많은 이유가 역사적입니다. 그렇다고 오늘날 이해가되지 않는다는 의미는 아닙니다.
이식성 문제
파일 이름을 지정할 때 다른 (파일) 시스템이 해당 파일 이름을 처리하는 방법을 고려해야 할 수도 있습니다. 파일 이름의 문자는 시스템에는 문제가 없지만 다른 시스템에는 문제가 될 수 있습니다.
따라서 이전 시스템에서 파일에 쉽게 액세스 할 수있는 가능성이 가장 적은 경우 안전한 문자 만 선택하면됩니다 . 여기에는 기존의 복구 시스템으로 부팅하거나 최신 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 \ path / Long \ program \ name 매개 변수 \ one 매개 변수 \ two ...
모호하지 않습니다.
URL (Uniform Resource Locator)
URL을 사용하여 파일의 위치를 설명하려고 할 때 공백을 이스케이프해야합니다.
여러 가지 이유로 문자가 안전하지 않을 수 있습니다. 공백 문자는 유효하지 않은 공백이 사라지고 URL이 전사되거나 조판되거나 워드 프로세싱 프로그램의 처리를받을 때 중요하지 않은 공백이 생길 수 있으므로 안전하지 않습니다.
출처 : RFC1738
따라서 공백 %20대신에 공백을 교체해야합니다 . 이렇게하면 URL의 파일 이름 부분을 읽기 어렵게하므로 사람들이 먼저 파일 이름을 피할 수 있습니다.