파일명

Filename
디렉터리에 파일 이름이 표시된 Windows 명령 셸의 스크린샷
소프트웨어 디스플레이에 나타나는 쉼표와 공백 문자를 포함하는 긴 파일 이름을 가진 파일 이름 목록.

파일 이름 또는 파일 이름은 파일 시스템에서 컴퓨터 파일을 고유하게 식별하는 데 사용되는 이름입니다.파일 시스템마다 파일 이름 길이에 다른 제한이 있습니다.

파일 시스템에 따라 파일 이름은 다음과 같습니다.

유틸리티 및 응용 프로그램별로 파일을 식별하는 데 필요한 구성 요소는 운영 체제마다 다르며, 유효한 파일 이름에 대한 구문 및 형식도 다릅니다.

파일 이름에 허용되는 문자는 파일 시스템에 따라 다릅니다.대부분의 파일 시스템에서는 A-Z와 0-9 숫자를 사용할 수 있습니다. 많은 파일 시스템에서는 a-z 문자, 특수 문자 및 기타 인쇄 가능한 문자(예: 로마자가 아닌 알파벳의 강세 문자, 기호)를 지원합니다.일부 파일 시스템에서는 Bell, Null, ReturnLinefeed를 포함하여 인쇄할 수 없는 문자도 파일 이름의 일부로 허용하지만 대부분의 유틸리티에서는 이를 잘 처리하지 못합니다.[citation needed]

파일명에는 컴퓨터 코드, 숫자 시퀀스 번호(DCF 표준을 통해 디지털 카메라에서 널리 사용됨), 날짜 및 시간(스마트폰 카메라 소프트웨어 및 스크린샷에 널리 사용됨),파일 검색을 용이하게 하기 위한 제목, 위치 또는 기타 텍스트와 같은 주석.

어떤 사람들은 윈도우 C와 같은 장치, 서브디렉토리, 파일명의 완전한 사양을 언급할 때 파일명이라는 용어를 사용합니다.\Program Files\Microsoft Games\Chesss\Chess.exe.이 경우의 파일 이름은 Chess.exe입니다.일부 유틸리티에는 MS Windows 탐색기와 같이 확장을 억제하는 설정이 있습니다.[not verified in body]

역사

1970년대에 일부 메인프레임 및 미니 컴퓨터에는 시스템 상의 파일이 사용자 이름 또는 계정 번호로 식별되는 운영 체제가 있었습니다.

예를 들어, Digital Equipment CorporationTOPS-10RSTS/E 운영 체제에서 파일은 다음과 같이 식별되었습니다.

  • 선택적 장치 이름(1자 또는 2자) 다음에 선택적 장치 번호, 콜론 ":"를 입력합니다.존재하지 않는 경우 SY로 추정됩니다.
  • 대괄호 "["], 쉼표로 구분된 한 쌍의 숫자, 그리고 가까운 대괄호 "[]로 구성된 계정 번호.생략하면 당신 것으로 추정됩니다.
  • 필수 파일 이름, 1~6자로 구성(대소문자 또는 숫자)
  • 선택적인 3자 확장.

IBMOS/VS1, MVSOS/390 운영 체제에서 파일 이름은 대문자, 숫자 및 마침표로 구성된 최대 44자였습니다.파일 이름은 문자 또는 숫자로 시작해야 하며 마침표는 각 8자마다 한 번 이상 발생해야 하며, 두 개의 연속된 마침표는 이름에 표시할 수 없으며 문자 또는 숫자로 끝나야 합니다.[1]관례상 1기 전의 문자와 숫자는 소유자의 계좌번호 또는 소유 사업자의 계좌번호였지만, 이 규약을 사용할 필요는 없었습니다.[2]

McGill University MUSIC/SP 시스템에서 파일 이름은 다음과 같이 구성되었습니다.

  • 선택적 계정 번호. 1~4자 뒤에 콜론이 오는 번호입니다.계정 번호가 누락된 경우 계정에 있는 것으로 추정했지만 누락된 경우 공용으로 표시된 모든 파일이 카탈로그화된 *COM:pseudo-account에 있는 것으로 추정했습니다.
  • 1–17 문자 파일 이름. 대문자 또는 숫자일 수 있으며 마침표로 시작하거나 마침표로 끝나는 것이 아니거나 두 개의 연속된 마침표로 구성됩니다.

Univac VS/9 운영 체제는 다음과 같이 구성된 파일 이름을 가지고 있었습니다.

  • 달러 기호 "$", 1-7자(문자 또는 숫자) 사용자 이름 및 마침표(".")로 구성된 계정 이름입니다.존재하지 않는 경우 계정에 있는 것으로 추정되지만 존재하지 않는 경우 운영 체제는 시스템 관리자의 $TSOS 계정을 검색합니다.계정으로 달러 기호만 입력한 경우 첫 번째 마침표 이전의 파일 이름의 첫 번째 1-7 문자가 실제 계정 이름과 일치하지 않는 $TSOS 계정에 파일이 있음을 나타냅니다(예: ABLE).베이커는 당신의 계정에 있는 파일이지만 그렇지 않다면 시스템은 $TSOS를 검색할 것입니다.에이블.베이커, 하지만 $ABLE이면.$TSOS 파일인 Baker가 지정되었습니다.ABLE.BAKE는 $ABLE이 유효한 계정이 아니라면 사용될 것이고, 그 계정에서 BBAKE라는 이름의 파일을 찾을 것입니다.
  • 파일 이름, 마침표로 구분된 1~56자(글자 및 숫자).파일 이름은 마침표로 시작하거나 끝날 수 없으며, 두 개의 마침표가 연속적으로 나타날 수도 없습니다.

1985년에. RFC959는 공식적으로 경로 이름을 파일을 식별하기 위해 사용자가 파일 시스템에 입력해야 하는 문자열로 정의했습니다.[3]

CP/M 운영 체제를 사용하는 초기 개인용 컴퓨터에서 파일 이름은 항상 11자였습니다.이것을 최대 8바이트 이름과 최대 3바이트 확장자를 가진 8.3 파일 이름이라고 불렀습니다.유틸리티 및 응용프로그램을 통해 사용자는 파일 이름을 후행 공백 없이 지정하고 확장자 앞에 점을 포함할 수 있습니다.점이 디렉토리에 실제로 저장되지 않았습니다.7비트 문자만 사용하면 고차 비트를 사용하여 실제 파일 이름에 여러 파일 속성을 포함할 수 있습니다. 이러한 속성에는 Read only, Archive 및 System이 포함됩니다.[4]결국 이것은 너무 제한적이었고 허용된 문자의 수는 증가했습니다.속성 비트가 추가 정보를 포함하여 파일의 특수 블록으로 이동되었습니다.[citation needed]

원래의 FAT(File Allocation Table) 파일 시스템은 독립 실행형 디스크 BASIC-80에서 사용되었으며 파일 이름이 6.3바이트이고 확장자가 3바이트입니다.윈도우 95 이전의 IBM PC DOS/MS-DOS마이크로소프트 윈도우FAT12FAT16 파일 시스템은 CP/M 파일 시스템과 동일한 8.3 규약을 사용했습니다.FAT 파일 시스템은 8비트 문자를 지원하여 비ASC를 지원합니다.II 문자는 파일 이름에 포함되며, 속성은 파일 이름과 별도로 저장됩니다.

1995년경에 MS-DOS FAT 파일 시스템의 확장자인 VFAT윈도우 95와 윈도우 NT에 도입되었습니다.고전적인 "8.3" 이름뿐만 아니라 유니코드 문자를 사용하는 LFN(Mixed case long file name)을 허용했습니다.

참조: 절대 대 상대

절대 참조는 모든 디렉토리 수준을 포함합니다.일부 시스템에서는 완전한 디렉토리 경로를 포함하지 않는 파일 이름 참조가 현재 작업 디렉토리로 기본 설정됩니다.이것은 상대적인 참고 자료입니다.프로그램 구성 파일이나 스크립트에서 상대적인 참조를 사용하는 것의 한 가지 장점은 스크립트나 프로그램의 인스턴스가 다른 파일을 사용할 수 있다는 것입니다.

이것은 일련의 파일 이름으로 구성된 절대 경로 또는 상대 경로를 만듭니다.

파일당 이름 수

유닉스 계열 파일 시스템에서는 파일 이름을 둘 이상 가질 수 있습니다. 기존 유닉스 계열 파일 시스템에서는 이름이 파일의 inode 또는 동등한 파일에 대한 하드 링크입니다.Windows는 NTFS 파일 시스템에서 하드 링크를 지원하며 명령어를 제공합니다.fsutil윈도우 XP에서, 그리고mklink최신 버전에서는 이를 만들기 위해 사용합니다.[5][6]하드 링크는 Windows 바로 가기, Mac OS/macOS 별칭 또는 심볼릭 링크와는 다릅니다.VFAT을 사용하는 LFN을 도입하여 파일 이름 별칭을 허용했습니다.예를들면,longfi~1.???최대 8자에 3자를 더한 파일 이름 별칭은 ""입니다.long file name.???" 오래된 프로그램에 대한 8.3 제한을 준수하는 방법으로.

이 속성은 먼저 두 번째 파일 이름을 만든 다음 첫 번째 파일 이름만 제거하는 move 명령 알고리즘에서 사용되었습니다.

다른 파일 시스템은 설계상 파일당 하나의 파일만 제공하므로 한 파일의 파일을 변경하더라도 다른 파일의 파일은 변경되지 않습니다.

길이 제한

일부 파일 시스템에서는 파일 이름의 길이를 제한합니다.경우에 따라 IBM z/OS의 44자와 같이 이러한 길이가 전체 파일 이름에 적용됩니다.[1]다른 경우에는 디렉터리에 있는 파일 이름 또는 디렉터리 이름과 같은 파일 이름의 특정 부분에 길이 제한이 적용될 수 있습니다.예를 들어, 9개(예: 독립 실행형 디스크 BASIC의 8비트 FAT), 11개(예: DOS의 FAT12, FAT16, FAT32), 14개(예: 초기 유닉스), 21개(휴먼68K), 31개, 30개(예: Apple DOS 3.2 및 3.3), 15개(예: Apple ProDOS), 44개([1]예: IBM S/370) 또는 255개(예: 초기 버클리 유닉스) 문자 또는 바이트입니다.길이 제한은 파일 시스템의 고정 공간을 이름의 구성 요소를 저장하는 데 할당하는 데서 비롯되는 경우가 많기 때문에 제한을 늘리면 호환되지 않는 변경이 필요할 뿐만 아니라 더 많은 공간을 확보해야 합니다.

중첩된 디렉토리에 정보를 저장하는 파일 시스템의 특별한 문제는 전체 이름이 아닌 이름의 개별 부분에만 길이 확인이 적용될 수 있기 때문에 구현 제한을 초과하는 완전한 경로 이름을 가진 파일을 생성할 수 있다는 것입니다.많은 Windows 응용 프로그램은 다음과 같이 제한됩니다.MAX_PATH값이 260이지만 Windows 파일 이름은 이 제한을 쉽게 초과할 수 있습니다.[7]Windows 10 버전 1607에서는 MAX_PATH 제한이 제거되었습니다.[8]

파일 확장명

FAT파일-11의 ODS-1 및 ODS-2 수준과 같은 일부 파일 시스템의 파일 이름은 기본 이름 또는 스템과 일부 응용 프로그램에서 파일 형식을 나타내기 위해 사용하는 확장자 또는 접미사의 두 부분으로 구성됩니다.유닉스 파일 시스템, VFATNTFS와 같은 일부 다른 파일 시스템에서는 파일 이름을 하나의 문자열로 취급합니다. 이러한 파일 시스템에서 자주 사용되는 규칙은 파일 이름의 마지막 마침표 뒤에 오는 문자, 마침표가 포함된 파일 이름의 확장자 부분으로 취급합니다.

응용프로그램에서 생성된 여러 출력 파일은 동일한 기본 이름과 다양한 확장명을 사용할 수 있습니다.예를 들어, 포트란 컴파일러는 확장자를 사용할 수 있습니다.FOR소스 입력 파일의 경우,OBJ객체 출력에 대해LST상장을 위하여일부 일반적인 확장명이 있지만 임의적이며 다른 응용프로그램에서 사용할 수 있습니다.REL그리고.RPT. 확장자는 적어도 역사적으로 일부 시스템에서는 3자의 길이로 제한되었지만 일반적으로 임의의 길이를 가질 수 있습니다.html.

인코딩 상호운용성

파일 이름에 대한 일반적인 인코딩 표준이 없습니다.

네트워크 파일 전송, 파일 시스템 저장, 백업 및 파일 동기화 소프트웨어, 구성 관리, 데이터 압축 및 보관 등을 위해 소프트웨어 환경 간에 파일 이름을 교환해야 합니다.따라서 응용프로그램 간에 파일 이름 정보가 손실되지 않도록 하는 것이 매우 중요합니다.이로 인해 기존 소프트웨어가 유니코드를 인식하지 못할 수도 있지만 파일 이름을 인코딩하기 위한 표준으로 유니코드가 널리 채택되었습니다.

부호화 지시 상호운용성

전통적으로 파일 이름은 파일 시스템이 안전하기만 하면 파일 이름에 있는 모든 문자를 허용했습니다.[9]이렇게 하면 인코딩을 사용할 수 있으므로 로컬 시스템에서 로컬 텍스트를 표현할 수 있지만 많은 상호 운용성 문제가 발생했습니다.

파일 이름은 일본 Shift JIS 인코딩과 일본 EUC 인코딩을 사용하는 경우와 같이 단일 국가 내에서 서로 다른 시스템에 서로 다른 바이트 문자열을 사용하여 저장할 수 있습니다.대부분의 시스템에서 확장 파일 정보의 일부로 파일 이름에 사용되는 인코딩에 대한 설명을 표시하지 않았기 때문에 변환할 수 없었습니다.이로 인해 파일 액세스마다 값비싼 파일 이름 인코딩을 추측할 수 밖에 없었습니다.[9]

해결책은 유니코드를 파일 이름의 인코딩으로 채택하는 것이었습니다.

그러나 고전적인 Mac OS에서는 파일 이름의 인코딩이 파일 이름 속성과 함께 저장되었습니다.[9]

유니코드 상호운용성

유니코드 표준은 인코딩 결정 문제를 해결합니다.

그러나 정규화(동등성) 또는 사용 중인 유니코드 버전과 같은 제한된 상호 운용성 문제가 여전히 남아 있습니다.예를 들어, UDF는 유니코드 2.0으로 제한됩니다. macOS의 HFS+ 파일 시스템은 NFD 유니코드 정규화를 적용하고 선택적으로 대소문자 구분(기본적으로 대소문자 구분 없음).파일 이름의 최대 길이가 표준 길이가 아니며 코드 단위 크기에 따라 다를 수 있습니다.심각한 문제이긴 하지만 대부분의 경우 이 문제는 제한적입니다.[9]

Linux의 경우 파일 이름만으로는 파일을 열기에 충분하지 않습니다. 또한 스토리지 장치에서 파일 이름의 정확한 바이트 표현이 필요합니다.이것은 까다로운 정규화 호출을 통해 응용 프로그램 수준에서 해결할 수 있습니다.[10]

유니코드 동등성 문제는 "정규화된 이름 충돌"로 알려져 있습니다.해결책으로는 Subversion 및 Apache 기술 커뮤니티에서 사용되는 Nonnormalizing Unicode Composition Awareness가 있습니다.[11]이 솔루션은 저장소의 경로를 정규화하지 않습니다.경로는 비교를 위해서만 정규화됩니다.그럼에도 불구하고, 일부 지역사회는 다른 지역사회의 사용을 금지하는 이 전략에 대한 특허를 냈습니다.[clarification needed]

원근법

상호 운용성 문제를 제한하기 위해 Sun이 설명한 몇 가지 아이디어는 다음과 같습니다.

  • 하나의 유니코드 인코딩을 사용합니다(예: UTF-8).
  • 파일 이름에 대해 투명한 코드 변환 수행합니다.
  • 정규화된 파일 이름 저장 안 함
  • 파일 이름 간의 표준 동등성을 검사하여 동일한 디렉토리에서 두 개의 표준 동등성 파일 이름을 피할 수 있습니다.[9]

이러한 고려 사항은 UTF-8과 다른 향후 인코딩으로 전환을 허용하지 않는 제한을 만듭니다.

유니코드 마이그레이션

한 가지 문제는 유니코드로의 마이그레이션이었습니다.이를 위해 여러 소프트웨어 회사에서 파일 이름을 새 유니코드 인코딩으로 마이그레이션하는 소프트웨어를 제공했습니다.

  • 마이크로소프트는 VFAT 기술 전반에 걸쳐 사용자에게 투명하게 마이그레이션을 제공했습니다.
  • 애플은 "파일 이름 인코딩 복구 유틸리티 v1.0"을 제공했습니다.[12]
  • 리눅스 커뮤니티는 "convmv"를 제공했습니다.[13]

맥 OS X 10.3은 애플이 유니코드 3.2 문자 분해를 채택한 것으로, 이전에 사용되었던 유니코드 2.1 문자 분해를 대체했습니다.이러한 변화는 개발자들이 맥 OS X용 소프트웨어를 쓰는 데 문제를 일으켰습니다.[14]

유니크함

단일 디렉토리 내에서 파일 이름은 고유해야 합니다.파일 이름 구문은 디렉토리에도 적용되므로 단일 디렉토리에 동일한 이름의 파일 및 디렉토리 항목을 작성할 수 없습니다.서로 다른 디렉토리에 있는 여러 파일의 이름이 같을 수 있습니다.

고유성 접근 방식은 대소문자 민감도와 NFC, NFD와 같은 유니코드 정규화 형태에 따라 다를 수 있습니다.즉, L"\x00C0와 같이 동일한 텍스트 파일 이름과 다른 바이트 구현으로 두 개의 개별 파일이 생성될 수 있습니다.txt" (UTF-16, NFC) (묘가 있는 라틴어 대문자 A) 및 L"\x0041\x0300.txt" (UTF-16, NFD)[15] (라틴어 대문자 A, 묘가 있는 결합).

레터케이스보존

FAT와 같은 일부 파일 시스템은 파일 이름을 만드는 데 사용된 문자 대소문자에 관계없이 파일 이름을 대문자로 저장합니다.예를 들어, "MyName"이라는 이름으로 작성된 파일입니다.Txt" 또는 "내 이름".txt"는 "MYNAME.TXT"라는 파일명과 함께 저장됩니다.대문자와 소문자의 변형은 동일한 파일을 참조하는 데 사용할 수 있습니다.이러한 종류의 파일 시스템은 대소문자를 구분하지 않으며 대소문자를 구분하지 않습니다.일부 파일 시스템에서는 파일 이름에 소문자를 사용하는 것을 전면적으로 금지합니다.

일부 파일 시스템은 파일 이름을 원래 작성한 형태로 저장합니다. 이러한 파일 이름을 대소문자 보존 또는 대소문자 보존이라고 합니다.이러한 파일 시스템은 대소문자를 구분하거나 대소문자를 구분하지 않을 수 있습니다.대소문자를 구분하는 경우 "My Name"을 선택합니다.Txt'와 '내 이름.txt"는 동일한 디렉토리에 있는 두 개의 다른 파일을 나타낼 수 있으며 각 파일은 이름이 지정된 정확한 대문자로 참조되어야 합니다.대소문자를 구분하지 않고 대소문자를 보존하는 파일 시스템에서는 "MyName" 중 하나만 사용할 수 있습니다.Txt", "내 이름은.txt"와 "내 이름".TXT"는 주어진 시간에 주어진 디렉토리에 있는 파일의 이름이 될 수 있으며, 이러한 이름 중 하나를 가진 파일은 이름의 대문자로 참조될 수 있습니다.

처음부터 유닉스와 파생 시스템은 사례를 보존하고 있었습니다.그러나 모든 유닉스 계열 파일 시스템이 대소문자를 구분하지는 않습니다. macOS의 HFS+기본적으로 대소문자를 구분하지 않으며 SMB 서버는 대개 대소문자를 구분하지 않는 동작을 제공합니다(예: 대부분의 유닉스 계열 시스템의 Samba). SMB 클라이언트 파일 시스템은 대소문자를 구분하지 않는 동작을 제공합니다.파일 시스템 대소문자 구분은 Samba 및 Wine과 같은 소프트웨어에서 상당히 어려운 문제입니다. Samba 및 Wine은 대문자 및 소문자 파일을 서로 다르게 취급하는 시스템과 동일하게 취급하는 시스템과 효율적으로 상호 운용해야 합니다.[16]

예약 문자 및 단어

파일 시스템에서 파일 이름을 구성할 때 항상 동일한 문자 집합을 제공한 것은 아닙니다.유니코드가 사실상의 표준이 되기 전에는 파일 시스템은 대부분 로케일 의존 문자 집합을 사용했습니다.대조적으로, 일부 새로운 시스템은 유니코드 레퍼토리의 거의 모든 문자와 심지어 유니코드가 아닌 바이트 시퀀스로 파일 이름을 구성할 수 있도록 허용합니다.파일 시스템, 운영 체제, 응용 프로그램 또는 다른 시스템과의 상호 운용성 요구 사항에 따라 제한이 발생할 수 있습니다.

많은 파일 시스템 유틸리티는 제어 문자가 파일 이름에 나타나는 것을 금지합니다.유닉스 계열 파일 시스템에서 null 문자[17] 경로 구분자/금물입니다.

Windows에서

다양한 시스템의 파일 시스템 유틸리티 및 명명 규칙은 특정 문자가 파일 이름에 나타나는 것을 금지하거나 문제가 되게 합니다.[7]

성격 이름. 금지사유
/ 머리를 깎다 Unix-like, Windows 및 Amiga 시스템에서 경로 이름 구성 요소 구분자로 사용됩니다. (SwitchChar 설정이 /로 설정된 경우 DOS COMMAND.COM 셸은 스위치 문자로 사용하지만, 도스와 윈도우 자체는 항상 API 수준에서 구분자로 사용합니다.)
Windows 파일 이름에는 큰 solidus ⧸(Unicode code point U+29F8)이 허용됩니다.
\ 백슬래시 DOS, OS/2 및 Windows에서 기본 경로 이름 구성 요소 구분자로 사용됩니다(SwitchChar가 '-'로 설정된 경우에도 Unix 파일 이름에서 허용됨, 참고 1 참조).
Windows 파일 이름에는 대규모 역방향 솔리드러스 ⧹(U+29F9)이 허용됩니다.
? 물음표 유닉스, 윈도우 및 아미가에서 와일드카드로 사용OS; 단일 문자를 표시합니다.Unix 파일 이름에 허용됨, 참고 1 참조.
성문 정지 ʔ(U+0294), 인터로방 (U+203D), 반전 물음표 ¿(U+00BF) 및 이중 물음표 ⁇(U+2047)는 모든 파일 이름에서 허용됩니다.
% 퍼센트 RT-11에서 와일드카드로 사용되며, 단일 문자를 표시합니다.Windows에서는 특별하지 않습니다.
* 별표의
아니면
유닉스, 도스, RT-11, VMS 및 윈도우에서 와일드카드로 사용됩니다.문자 시퀀스(Unix, Windows, DOS) 또는 기본 이름 또는 확장자의 문자 시퀀스(따라서 "*")를 표시합니다.*" 도스(DOS)는 "모든 파일"을 의미합니다.Unix 파일 이름에 허용됨, 참고 1 참조.
파일 이름에 허용되는 많은 별표와 같은 문자에 대해서는 별(글리프)을 참조하십시오.
: 대장의 Windows에서 마운트 지점/드라이브를 결정하는 데 사용되며, AmigaOS, RT-11 및 VMS의 드라이브와 같은 가상 장치 또는 물리적 장치를 결정하는 데 사용되며, 기존 Mac OS에서 경로 이름 구분자로 사용됩니다.VMS의 이름 뒤에 두 배로 늘어남, DECnet 노드 이름(NetB와 동일)을 나타냅니다.IOS(윈도우즈 네트워킹) 호스트 이름 앞에 "\"("\")가 붙습니다.또한 콜론은 Windows에서 기본 파일에서 대체 데이터 스트림을 분리하는 데 사용됩니다.
윈도우즈 파일 이름에는 문자 콜론 (U+A789) 및 비율 기호 ∶(U+2236)이 허용됩니다.Windows 탐색기에서 사용되는 세고 UI 글꼴에서 콜론과 콜론 문자의 글리프는 동일합니다.
세로 막대
또는 파이프
유닉스, 도스, 윈도우에서 소프트웨어 파이프라인을 지정하며, 유닉스 파일명에서 허용됨, 주 1 참조.윈도우즈 파일 이름에는 수학 연산자 ∣(U+2223)이 허용됩니다.
" 직설적인 큰따옴표 DOS에서 넘겨받은 레거시 제한입니다.'(U+0027), ' '(U+2018), '(U+2019)와 '곡선 쌍따옴표 '(U+201C), '(U+201D)는 파일 이름 어디에서나 사용할 수 있습니다. 1 참조.
< 보다 적은 입력을 리디렉션하는 데 사용되며, Unix 파일 이름에서 허용됩니다. 참고 1을 참조하십시오.공백 한정자 문자 ˂(U+2C2)는 Windows 파일 이름에서 사용할 수 있습니다.
> 보다 큰 출력을 리디렉션하는 데 사용되며, Unix 파일 이름에서 허용됩니다(참고 1 참조).공백 한정자 문자 ˃(U+2C3)은 Windows 파일 이름에서 사용할 수 있습니다.
. 기간을
또는 점
Windows에서 폴더 이름은 마침표로 끝날 수 없지만 마침표 뒤에 공백(: 공백)으로 끝날 수 있습니다.다른 곳에서는 기간이 허용되지만 마지막으로 발생한 것은 VMS, DOS 및 Windows에서 확장 구분자로 해석됩니다.일반적으로 파일 이름의 일부로 간주되는 다른 OS에서는 두 개 이상의 주기(전체 중지)가 허용될 수 있습니다.유닉스에서 선행 기간은 파일이나 폴더가 일반적으로 숨겨져 있음을 의미합니다.
, 쉼표를 허용되지만 명령줄 인터프리터 COMMAND에서는 구분 기호로 처리됩니다.COM과 CMD.도스와 윈도우에서 EXE.
; 세미콜론의 허용되지만 명령줄 인터프리터 COMMAND에서는 구분 기호로 처리됩니다.COM과 CMD.도스와 윈도우에서 EXE.
= 등호 허용되지만 명령줄 인터프리터 COMMAND에서는 구분 기호로 처리됩니다.COM과 CMD.도스와 윈도우에서 EXE.
공간
허용되지만, 공간은 명령줄 응용 프로그램에서 매개 변수 구분자로 사용되기도 합니다.이는 전체 파일명을 인용함으로써 해결할 수 있습니다.

참고 1: 대부분의 유닉스 셸은 유닉스 파일 및 폴더 이름에서 허용되지만, 공백, <, >, <, >, \, &, # 등의 특정 문자와 ?, * 등의 와일드카드를 따옴표로 붙이거나 빼야 합니다.

five\ and\ six\<seven(탈출example)
'five and six<seven'아니면"five and six<seven"(견적examples)

문자 Å(0xE5)는 86-DOS 및 MS-DOS/PC DOS 1.x-2.x 아래의 파일 이름의 첫 글자로 허용되지 않았지만 이후 버전에서 사용할 수 있습니다.

Windows 유틸리티에서는 공백과 마침표를 파일 이름의 마지막 문자로 사용할 수 없습니다.[18]마침표는 첫 번째 문자로 허용되지만 Windows 탐색기와 같은 일부 Windows 응용 프로그램에서는 숨겨진 파일 및 디렉토리를 설명하기 위해 유닉스 계열 시스템에서 사용되는 이 규칙에도 불구하고 파일을 만들거나 이름을 바꾸는 것을 금지합니다.해결 방법으로는 파일 이름을 바꿀 때 점을 추가하거나(이후 자동으로 제거됨), 대체 파일 관리자를 사용하거나 명령줄을 사용하여 파일을 만들거나 원하는 파일 이름을 가진 파일을 응용 프로그램에 저장하는 것이 있습니다.[19]

특정 운영 체제의 일부 파일 시스템(특히 다른 운영 체제에서 원래 구현된 파일 시스템)과 해당 운영 체제의 특정 응용 프로그램은 추가적인 제한과 해석을 적용할 수 있습니다.제한에 대한 자세한 내용은 파일 시스템 비교를 참조하십시오.

유닉스 계열 시스템, 도스, 윈도우에서 파일 이름은 "."와 "..." 특별한 의미(현재 디렉토리와 부모 디렉토리 각각)를 갖습니다.또한 Windows 95/98/ME에서는 조부모 또는 증조부모 디렉토리를 나타내는 "...", "..." 등의 이름을 사용합니다.[20]모든 Windows 버전은 점으로만 구성된 파일 이름을 만드는 것을 금지하고 있지만 유닉스에서는 세 개 이상의 점으로 구성된 이름("...")이 합법적입니다.

또한 Windows 및 DOS 유틸리티에서는 일부 단어도 예약되어 있으므로 파일 이름으로 사용할 수 없습니다.[19]예를 들어, DOS 장치 파일:[21]

CON, CONIN$, CONOUT$, PRN, AUX, CLOCK$, NUL COM0, COM1, COM2, COM3, COM4, COM5, COM6, COM8, COM9[7] LPT0, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9<[7] LST(86-DOS 및 DOS 1.xx에만 해당), SCREEN$(멀티태스킹 MS-DOS 4.0에만 해당)$IDLE$(동시 도스 386, 멀티유저 도스DR DOS 5.0 이상에만 해당) 구성$(MS-DOS 7에만 해당).0-8.0)

이러한 제한이 있는 시스템은 일부 다른 파일 시스템과 호환되지 않습니다.예를 들어, Windows에서는 이러한 합법적인 UNIX 파일 이름(aux.c,[22] q"uote"s)을 처리하지 못하거나 오류 보고서를 표시하지 못합니다.txt, 또는 NUL.txt.

내부적으로 사용되는 NTFS 파일 이름은 다음과 같습니다.

$Mft, $MftMirr, $LogFile, $Volume, $AtrDef, $Bitmap, $Boot, $BadClus, $Secure, $Upcase, $Extend, $Quota, $ObjId 및 $Reparse

파일 이름 제한 비교

시스템. 사례.
예민한
사례.
보존하고 있는
허용 문자 집합 예약문자 예약어 최대 길이(문자) 평.
8비트 FAT ? ? 7비트 ASCII(바이트로 저장됨) 첫 번째 문자는 0x00 또는 0xFF가 될 수 없습니다. 9 연속 파일(확장자 없음)의 경우 최대 9자의 기본 이름 제한 또는 이진 파일의 경우 최대 6자 및 3자 확장자 제한(6.3 파일 이름 참조)
FAT12, FAT16, FAT32 아니요. 아니요. SBCS/DBCS OEM 코드 페이지 0x00–0x1F 0x7F " * / : < > ? \ + , . ; = [ ](일부 환경에서도:! @; DOS 1/2에서 0xE5를 첫 번째 문자로 허용하지 않음) 장치 이름: $IDLE$ AUX COM1...COM4 CON CONFIG$ CLOCK$ KEYBD$ LPT1...LPT4 LST NUL PRN SCREEN$(depending 켜짐)AVAILDEV상태 어디에서나 또는 가상에서만\DEV\디렉토리) 11 최대 8자 기본 이름 제한 및 3자 확장(8.3 파일 이름 참조)
VFAT 아니요. 네. 유니코드, UCS-2 인코딩 사용 0x00–0x1F 0x7F " * / : < > ? \ 255
지방이 많은 아니요. 네. 유니코드, UTF-16 인코딩 사용 0x00–0x1F 0x7F " * / : < > ? \ 255
NTFS 선택적. 네. 유니코드, UTF-16 인코딩 사용 0x00–0x1F 0x7F " * / : < > ? \ 루트 디렉터리에만 있습니다: $AttrDef $BadClus $Bitmap $Boot $LogFile $MFT $MFTMirr 페이지 파일입니다.sys $Secure $UpCase $Volume $Extend $Extend\$ObjId $Extend\$Quota $Extend\$Reparse($Extend는 디렉토리입니다) 255 경로는 최대 32,000자까지 가능합니다.

이름이 Posix 네임스페이스에 있는 것으로 플래그를 지정하지 않는 한 1-31(0x01–0x1F) 범위의 문자와 " * / : < > ? \"를 사용할 수 없습니다.NTFS는 각 경로 구성 요소(디렉토리 또는 파일 이름)의[dubious ] 길이를 255자로 허용합니다.

Windows에서는 긴 UNC 경로(예: \\\)를 사용하는 경우를 제외하고는 확장자가 있는 이러한 이름(예: AUX.txt)뿐만 아니라 AUX, CLOCK$, COM0, COM9, CON, LPT0, ..., LPT9, NUL 및 PRN의 사용을 금지합니다.\C:\nul.txt 또는 \\?\D:\aux\con).(CLOCK$는 연장이 제공되는 경우 사용할 수 있습니다.)Win32 API는 UNC 경로가 사용되는 경우를 제외하고 파일 이름에서 후행 주기(전체 중지) 및 선행 및 후행 공백 문자를 제거합니다.이러한 제한 사항은 Windows에만 적용되며 NTFS를 지원하는 Linux 배포판에서는 / 및 NUL을 제외한 모든 유니코드 문자를 허용하는 NTFS의 Posix 네임스페이스를 사용하여 파일 이름을 작성합니다.

OS/2 HPFS 아니요. 네. 임의 8비트 세트 \?*<":>/ 254
맥 OS HFS 아니요. 네. 임의 8비트 세트 : 255 파인더의 이전 버전은 31자로 제한됩니다.
HFS+ 선택적. 네. 유니코드, UTF-16 인코딩 사용 : 디스크, 클래식 Mac OS 및 Mac OS의 카본 계층에서, / macOS의 Unix 계층에서 255 Mac OS 8.1 - macOS
APFS 선택적. 네. 유니코드, UTF-8 인코딩[23] 사용 Finder에서 /를 포함하는 파일 이름을 만들 수 있지만 /는 파일 시스템에 콜론(:)으로 저장되어 명령줄에 표시됩니다.명령줄에서 생성된 :를 포함하는 파일 이름은 파인더에 : 대신 /로 표시되므로 파인더에 파일 이름에 :가 있는 것으로 표시되는 파일은 만들 수 없습니다. 255 macOS 시에라(10.12.4) 이상, iOS 10.3 이상, tvOS 10.2 이상, watch OS 3.2 이상, iPadOS
대부분의 UNIX 파일 시스템 네. 네. 임의 8비트 세트 / 귀무의 255 의 앞줄은 …임을 나타냄ls파일 관리자는 기본적으로 파일을 표시하지 않습니다.
z/OS 클래식 MVS 파일 시스템(데이터 세트) 아니요. 아니요. EBCDIC 코드 페이지 $# @ - x'C0' 이외의 항목 44 첫 번째 문자는 알파벳 또는 국가($, #, @)여야 합니다.

"적격" 포함. 8자 이하의 숫자가 나올 때마다.[1]분할 데이터 세트(PDS 또는 PDSE)는 최대 8자의 이름을 가진 멤버로 분할됩니다. 멤버 이름은 PDS 이름 뒤에 괄호로 표시됩니다.PAYROLL.DEV.CBL(PROG001)

CMS 파일 시스템 아니요. 아니요. EBCDIC 코드 페이지 8 + 8 디스크 문자(A~Z)가 있는 단일 레벨 디렉토리 구조.최대 8자 파일 이름과 최대 8자 파일 형식, 공백으로 구분됩니다.예를 들어 디스크 A의 MEMO라는 텍스트 파일은 "MEMO TEXT A"로 액세스됩니다. (이후 버전의 VM은 계층적 파일 시스템 구조, SFS 및 BFS를 도입했지만 원래 플랫 디렉토리 "minidisk" 구조는 여전히 널리 사용됩니다.)
초기 UNIX (AT&T Corporation) 네. 네. 임의 8비트 세트 / 14 선두 .는 "숨겨진" 파일을 나타냅니다.
POSIX "완전 휴대용 파일 이름"[24] 네. 네. A–Z a–z 0–9 . _ - / 귀무의 14 하이픈은 첫 번째 문자가 아니어야 합니다.적합성을 검사하는 명령줄 유틸리티 "pathchk"는 IEEE 1003.1 표준 및 Open Group Base Specifications의[25] 일부입니다.
ISO 9660 아니요. ? A–Z 0–9 _ . "180에 근접"(레벨 2) 또는 200(레벨 3) CD에 사용, 최대 8개의 디렉토리 레벨(레벨 2,3이 아닌 레벨 1의 경우)
아미가 OFS 아니요. 네. 임의 8비트 세트 : / null 30 원본 파일 시스템 1985
아미가 FFS 아니요. 네. 임의 8비트 세트 : / null 30 빠른 파일 시스템 1988
아미가 PFS 아니요. 네. 임의 8비트 세트 : / null 107 프로페셔널 파일 시스템 1993
아미가 SFS 아니요. 네. 임의 8비트 세트 : / null 107 스마트 파일 시스템 1998
아미가 FFS2 아니요. 네. 임의 8비트 세트 : / null 107 고속 파일 시스템 2 2002
BeOS BFS 네. 네. 유니코드, UTF-8 인코딩 사용 / 255
DEC PDP-11 RT-11 아니요. 아니요. RADIX-50 6 + 3 서브디어가 없는 플랫 파일 시스템.전체 "파일 사양"은 장치, 파일 이름 및 확장자(파일 유형)를 dev:filnam.ext 형식으로 포함합니다.
DEC VAX VMS 아니요. 부터
v7.2
A–Z 0–9 $ - _ 구성 요소당 32개, 이전 구성 요소당 9개, 이후에는 파일 이름이 255개, 확장자가 32개입니다. 파일명, 디스크명, 디렉토리/ies, 파일명, 확장자, 버전을 포함한 전체 파일명:OURNODE::MYDISK:[THISDIR.THATDIR]FILENAME.EXTENSION;2디렉터리는 8층까지만 들어갈 수 있습니다.
코모도어 도스 네. 네. 임의 8비트 세트 :, = $ 16 길이는 드라이브에 따라 다릅니다. 보통 16.
HP 250 네. 네. 임의 8비트 세트 SPACE ", : NULL CHR$(255) 6 디스크와 테이프 드라이브는 라벨(최대 8자) 또는 단위 사양을 사용하여 주소를 지정합니다.HP 250 파일 시스템은 디렉토리를 사용하지 않으며 파일 형식을 나타내는 확장자도 사용하지 않습니다.대신 유형은 속성(예: 데이터 파일, 프로그램 파일, 백업 및 OS 자체의 DATA, PROG, BKUP 또는 SYST)입니다.[26]

참고 항목

참고문헌

  1. ^ a b c d "Data Set Naming Rules". z/OS TSO/E User's Guide. IBM.
  2. ^ "Data Set Naming Conventions". z/OS TSO/E User's Guide. IBM.
  3. ^ File Transfer Protocol (FTP). doi:10.17487/RFC0959. RFC 959.
  4. ^ "CPM - CP/M disk and file system format".
  5. ^ "Fsutil command description page". Microsoft.com. Archived from the original on October 6, 2013. Retrieved September 15, 2013.
  6. ^ "NTFS Hard Links, Directory Junctions, and Windows Shortcuts". Flex hex. Inv Softworks. Archived from the original on July 11, 2011. Retrieved March 12, 2011.
  7. ^ a b c d "Naming Files, Paths, and Namespaces". December 15, 2022. Retrieved October 8, 2023.
  8. ^ "Maximum Path Length Limitation - Win32 apps". July 18, 2022.
  9. ^ a b c d e David Robinson; Ienup Sung; Nicolas Williams (March 2006). "Solaris presentations: File Systems, Unicode, and Normalization" (PDF). San Francisco: Sun.com. Archived from the original (PDF) on July 4, 2012.
  10. ^ "Filenames with accents". Ned Batchelder. June 2011. Retrieved September 17, 2013.
  11. ^ "NonNormalizingUnicodeCompositionAwareness - Subversion Wiki". Wiki.apache.org. January 21, 2013. Retrieved October 8, 2023.
  12. ^ "File Name Encoding Repair Utility v1.0". Support.apple.com. June 1, 2006. Retrieved October 2, 2018.
  13. ^ "convmv - converts filenames from one encoding to another". J3e.de. Retrieved September 17, 2013.
  14. ^ "Re: git on MacOSX and files with decomposed utf-8 file names". KernelTrap. May 7, 2010. Archived from the original on March 15, 2011. Retrieved July 5, 2010.
  15. ^ "Cross platform filepath naming conventions - General Programming". GameDev.net. Retrieved October 8, 2023.
  16. ^ "CaseInsensitiveFilenames - The Official Wine Wiki". Wiki.winehq.org. November 8, 2009. Archived from the original on August 18, 2010. Retrieved August 20, 2010.
  17. ^ "The Open Group Base Specifications Issue 6". IEEE Std 1003.1-2001. The Open Group. 2001.
  18. ^ "Windows 이름 지정 규칙".MSDN, Microsoft.com .마지막 글머리표 항목 참조.
  19. ^ a b MSDN(msdn.microsoft.com ) 파일 이름 지정, Windows의 파일 이름 제한
  20. ^ Microsoft Windows 95 README for Tips and Tricks, Microsoft, archived from the original on November 1, 2014
  21. ^ MS-DOS Device Driver Names Cannot be Used as File Names, Microsoft, archived from the original on March 20, 2014
  22. ^ Ritter, Gunnar (January 30, 2007). "The tale of "aux.c"". Heirloom Project.
  23. ^ "Apple File System Reference" (PDF). Apple Inc.
  24. ^ 르윈, 도날드.POSIX 프로그래머 가이드: 휴대용 UNIX 프로그램 1991 O'Reilly & Associates, Inc. 작성세바스토폴, 캡 63-64
  25. ^ pathchk - 경로 이름 확인
  26. ^ 휴렛패커드사 로즈빌, CA HP 250 신택스 참조 Rev 1/84 수동 부품 no 45260-90063

외부 링크