맨위로가기

파일 이름

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

파일 이름은 컴퓨터 시스템에서 파일을 식별하는 데 사용되는 문자열로, 파일의 접근 방법, 호스트, 장치, 디렉터리, 기본 이름, 확장자, 버전 등의 구성 요소를 가질 수 있다. 초기 시스템에서는 파일 이름 길이에 제한이 있었으나, 현대 운영체제에서는 유니코드 지원을 통해 긴 파일 이름 사용이 가능해졌다. 파일 이름 명명 규칙과 제한은 운영 체제 및 파일 시스템에 따라 다르며, 파일 이름 인코딩 및 상호 운용성 문제 해결을 위해 유니코드가 널리 사용된다. 파일 이름은 해당 디렉토리 내에서 고유해야 하며, 대소문자 구분 여부는 파일 시스템에 따라 다르다.

더 읽어볼만한 페이지

  • 파일 이름 - 긴 파일 이름
    긴 파일 이름은 FAT 파일 시스템에서 긴 파일 이름을 지원하기 위해 사용되는 기술이며, 마이크로소프트는 VFAT 규칙을 통해 호환성을 확보하고 윈도우 95에서 처음 LFN을 도입했다.
  • 파일 이름 - 8.3 파일 이름
    8.3 파일 이름은 도스 운영체제에서 파일 이름을 8자 본문과 3자 확장자로 제한한 규칙으로, 기술적 제약 극복과 파일 시스템 단순성 유지를 위해 도입되었으며 윈도우에서도 호환성을 위해 지원되고 NTFS에서도 레거시 응용 프로그램과의 호환성을 위해 사용된다.
  • 기록 관리 - 정보 아키텍처
    정보 아키텍처는 정보 시스템 및 정보 기술 분야에서 공유 정보 환경의 구조적 설계를 의미하며, 웹사이트, 소프트웨어 등의 구성과 레이블링을 포함하여 검색 용이성과 사용성을 지원하고, 도서관정보학에 기원을 두고 있다.
  • 기록 관리 - 파일 호스팅 서비스
    파일 호스팅 서비스는 사용자가 파일을 온라인 서버에 저장하고 접근하도록 지원하며, 이동식 미디어 대체, 백업, 파일 전송, 공유 등의 용도로 사용된다.
파일 이름

2. 역사

파일 이름의 역사는 운영체제의 발전과 밀접하게 관련되어 있다. 초기 컴퓨터 시스템에서는 파일 이름의 길이와 사용 가능한 문자가 매우 제한적이었으나, 기술 발전과 함께 이러한 제한이 점차 완화되었다.

1985년에는 IETF에서 ''경로명''을 파일을 식별하기 위해 사용자가 파일 시스템에 입력해야 하는 문자열로 공식 정의했다.[4]

Standalone Disk BASIC-80에서 사용된 원본 파일 할당 테이블(FAT) 파일 시스템은 6.3 파일 이름을 사용했으며, 이름에 최대 6바이트, 확장자에 최대 3바이트를 할당했다. FAT 파일 시스템은 8비트 문자를 지원하여 파일 이름에 비 ASCII 문자를 포함할 수 있었고, 파일 속성은 파일 이름과 별도로 저장했다.

2. 1. 초기 시스템

1970년대에 일부 메인프레임미니컴퓨터는 시스템 상의 파일을 사용자 이름 또는 계정 번호로 식별하는 운영 체제를 사용했다.[2]

예를 들어, 디지털 이큅먼트 코퍼레이션의 TOPS-10 및 RSTS/E 운영 체제에서 파일은 다음과 같이 식별되었다.

구성 요소설명
선택적 장치 이름1~2자, 선택적 유닛 번호와 콜론(":")이 붙음. 없는 경우 SY:로 간주.
계정 번호"[", 쉼표로 구분된 두 개의 숫자 쌍, "]"로 구성. 생략되면 본인 계정으로 간주.
필수 파일 이름1~6자의 문자(대문자 또는 숫자)로 구성.
선택적 3자 확장자파일의 종류나 형식을 나타내는 3자.



IBM의 OS/VS1, MVS, OS/390 운영 체제에서 파일 이름은 최대 44자였으며, 대문자, 숫자 및 마침표로 구성되었다. 파일 이름은 문자 또는 숫자로 시작해야 하며, 마침표는 각 8자마다 한 번 이상 나타나야 하고, 두 개의 연속된 마침표는 이름에 나타날 수 없으며, 문자 또는 숫자로 끝나야 했다.[3]

CP/M 운영 체제를 사용하는 초기의 개인용 컴퓨터에서 파일 이름은 항상 11자였다. 이는 최대 8바이트 이름과 최대 3바이트 확장자를 가진 8.3 파일 이름으로 언급되었다. IBM PC DOS/MS-DOS 및 Windows 95 이전의 마이크로소프트 윈도의 FAT12 및 FAT16 파일 시스템은 CP/M 파일 시스템과 동일한 8.3 규칙을 사용했다.

2. 2. 현대 시스템

1995년경, MS-DOS FAT 파일 시스템의 확장인 VFAT가 Windows 95 및 Windows NT에 도입되었다. 이는 고전적인 "8.3" 이름 외에 혼합된 대소문자의 긴 파일 이름 (LFN)을 유니코드 문자를 사용하여 허용했다.

3. 파일 이름의 구성 요소

파일 이름은 프로토콜, 호스트, 장치, 디렉터리, 기본 파일 이름, 종류(확장자), 버전 등의 요소로 구성될 수 있다.

일부 파일 시스템은 파일 이름의 길이를 제한한다. 예를 들어, IBM z/OS에서는 전체 파일 이름이 44자까지로 제한될 수 있다.[2] 다른 경우에는 길이 제한이 파일 이름의 특정 부분에 적용될 수 있는데, 예를 들어 DOS의 FAT12, FAT16, FAT32에서는 11자, 초기 Unix에서는 14자, Apple ProDOS에서는 15자 등으로 제한되었다.[2] 이러한 길이 제한은 파일 시스템에서 이름 구성 요소를 저장하기 위해 고정된 공간을 할당하기 때문에 발생하며, 제한을 늘리려면 더 많은 공간을 확보해야 하는 경우가 많다.

정보를 중첩된 디렉터리에 저장하는 파일 시스템에서는 전체 경로 이름이 구현 제한을 초과하는 파일을 생성하는 문제가 발생할 수 있다. 이는 길이 검사가 전체 이름이 아닌 이름의 개별 부분에만 적용될 수 있기 때문이다. 많은 Windows 응용 프로그램은 260자의 `MAX_PATH` 값으로 제한되지만, Windows 파일 이름은 이 제한을 쉽게 초과할 수 있다.[8] Windows 10, 버전 1607부터는 MAX_PATH 제한이 제거되었다.[9]

3. 1. 프로토콜 (스키마)

프로토콜(스키마라고도 함)은 파일에 접근하는 방법을 나타낸다. 예를 들어 http, ftp, file, smb 등이 있다.

3. 2. 호스트 (네트워크 ID)


  • 호스트 (네트워크 ID의 경우도) — 호스트 이름, IP 주소, 도메인 이름, LAN 네트워크 이름
  • 예: `wikipedia.org`, `207.142.131.206`, `\\MYCOMPUTER`, `SYS:` 등

3. 3. 장치 (노드)


  • '''장치''' (노드라고도 함)는 포트, 소켓, 드라이브, 루트 마운트 포인트, 디스크, 볼륨 등을 나타낸다.
  • 예: `C:`, `/`, `SYSLIB`[30]

3. 4. 디렉터리 (경로)

파일 이름에서 디렉터리(경로)는 디렉터리 트리를 나타낸다.

  • 예: `/usr/bin`, `\TEMP`, `[USR.LIB.SRC]` 등

3. 5. 기본 파일 이름 (베이스 파일 이름, 스템)

베이스 파일 이름(스템)은 확장자를 제외한 파일의 주된 이름을 나타낸다. 예를 들어 `C:\hoge\fuga.txt`에서 `fuga`가 베이스 파일 이름에 해당한다.

POSIX에는 경로 구분 문자 `/`로 분할된 마지막 요소를 반환하는 `basename`이라는 명령 및 시스템 콜이 있다. 이들은 확장자를 포함한 파일 이름을 반환한다. 명령어는 `.txt`와 같은 확장자를 제거하는 옵션을 지정할 수도 있지만, 임의의 확장자를 일률적으로 제거할 수 있는 것은 아니다.

Java에서는 `getName()` 또는 `getFileName()`을 사용하여 이름 구분 문자로 분할된 마지막 요소를 가져올 수 있다.

3. 6. 확장자 (종류, 형식)

파일 시스템에서 파일 이름은 "기본 이름" 또는 "스템"과 파일 형식을 나타내는 "확장자" 또는 "접미사"의 두 부분으로 구성될 수 있다. 예를 들어 FAT와 Files-11의 ODS-1 및 ODS-2 레벨에서 파일 이름은 두 부분으로 구성된다. 유닉스 파일 시스템, VFAT, NTFS와 같은 다른 파일 시스템은 파일 이름을 단일 문자열로 취급하지만, 마침표가 포함된 파일 이름에서 마지막 마침표 뒤의 문자를 파일 이름의 확장자 부분으로 취급하는 규칙을 사용하기도 한다.

애플리케이션에서 생성된 여러 개의 출력 파일은 동일한 기본 이름과 다양한 확장자를 사용할 수 있다. 예를 들어, 포트란 컴파일러는 소스 입력 파일에 `FOR` 확장자를, 개체 출력에 `OBJ` 확장자를, 리스팅에 `LST` 확장자를 사용할 수 있다. 확장자는 일반적으로 `html`과 같이 임의의 길이를 가질 수 있지만, 역사적으로 일부 시스템에서는 3자 길이로 제한되었다.

파일 이름의 구성 요소 중 종류(형식 또는 확장자)는 파일의 내용 종류를 나타낸다. 예를 들어 `.txt`, `.exe`, `.dir`, `.html` 등이 있다.

3. 7. 버전

버전은 파일의 버전을 나타내는 번호이다.

4. 파일 이름 명명 규칙 및 제한 사항

'five and six

윈도우에서 공백과 온점은 파일 이름의 마지막에 허용하지 않는다. 온점은 파일 이름의 처음에는 허용하지만 윈도우 탐색기와 같은 일부 윈도 응용 프로그램은 이러한 파일의 이름을 만들거나 이름을 바꾸는 것을 금지한다. (유닉스 계열 운영 체제에서는 숨김 파일 및 디렉터리를 기술하는 데 사용하는 변환이기는 하다)

유닉스 계열 운영 체제, MS-DOS, 윈도우에서 파일 이름 "."와 ".."는 특별한 의미가 있다. (각각 현재 및 부모 디렉터리).

그뿐 아니라 윈도와 도스에서 일부 글자는 파일 이름으로 금지되어 사용할 수 없다.[45] 이를테면 도스 장치 파일이 그러하다:

CON, PRN, AUX, CLOCK$, NUL

COM0, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9

LPT0, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9.

시스템대소문자 구별허용 문자 집합금칙 문자금칙 단어최대 길이
MS-DOS 파일 할당 테이블대소문자 구별 안 함 / 구별된 대소문자 보존 안 함모두0x00-0x1F SPACE DEL " * / : < > ? \>장치 이름: AUX COM1 COM2 COM3 COM4 COM5 COM6 COM7 COM8 COM9 CON LPT1 LPT2 LPT3 LPT4 LPT5 LPT6 LPT7 LPT8 LPT9 NUL PRN11
코모도어 64대소문자 구별함 / 구별된 대소문자 보존모두:,=$16
Win95 VFAT대소문자 구별 안 함모두?*<":>+[]/ 제어 문자255
NTFS선택 사항 (구별된 대소문자 보존)모두 (유니코드 문자 포함)/ null (이를테면 0x00)루트 디렉터리만: $AttrDef $BadClus $Bitmap $Boot $LogFile $MFT $MFTMirr pagefile.sys $Secure $UpCase $Volume $Extend $Extend\$ObjId $Extend\$Quota $Extend\$Reparse ($Extend는 디렉터리)255
OS/2 HPFS대소문자 구별 안 함 / 구별된 대소문자 보존모두?*<":>/254
맥 OS HFS대소문자 구별 안 함 / 구별된 대소문자 보존모두:255
맥 OS HFS+선택 사항 (구별된 대소문자 보존)모두: 디스크, 고전 맥 OS, OS X의 카본 계층에서 / OS X 유닉스 계층에서255
대부분의 유닉스 파일 시스템대소문자 구별함 / 구별된 대소문자 보존모두/ null255
초기 UNIX (AT&T)대소문자 구별함 / 구별된 대소문자 보존모두/14
POSIX "완전히 이식 가능한 파일 이름"[46]대소문자 구별함 / 구별된 대소문자 보존A–Za–z0–9._-/ null다음을 포함하지 않는 파일 이름: a.out, core, .profile, .history, .cshrc14
아미가OS대소문자 구별 안 함 / 구별된 대소문자 보존모두:/"107
아미가 OFS대소문자 구별 안 함 / 구별된 대소문자 보존모두:/"30
아미가 FFS대소문자 구별 안 함 / 구별된 대소문자 보존모두:/"30
아미가 PFS대소문자 구별 안 함 / 구별된 대소문자 보존모두:/"255
아미가 SFS대소문자 구별 안 함 / 구별된 대소문자 보존모두:/"32,000
아미가 FFS2대소문자 구별 안 함 / 구별된 대소문자 보존모두:/"107
BeOS BFS대소문자 구별함UTF-8/255
DEC PDP-11 RT-11대소문자 구별 안 함RADIX-506 + 3
DEC VAX VMS대소문자 구별 안 함A–Z 0–9 $ - _한 요소에 32개. 초기에는 9개로 제한되었으나 나중에는 파일 이름의 경우 255개, 확장자의 경우 32개로 늘어남.
ISO 9660대소문자 구별 안 함A–Z 0–9 _ .255



파일 이름으로 사용할 수 없는 기호와 사용할 수 없는 이유를 다음 표에 나타낸다.

기호기호명사용할 수 없는 이유
/슬래시경로명 구성 요소 구분 기호로, UNIX 등의 OS나 MS-DOS 및 윈도우에서는 사용할 수 없다.
\백슬래시경로명 구성 요소 구분 기호로, MS-DOS와 Windows에서는 사용할 수 없다.
?물음표와일드카드(불특정을 나타내는 기호)로 사용되므로, Windows와 AmigaOS에서는 사용할 수 없다.
*별표와일드카드로 사용되므로, MS-DOS와 Windows에서는 사용할 수 없다.
:콜론드라이브 문자에 사용되거나 경로명 구분 기호이기 때문에, Windows, AmigaOS, Mac OS에서는 사용할 수 없다.
>세로 막대
"따옴표공백을 포함하는 파일 이름의 시작과 끝을 지정하는 데 사용되므로, Windows에서 사용할 수 없다.
<작음 기호
>큼 기호
.마침표8.3 형식에서는 2개 이상의 마침표를 사용할 수 없으며, 파일 이름의 처음이나 마지막에 마침표를 사용할 수도 없다.
반각 공백 (꼬리)8.3 형식을 다루는 데이터 구조상의 이유로 인해 MS-DOS에서 사용할 수 없다.
영문 소문자CD-ROM용 파일 시스템 중 ISO 9660 Level 1에서는 사용할 수 없다. MS-DOS에서는 읽기/쓰기 불능으로 사용할 수 없다.


5. 파일 이름 인코딩 및 상호 운용성

파일 이름 인코딩은 파일 시스템 간, 운영 체제 간, 또는 다른 소프트웨어 환경 간에 파일을 교환할 때 중요한 문제이다. 파일 이름에 대한 일반적인 인코딩 표준은 없기 때문에, 파일을 주고받을 때 파일 이름 정보가 손실되지 않도록 하는 것이 중요하다.

전통적으로 파일 시스템은 파일 이름에 모든 문자를 허용하여[10] 다양한 인코딩을 사용할 수 있었지만, 이는 여러 상호 운용성 문제를 야기했다. 예를 들어, 일본에서 Shift JIS 인코딩을 사용하는 시스템과 EUC 인코딩을 사용하는 시스템 간에 파일을 교환할 때, 파일 이름이 깨지는 문제가 발생할 수 있었다. 대부분의 시스템이 파일 이름에 사용된 인코딩 정보를 제공하지 않았기 때문에, 파일 이름을 올바르게 해석하기 위해서는 각 파일에 접근할 때마다 인코딩을 추측해야 하는 번거로움이 있었다.[10]

이러한 문제를 해결하기 위해 유니코드가 파일 이름 인코딩 표준으로 널리 채택되었다. 클래식 Mac OS에서는 파일 이름의 인코딩이 파일 속성과 함께 저장되기도 했다.[10]

5. 1. 유니코드

유니코드 표준은 파일 이름 인코딩 문제에 대한 해결책을 제시한다.

하지만 정규화(동등성) 또는 사용 중인 유니코드 버전과 같은 몇 가지 상호 운용성 문제가 여전히 존재한다. 예를 들어, UDF는 유니코드 2.0으로 제한된다. macOS의 HFS+ 파일 시스템은 NFD 유니코드 정규화를 적용하며, 선택적으로 대소문자를 구분한다(기본적으로 대소문자를 구분하지 않음). 파일 이름 최대 길이는 표준이 아니며 코드 단위 크기에 따라 달라질 수 있다.[10]

리눅스에서는 파일 이름을 사용하는 것만으로는 파일을 열기에 충분하지 않다. 저장 장치에 있는 파일 이름의 정확한 바이트 표현 또한 필요하다. 이 문제는 응용 프로그램 수준에서 몇 가지 까다로운 정규화 호출을 통해 해결할 수 있다.[11]

유니코드 동등성 문제는 "정규화된 이름 충돌"이라고 알려져 있다. 이에 대한 해결책으로 Subversion 및 Apache 기술 커뮤니티에서는 ''비정규화 유니코드 구성 인식''을 사용한다.[12] 이 솔루션은 저장소의 경로를 정규화하지 않고, 비교 목적으로만 정규화한다. 그럼에도 불구하고, 일부 커뮤니티에서는 이 전략에 대한 특허를 취득하여 다른 커뮤니티에서 사용하는 것을 금지했다.

Sun에서는 상호 운용성 문제를 해결하기 위해 다음과 같은 방법을 제시했다.

  • 하나의 유니코드 인코딩(예: UTF-8) 사용
  • 파일 이름에 대한 투명한 코드 변환 수행
  • 정규화된 파일 이름 저장하지 않음
  • 동일한 디렉토리에 두 개의 정규 동등한 파일 이름이 없도록 파일 이름 간의 정규 동등성을 확인[10]


이러한 고려 사항은 UTF-8과 다른 미래의 인코딩으로 전환하는 것을 제한한다.

유니코드 마이그레이션 또한 문제였다. 이를 위해 여러 소프트웨어 회사들이 파일 이름을 새로운 유니코드 인코딩으로 마이그레이션하기 위한 소프트웨어를 제공했다.

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


Mac OS X 10.3은 이전의 유니코드 2.1 분해를 대체하며, 애플이 유니코드 3.2 문자 분해를 채택한 것을 나타냈다. 이 변화는 Mac OS X용 소프트웨어를 개발하는 개발자들에게 문제를 일으켰다.[15]

6. 파일 이름의 유일성

하나의 디렉터리 내에서 파일 이름은 고유해야 한다. 파일 이름 구문은 디렉터리에도 적용되므로, 단일 디렉터리 내에서 동일한 이름의 파일과 디렉터리 항목을 생성하는 것은 불가능하다. 서로 다른 디렉터리에 있는 여러 파일은 동일한 이름을 가질 수 있다.[16]

고유성 접근 방식은 대소문자 구분 및 유니코드 정규화 형태 (예: NFC, NFD)에 따라 다를 수 있다. 즉, L"\x00C0.txt" (UTF-16, NFC) (무덤이 있는 라틴 대문자 A) 및 L"\x0041\x0300.txt" (UTF-16, NFD) (라틴 대문자 A, 결합된 무덤)과 같이 동일한 텍스트 파일 이름과 다른 바이트 구현을 가진 두 개의 별도 파일을 생성할 수 있다.[16]

일반적으로 하나의 컴퓨터에 동일한 전체 경로를 가진 파일이 여러 개 존재하는 것은 불가능하다. 따라서, 저장 대상으로 이용하려는 스토리지 안에 동일한 전체 경로를 가진 파일이 이미 존재할 경우(동일한 상위 디렉터리에 완전히 똑같은 이름의 파일이 이미 존재할 경우) 덮어쓰기(덮어쓰기 저장)하거나, 다른 이름으로 저장하거나, 취소해야 한다. 파일 이름의 대소문자를 구별하지 않는 환경에서는 대소문자 차이만으로는 다른 이름이 되지 않고 같은 이름으로 취급된다.

구글 드라이브와 같은 일반적인 온라인 스토리지 서비스에서는 최종 사용자에게 표시되는 파일 이름은 편의상의 표시명(display name)에 불과하며, 내부적인 파일 이름과는 별개이다. 표시명을 변경해도 내부 이름은 바뀌지 않으며 변경 이력도 계승된다. 따라서 동일한 상위 폴더 내에 같은 이름을 가진 파일이 여러 개 존재할 수 있다.

7. 한국어 환경에서의 파일 이름 문제

(빈 텍스트)

참조

[1] 웹사이트 Fixing Unix/Linux/POSIX Filenames: Control Characters (such as Newline), Leading Dashes, and Other Problems https://dwheeler.com[...] 2023-08-22
[2] 웹사이트 Data Set Naming Rules https://www.ibm.com/[...] IBM
[3] 웹사이트 Data Set Naming Conventions https://www.ibm.com/[...] IBM
[4] 간행물 File Transfer Protocol (FTP)
[5] 웹사이트 CPM - CP/M disk and file system format https://www.cpm8680.[...]
[6] 웹사이트 Fsutil command description page http://www.microsoft[...] Microsoft.com 2013-09-15
[7] 웹사이트 NTFS Hard Links, Directory Junctions, and Windows Shortcuts http://www.flexhex.c[...] Inv Softworks 2011-03-12
[8] 웹사이트 Naming Files, Paths, and Namespaces https://learn.micros[...] 2022-12-15
[9] 웹사이트 Maximum Path Length Limitation - Win32 apps https://docs.microso[...] 2022-07-18
[10] 웹사이트 Solaris presentations: File Systems, Unicode, and Normalization http://developers.su[...] Sun.com 2006-03
[11] 웹사이트 Filenames with accents http://nedbatchelder[...] Ned Batchelder 2011-06
[12] 웹사이트 NonNormalizingUnicodeCompositionAwareness - Subversion Wiki https://cwiki.apache[...] Wiki.apache.org 2013-01-21
[13] 웹사이트 File Name Encoding Repair Utility v1.0 https://support.appl[...] Support.apple.com 2006-06-01
[14] 웹사이트 convmv - converts filenames from one encoding to another http://www.j3e.de/li[...] J3e.de
[15] 웹사이트 Re: git on MacOSX and files with decomposed utf-8 file names http://kerneltrap.or[...] KernelTrap 2010-05-07
[16] 웹사이트 Cross platform filepath naming conventions - General Programming https://www.gamedev.[...] GameDev.net
[17] 웹사이트 CaseInsensitiveFilenames - The Official Wine Wiki http://wiki.winehq.o[...] Wiki.winehq.org 2009-11-08
[18] 웹사이트 The Open Group Base Specifications Issue 6 http://pubs.opengrou[...] The Open Group
[19] MSDN Windows Naming Conventions http://msdn.microsof[...] Microsoft.com
[20] MSDN Naming a file http://msdn.microsof[...] msdn.microsoft.com
[21] citation Microsoft Windows 95 README for Tips and Tricks https://support.micr[...] Microsoft
[22] citation MS-DOS Device Driver Names Cannot be Used as File Names http://support.micro[...] Microsoft
[23] 웹사이트 The tale of "aux.c" http://heirloom.sour[...] 2007-01-30
[24] 웹사이트 Naming Files, Paths, and Namespaces - Win32 apps https://learn.micros[...] 2024-02-26
[25] 웹사이트 Apple File System Reference https://developer.ap[...] Apple Inc.
[26] 서적 POSIX Programmer's Guide: Writing Portable UNIX Programs O'Reilly & Associates, Inc.
[27] 문서 pathchk - check pathnames https://pubs.opengro[...]
[28] 문서 HP 250 Syntax Reference 1984-01
[29] 문서 path::filename - cpprefjp C++日本語リファレンス https://cpprefjp.git[...]
[30] 문서 §File and Directory Names : Naming Files, Paths, and Namespaces - Win32 apps | Microsoft Learn https://learn.micros[...]
[31] 문서 File input/output - cppreference.com https://en.cpprefere[...]
[32] 문서 CreateFileW function (fileapi.h) - Win32 apps | Microsoft Learn https://learn.micros[...]
[33] 문서 MoveFileW function (winbase.h) - Win32 apps | Microsoft Learn https://learn.micros[...]
[34] 문서 §Paths : Naming Files, Paths, and Namespaces - Win32 apps | Microsoft Learn https://learn.micros[...]
[35] 문서 §Short vs. Long Names : Naming Files, Paths, and Namespaces - Win32 apps | Microsoft Learn https://learn.micros[...]
[36] 뉴스 Apple、iOS 11を20日に提供開始 - 「Dock」「ファイル」など追加 | マイナビニュース https://news.mynavi.[...]
[37] 웹사이트 path::stem - cpprefjp C++日本語リファレンス https://cpprefjp.git[...]
[38] 간행물 basename — return non-directory portion of a pathname | The Open Group Base Specifications Issue 8 / IEEE Std 1003.1-2024 | The IEEE and The Open Group https://pubs.opengro[...]
[39] 간행물 basename — return the last component of a pathname | The Open Group Base Specifications Issue 8 / IEEE Std 1003.1-2024 | The IEEE and The Open Group https://pubs.opengro[...]
[40] 웹사이트 ASCII.jp:Windowsでファイルやフォルダーに「使わない方がいい」文字 (1/2) https://ascii.jp/ele[...]
[41] 웹사이트 Overview of FAT, HPFS, and NTFS File Systems - Windows Client | Microsoft Learn https://learn.micros[...]
[42] 웹사이트 Character Sets Used in File Names - Win32 apps | Microsoft Learn https://learn.micros[...]
[43] 웹사이트 §Naming Conventions : Naming Files, Paths, and Namespaces - Win32 apps | Microsoft Learn https://learn.micros[...]
[44] 웹인용 When did Windows start accepting forward slash as a path separator? - Python answers http://www.thescript[...] Thescripts.com 2005-07-18
[45] 웹사이트 Naming a file http://msdn.microsof[...]
[46] 서적 POSIX Programmer's Guide: Writing Portable UNIX Programs O'Reilly & Associates, Inc. 1991



본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com