파일 형식

wav 파일: 2.1 메가바이트.

ogg 파일: 154 킬로바이트.

파일 형식 또는 파일 포맷(file format)은 컴퓨터 파일에 저장하기 위해 정보를 인코딩하는 방식이다. 이는 저수준의 비트 및 바이트 레이아웃부터 마크업 및 테이블 구조와 같은 고수준의 조직에 이르기까지 다양한 추상화 수준에서의 인코딩을 설명할 수 있다. 파일 형식은 표준화될 수 있으며(이 경우 독점 또는 오픈 형식이 될 수 있음), 애드혹 관습일 수도 있다.

일부 파일 형식은 매우 특정한 유형의 데이터를 위해 설계되었다. 예를 들어 PNG 파일은 비손실 데이터 압축을 사용하여 비트맵 이미지를 저장한다. 반면에 다른 파일 형식은 여러 다른 유형의 데이터를 저장하도록 설계되기도 한다. Ogg 형식은 오디오와 비디오의 조합, 텍스트(예: 자막), 메타데이터를 포함한 다양한 유형의 멀티미디어를 담는 컨테이너 역할을 할 수 있다. 텍스트 파일은 가능한 제어 문자를 포함한 모든 문자 스트림을 포함할 수 있으며, 다양한 문자 인코딩 방식 중 하나로 인코딩된다. HTML, 스케일러블 벡터 그래픽스, 컴퓨터 소프트웨어의 소스 코드와 같은 일부 파일 형식은 정의된 구문을 가진 텍스트 파일로, 특정 목적에 사용될 수 있게 한다.

사양

일부 파일 형식은 해당 형식과 데이터의 정확성을 검증하는 방법을 설명하는 공개된 사양을 가지고 있다. 모든 형식에 대해 이러한 문서를 사용할 수 있는 것은 아니다(때로는 형식이 영업 비밀로 간주되기 때문이며, 때로는 문서 자체가 작성되지 않았기 때문이다). 때때로 형식은 해당 파일에 액세스하는 프로그램의 동작에 의해 데 팍토로 정의되기도 한다.

사용 가능한 사양이 없는 경우, 개발자는 해당 형식의 파일을 검사하여 형식을 역공학하거나, 비용을 지불하고 기밀유지 협약에 서명하여 사양을 획득할 수 있다. 이러한 접근 방식에 드는 시간과 비용 때문에, 공개적으로 사용 가능한 사양이 있는 파일 형식이 더 많은 프로그램에서 지원되는 경향이 있다.

지식 재산권 보호

파일 형식 고유의 지식 재산권을 보호하기 위해 (저작권보다는) 특허법이 사용될 수 있다. 미국 법률상 파일 형식 자체에 대한 특허는 직접적으로 허용되지 않지만, 일부 형식은 특허받은 알고리즘을 사용하여 데이터를 인코딩한다. 예를 들어 2004년 이전에는 GIF 파일 형식의 압축을 사용하려면 특허받은 알고리즘을 사용해야 했으며, 특허 소유자가 처음에는 특허권을 행사하지 않았으나 나중에 로열티를 징수하기 시작했다. 이는 GIF 사용의 급격한 감소를 초래했으며, 대체 형식인 PNG 형식이 개발되는 계기 중 하나가 되었다. 그러나 GIF 특허는 미국에서 2003년 중반에, 전 세계적으로는 2004년 중반에 만료되었다.

식별

사용자와 응용 프로그램 모두 파일을 적절하게 사용하기 위해 파일 형식을 식별할 필요가 있다. 일반적으로 식별 방법은 운영체제마다 다르며, 각 접근 방식은 장단점을 가지고 있다.

파일 확장자

 이 부분의 본문은 파일 확장자입니다.

Windows, macOS, CP/M, MS-DOS, OpenVMS, VM/CMS를 포함한 많은 운영체제에서 사용하는 널리 알려진 방법 중 하나는 확장자라고 알려진 파일 이름의 접미사로 파일 형식을 나타내는 것이다. 예를 들어, HTML 문서는 .html 또는 .htm으로 끝나는 파일 이름으로 식별되고, GIF 이미지는 .gif로 식별된다.

현재는 구식이 된 FAT 파일 시스템에서 파일 이름은 기본 이름 8자 더하기 3자의 확장자로 제한되었으며, 이를 8.3 파일 이름이라고 한다. 이러한 명명 체계의 유행으로 인해 현대의 시스템이 더 긴 확장자를 지원함에도 불구하고 많은 형식이 여전히 3자 확장자를 사용한다. 표준화된 확장자 목록이 없기 때문에 두 개 이상의 형식이 동일한 확장자를 사용할 수 있으며, 특히 3자 조합의 수는 제한되어 있기 때문에 3자 확장자에서 이러한 현상이 두드러진다. 이러한 상황은 사용자와 응용 프로그램 모두에게 혼란을 줄 수 있다.

확장자로 파일 유형을 나타내는 방식의 한 가지 영향은, 사용자와 응용 프로그램이 파일 이름만 바꿈으로써 파일을 다른 형식인 것처럼 취급하도록 속일 수 있다는 점이다. 예를 들어, HTML 파일에 확장자 filename.txt를 추가(또는 기존 확장자 변경)하여 플레인 텍스트로 취급하게 할 수 있다. 이 전략은 유용할 수 있지만, 실수로 파일을 사용할 수 없게 만들거나 파일을 "잃어버리는" 기술적 지식이 적은 사용자에게는 혼란을 줄 수 있다. 이러한 시나리오를 피하기 위해 Windows와 macOS는 확장자 숨기기 기능을 지원한다.

그러나 확장자를 숨기면 같은 폴더 내에 이름이 같은 여러 파일이 있는 것처럼 보일 수 있어 사람들에게 혼란을 준다. 예를 들어, 출판용 .eps 형식과 웹사이트용 .png 형식의 이미지가 모두 필요할 때, 기본 이름을 동일하게 지정할 수 있다(예: CompanyLogo.eps와 CompanyLogo.png). 확장자가 숨겨진 상태에서는 두 파일 모두 CompanyLogo라는 동일한 이름으로 나타난다.

확장자를 숨기는 것은 보안 위험을 초래할 수도 있다. 예를 들어, 악의적인 사용자가 "Holiday photo.jpg.exe"와 같이 무해해 보이는 이름의 실행 파일을 만들 수 있다. ".exe" 부분은 숨겨지고 의심하지 않는 사용자는 "Holiday photo.jpg"만 보게 되며, 이는 대개 시스템에 해를 끼칠 수 없는 JPEG 이미지처럼 보일 것이다. 그러나 운영체제는 여전히 ".exe" 확장자를 인식하고 프로그램을 실행하여 컴퓨터에 피해를 줄 수 있다. 확장자가 하나뿐인 파일도 마찬가지이다. 사용자에게 확장자가 표시되지 않으면 파일을 명시적으로 조사하지 않고는 파일에 대한 정보를 추론할 수 없다. 사용자를 더 속이기 위해 프로그램 내부에 아이콘을 저장할 수 있는데, 이 경우 일부 운영체제에서 실행 파일(.exe)에 할당하는 아이콘이 JPEG 이미지를 나타내는 데 흔히 쓰이는 아이콘으로 대체되어 프로그램이 이미지처럼 보이게 된다. 확장자는 스푸핑될 수도 있다. 일부 마이크로소프트 워드 매크로 바이러스는 템플릿 형식의 워드 파일을 만들고 이를 .doc 확장자로 저장한다. 워드는 일반적으로 확장자를 무시하고 파일 형식을 직접 확인하기 때문에, 이러한 파일들은 템플릿으로 열려 실행되고 바이러스를 퍼뜨린다. 이는 확장자 숨기기가 기본적으로 설정되어 있는 Windows 시스템에서 실질적인 문제가 된다.

내부 메타데이터

파일의 형식은 파일 내부에서 식별될 수 있다. 이는 해당 목적을 위해 의도된 정보이거나, 의도된 목적은 아니더라도 식별에 사용될 수 있는 형식 내의 식별 가능한 데이터일 수 있다.

종종 의도적으로 배치된 정보는 파일의 시작 부분에 위치하는데, 이는 사용자와 응용 프로그램 모두 파일에서 읽기가 상대적으로 쉽기 때문이다. 파일 시작 부분의 정보가 다른 메타데이터를 포함하는 구조인 경우, 이를 종종 파일 헤더라고 부른다. 파일이 형식만을 나타내는 상대적으로 작은 데이터로 시작하는 경우, 이를 종종 매직 넘버라고 부른다.

파일 헤더

파일 헤더에 포함된 메타데이터는 대개 파일 시작 부분에 저장되지만, 파일 형식이나 포함된 데이터 유형에 따라 끝부분을 포함한 다른 영역에도 존재할 수 있다. 문자 기반(텍스트) 파일은 대개 문자 기반 헤더를 갖는 반면, 이진 형식은 대개 이진 헤더를 갖지만 이것이 규칙은 아니다. 텍스트 기반 파일 헤더는 일반적으로 더 많은 공간을 차지하지만, 사람이 읽을 수 있어 텍스트 편집기나 십육진 편집기 같은 간단한 소프트웨어를 사용하여 쉽게 검사할 수 있다.

파일 형식을 나타내는 것 외에도 파일 헤더에는 파일과 그 내용에 대한 메타데이터가 포함될 수 있다. 예를 들어, 대부분의 이미지 파일은 이미지 형식, 크기, 해상도 및 색 공간에 대한 정보를 저장하며, 선택적으로 이미지를 만든 사람, 시기, 장소, 사용된 카메라 모델 및 촬영 설정(Exif) 등의 저자 정보를 저장하기도 한다. 이러한 메타데이터는 로딩 과정 중이나 그 후에 파일을 읽거나 해석하는 소프트웨어에서 사용될 수 있다.

파일 헤더는 운영체제가 파일을 메모리에 모두 로드하지 않고도 파일에 대한 정보를 빠르게 수집하는 데 사용될 수 있지만, 그렇게 하는 것은 디렉토리 정보에서 직접 읽는 것보다 더 많은 컴퓨터 자원을 소모한다. 예를 들어, 그래픽 사용자 인터페이스 기반의 파일 관리자가 폴더의 내용을 표시해야 할 때, 적절한 아이콘을 표시하기 전에 많은 파일의 헤더를 읽어야 하지만, 이들은 저장 매체의 서로 다른 위치에 있어 액세스하는 데 더 오랜 시간이 걸린다. 섬네일 정보와 같은 복잡한 메타데이터가 있는 파일이 많이 포함된 폴더는 표시되기까지 상당한 시간이 걸릴 수 있다.

헤더가 하드 코딩되어 있어 메타데이터 콘텐츠 보호 등을 위해 헤더 자체를 인식하는 데 복잡한 해석이 필요한 경우, 파일 형식을 잘못 해석할 위험이 있다. 소스에서 잘못 작성되었을 수도 있다. 이는 손상된 메타데이터로 이어질 수 있으며, 극단적인 경우 파일을 읽을 수 없게 만들 수도 있다.

파일 헤더의 더 복잡한 예는 래퍼(또는 컨테이너) 파일 형식에서 사용되는 것들이다.

매직 넘버

 매직 넘버 (프로그래밍) § In files 문서를 참고하십시오.

파일 유형 메타데이터를 통합하는 한 가지 방법은 파일 내부에 "매직 넘버"를 저장하는 것이다. 원래 이 용어는 파일 시작 부분의 2바이트 식별자를 가리켰지만, 모든 이진 시퀀스는 숫자로 간주될 수 있으므로 파일 형식을 고유하게 구별하는 모든 특징을 식별에 사용할 수 있다. 예를 들어 GIF 이미지는 준수하는 표준에 따라 항상 GIF87a 또는 GIF89a의 ASCII 표현으로 시작한다. 많은 파일 유형, 특히 플레인 텍스트 파일은 이 방법으로 식별하기가 더 어렵다. 예를 들어 HTML 파일은 대소문자를 구분하지 않는 <html> 문자열이나, <!DOCTYPE html로 시작하는 적절한 문서 형식 정의, 또는 XHTML의 경우 <?xml로 시작하는 XML 식별자로 시작할 수 있다. 파일은 HTML 주석, 임의의 텍스트 또는 여러 개의 빈 줄로 시작할 수도 있지만 여전히 사용 가능한 HTML일 수 있다.

매직 넘버 접근 방식은 형식이 올바르게 식별될 것임을 더 잘 보장하며, 파일에 대한 더 정밀한 정보를 결정할 수 있는 경우가 많다. 상당히 신뢰할 수 있는 "매직 넘버" 테스트는 꽤 복잡할 수 있고, 각 파일은 매직 데이터베이스의 모든 가능성에 대해 실질적으로 테스트되어야 하므로, 이 접근 방식은 특히 대량의 파일 목록을 표시할 때 상대적으로 비효율적이다(반면 파일 이름 및 메타데이터 기반 방법은 데이터 조각 하나만 확인하고 정렬된 인덱스와 대조하면 된다). 또한 데이터가 파일 자체에서 읽혀야 하므로 디렉토리에 저장된 메타데이터에 비해 지연 시간이 늘어난다. 파일 유형이 이러한 방식으로 인식되지 않는 경우 시스템은 메타데이터로 대체해야 한다. 그러나 이는 프로그램이 처리하도록 지시받은 파일이 올바른 형식인지 확인하는 가장 좋은 방법이다. 파일 이름이나 메타데이터는 내용과 별개로 변경될 수 있지만, 잘 설계된 매직 넘버 테스트를 통과하지 못하는 것은 파일이 손상되었거나 잘못된 유형이라는 확실한 신호이기 때문이다. 반면에 유효한 매직 넘버가 파일이 손상되지 않았거나 올바른 유형임을 보장하는 것은 아니다.

스크립트 파일의 소위 셔뱅 라인은 매직 넘버의 특수한 경우이다. 여기서 매직 넘버는 파일 내에서 특정 인터프리터와 그에게 전달할 옵션을 식별하는 사람이 읽을 수 있는 텍스트로 구성된다.

매직 넘버를 사용하는 또 다른 운영체제는 아미가OS이다. 여기서 매직 넘버는 "매직 쿠키"(Magic Cookies)라고 불렸으며, Hunk 실행 파일 형식의 실행 파일을 인식하고 단일 프로그램, 도구 및 유틸리티가 저장된 데이터 파일 또는 데이터를 저장하고 로드할 때의 다른 종류의 파일 유형을 자동으로 처리할 수 있도록 하는 표준 시스템으로 채택되었다. 이 시스템은 이후 아미가 표준 데이터타입 인식 시스템으로 향상되었다. 또 다른 방법은 매킨토시의 OSType에서 유래하여 나중에 인터체인지 파일 포맷(Interchange File Format, IFF) 및 그 파생물에 의해 채택된 FourCC 방식이었다.

외부 메타데이터

파일의 형식을 저장하는 마지막 방법은 파일 자체가 아닌 파일 시스템에 형식에 관한 정보를 명시적으로 저장하는 것이다.

이 접근 방식은 메타데이터를 기본 데이터 및 이름과 분리하여 유지하지만, 형식을 파일 시스템 간에 변환해야 하므로 파일 이름 확장자나 "매직 넘버"보다 이식성이 떨어진다. 파일 이름 확장자도 어느 정도는 사실이지만(예: MS-DOS의 3자 제한과의 호환성을 위해), 대부분의 저장 장치 형태는 파일 데이터와 이름에 대해 거의 동등한 정의를 가지고 있지만 추가 메타데이터의 표현은 다르거나 없을 수 있다.

ZIP 파일 및 기타 압축 파일은 메타데이터 처리 문제를 해결한다. 유틸리티 프로그램은 여러 파일과 각 파일 및 해당 폴더/디렉토리에 대한 메타데이터를 하나의 새로운 파일(예: .zip 확장자를 가진 ZIP 파일)로 수집한다. 새 파일은 압축되고 암호화될 수도 있지만, 이제는 FTP 전송이나 이메일 첨부 파일을 통해 운영체제 간에 단일 파일로 전송할 수 있다. 목적지에서 수신된 단일 파일은 유용하게 사용되기 위해 호환되는 유틸리티로 압축을 풀어야 한다. 메타데이터 처리 문제는 ZIP 파일이나 아카이브 파일을 사용하여 이런 방식으로 해결된다.

Mac OS 유형 코드

Mac OS의 계층적 파일 시스템 및 HFS+ 파일 시스템, 그리고 애플 파일 시스템은 각 파일의 디렉토리 항목의 일부로 생성자(creator) 및 유형(type) 코드를 저장한다. 이 코드들은 OSType이라고 불린다. 이 코드들은 임의의 4바이트 시퀀스일 수 있지만, 종종 ASCII 표현이 응용 프로그램 이름의 약어나 개발자의 이니셜과 같은 의미 있는 문자 시퀀스를 형성하도록 선택되었다. 예를 들어 하이퍼카드 "스택" 파일은 WILD(하이퍼카드의 이전 이름인 "WildCard"에서 유래)라는 생성자와 STAK이라는 유형을 가진다. BBEdit 텍스트 편집기는 원래 프로그래머인 리치 시걸(Rich Siegel)을 참조하는 R*ch라는 생성자 코드를 가진다. 유형 코드는 파일의 형식을 지정하고, 생성자 코드는 사용자가 더블 클릭했을 때 파일을 열 기본 프로그램을 지정한다. 예를 들어, 사용자가 모두 TEXT라는 유형 코드를 가진 여러 텍스트 파일을 가질 수 있지만, 생성자 코드가 다르기 때문에 각각 다른 프로그램에서 열릴 수 있다. 이 기능은 사람이 읽을 수 있는 플레인 텍스트 파일은 범용 텍스트 편집기에서 열리고, 프로그래밍 또는 HTML 코드 파일은 전문 편집기나 IDE에서 열리도록 의도된 것이었다. 그러나 파일을 더블 클릭했을 때 어떤 프로그램이 실행될지 예측하기 어려운 경우가 많아 종종 사용자 혼란의 원인이 되었다.

RISC OS는 유사한 시스템을 사용하는데, 이는 설명 테이블에서 찾아볼 수 있는 12비트 숫자로 구성된다. 예를 들어 십육진법 숫자 FF5는 포스트스크립트 파일을 나타내는 PoScript로 "별칭"이 지정된다.

macOS UTI (Uniform Type Identifiers)

 이 부분의 본문은 UTI (식별자)입니다.

UTI(Uniform Type Identifier)는 파일 형식과 같은 엔티티의 "유형이 지정된" 클래스를 고유하게 식별하기 위해 macOS에서 사용되는 방법이다. 이는 OSType(유형 및 생성자 코드)을 대체하기 위해 애플에서 개발되었다.

UTI는 역 DNS 문자열을 사용하는 Core Foundation 문자열이다. 일부 일반적이고 표준적인 유형은 public이라는 도메인을 사용하며(예: PNG 이미지의 경우 public.png), 다른 도메인은 서드파티 유형에 사용될 수 있다(예: PDF의 경우 com.adobe.pdf). UTI는 준수 계층 구조로 알려진 계층 구조 내에서 정의될 수 있다. 따라서 public.png는 public.image라는 상위 유형을 준수하며, 이는 다시 public.data라는 상위 유형을 준수한다. UTI는 여러 계층 구조에 존재할 수 있어 큰 유연성을 제공한다.

파일 형식 외에도 UTI는 다음과 같이 macOS에 존재할 수 있는 다른 엔티티에도 사용될 수 있다.

• 클립보드(Pasteboard) 데이터
• 폴더(디렉토리)
• 번역 가능한 유형 (Translation Manager에서 처리)
• 번들
• 프레임워크
• 스트리밍 데이터
• 별칭 및 심볼릭 링크

VSAM 카탈로그

IBM의 OS/VS부터 Z/OS에 이르기까지, VSAM 카탈로그(ICF 카탈로그 이전)와 VSAM 볼륨 데이터 세트(VVDS)의 VSAM 볼륨 레코드(ICF 카탈로그 포함)는 VSAM 데이터 세트의 유형을 식별한다.

VTOC

IBM의 OS/360부터 Z/OS에 이르기까지, VTOC의 형식 1 또는 7 데이터 세트 제어 블록(DSCB)은 해당 데이터 세트의 데이터 세트 조직(DSORG)을 식별한다.

OS/2 확장 속성

HPFS, FAT12 및 FAT16(FAT32 제외) 파일 시스템은 파일과 함께 "확장 속성"을 저장할 수 있게 해준다. 이들은 이름, 값의 코딩된 유형, 값으로 이루어진 임의의 트리플렛 세트로 구성되며, 이름은 고유하고 값은 최대 64 KB까지 가능하다. 특정 유형과 이름에 대해 표준화된 의미가 있다(OS/2 기준). 그 중 하나는 파일 유형을 결정하는 데 사용되는 ".TYPE" 확장 속성이다. 그 값은 파일과 연관된 하나 이상의 파일 유형 목록으로 구성되며, 각각은 "Plain Text"나 "HTML document"와 같은 문자열이다. 따라서 파일은 여러 유형을 가질 수 있다.

NTFS 파일 시스템도 파일 포크 중 하나로 OS/2 확장 속성의 저장을 허용하지만, 이 기능은 단지 OS/2 서브시스템(XP에는 없음)을 지원하기 위해 존재할 뿐이므로 Win32 서브시스템은 이 정보를 불투명한 데이터 블록으로 취급하고 사용하지 않는다. 대신 Win32 특유의 형식으로 메타 정보를 저장하기 위해 다른 파일 포크에 의존한다. OS/2 확장 속성은 여전히 Win32 프로그램에 의해 읽고 쓰여질 수 있지만, 데이터는 응용 프로그램에 의해 완전히 파싱되어야 한다.

POSIX 확장 속성

유닉스 및 유닉스 계열 시스템에서 Ext2, Ext3, Ext4, ReiserFS 버전 3, XFS, JFS, FFS 및 HFS+ 파일 시스템은 파일과 함께 확장 속성을 저장할 수 있게 해준다. 여기에는 "이름=값" 문자열의 임의 목록이 포함되며, 이름은 고유하고 값은 관련 이름을 통해 액세스할 수 있다.

PRONOM 고유 식별자 (PUID)

PRONOM 영구 고유 식별자(PUID)는 파일 형식에 대한 영구적이고 고유하며 명확한 식별자를 위한 확장 가능한 체계로, 영국 국립기록보존소가 PRONOM 기술 레지스트리 서비스의 일환으로 개발했다. PUID는 info:pronom/ 네임스페이스를 사용하는 통합 자원 식별자로 표현될 수 있다. 아직 영국 정부와 일부 디지털 아카이브 프로그램 외부에서는 널리 사용되지 않지만, PUID 체계는 대부분의 대안 체계보다 더 큰 세분성을 제공한다.

MIME 타입

 이 부분의 본문은 미디어 타입입니다.

MIME 타입은 많은 인터넷 관련 응용 프로그램에서 널리 사용되며 다른 분야에서도 점점 더 많이 사용되고 있지만, 디스크 상의 유형 정보로의 사용은 드물다. 이들은 IANA에서 관리하는 표준화된 식별자 시스템으로 구성되며, 빗금으로 구분된 유형과 하위 유형으로 구성된다(예: text/html 또는 image/gif). 이들은 원래 소스 및 대상 운영체제와 관계없이 이메일에 첨부된 파일 유형을 식별하는 방법으로 의도되었다. MIME 타입은 BeOS, 아미가OS 4.0 및 모르프OS에서 파일을 식별하며, 응용 프로그램 실행을 위한 고유한 응용 프로그램 시그니처를 저장한다. 아미가OS와 모르프OS에서 MIME 타입 시스템은 아미가 특유의 데이터타입 시스템과 병행하여 작동한다.

그러나 MIME 타입에도 문제가 있다. 여러 조직과 사람들이 IANA에 제대로 등록하지 않고 독자적인 MIME 타입을 만들어 사용함으로써 어떤 경우에는 이 표준을 사용하기가 까다로워지기도 한다.

파일 형식 식별자 (FFID)

파일 형식 식별자는 파일의 출처와 범주에 따라 파일 형식을 식별하는 또 다른 잘 사용되지 않는 방식이다. 이는 Description Explorer 소프트웨어 제품군을 위해 만들어졌다. 이는 NNNNNNNNN-XX-YYYYYYY 형태의 여러 숫자로 구성된다. 첫 번째 부분은 조직의 출처/관리자를 나타내고(이 숫자는 회사/표준 기구 데이터베이스의 값을 나타냄), 이어지는 2자리는 십육진법으로 파일의 유형을 분류한다. 마지막 부분은 파일의 일반적인 파일 확장자나 파일의 국제 표준 번호로 구성되며, 왼쪽을 0으로 채운다. 예를 들어, PNG 파일 사양의 FFID는 000000001-31-0015948이며, 여기서 31은 이미지 파일을 나타내고, 0015948은 표준 번호이며, 000000001은 국제 표준화 기구(ISO)를 나타낸다.

파일 내용 기반 형식 식별

파일 형식을 식별하는 또 다른 덜 대중적인 방법은 파일 내용에서 파일 유형 간의 구별 가능한 패턴을 검사하는 것이다. 파일의 내용은 바이트의 시퀀스이며 바이트는 256개의 고유한 순열(0–255)을 갖는다. 따라서 종종 바이트 빈도 분포라고 불리는 바이트 패턴의 발생 횟수를 세면 파일 유형을 식별할 수 있는 구별 가능한 패턴이 제공된다. 바이트 빈도 분포를 사용하여 파일 유형에 대한 대표 모델을 구축하고 통계 및 데이터 마이닝 기법을 사용하여 파일 유형을 식별하는 많은 내용 기반 파일 유형 식별 체계가 있다.

파일 구조

파일에 데이터를 구조화하는 방법에는 여러 가지가 있다. 가장 일반적인 것들은 다음과 같다.

비구조화 형식 (원시 메모리 덤프)

초기 파일 형식은 하나 이상의 구조체의 메모리 이미지를 파일에 직접 덤프하는 원시 데이터 형식을 사용했다.

이 방식에는 몇 가지 단점이 있다. 메모리 이미지에 미래의 확장을 위한 예약 공간이 있지 않는 한, 이러한 유형의 구조화된 파일을 확장하고 개선하는 것은 매우 어렵다. 또한 특정 플랫폼이나 프로그래밍 언어에 종속적인 파일을 만들게 된다(예를 들어 파스칼 문자열을 포함하는 구조체는 C에서는 그렇게 인식되지 않는다). 반면에 이러한 유형의 파일을 읽고 쓰기 위한 도구를 개발하는 것은 매우 간단하다.

비구조화 형식의 한계로 인해, 쉽게 확장할 수 있으면서 동시에 하위 호환성을 유지할 수 있는 다른 유형의 파일 형식이 개발되었다.

청크 기반 형식

이러한 종류의 파일 구조에서 각 데이터 조각은 어떻게든 데이터를 식별하는 컨테이너에 담겨 있다. 컨테이너의 범위는 어떤 종류의 시작 및 종료 마커, 어딘가에 있는 명시적인 길이 필드, 또는 파일 형식 정의의 고정된 요구 사항에 의해 식별될 수 있다.

1970년대 내내 많은 프로그램이 이러한 일반적인 종류의 형식을 사용했다. 예를 들어 troff, Script, Scribe와 같은 워드 프로세서와 CSV와 같은 데이터베이스 내보내기 파일이 있다. 일렉트로닉 아츠와 코모도어 아미가도 1985년에 그들의 IFF(Interchange File Format) 파일 형식을 통해 이 유형의 파일 형식을 사용했다.

컨테이너는 때때로 "청크(chunk)"라고 불리기도 하지만, "청크"는 각 조각이 작거나 청크가 다른 청크를 포함하지 않는다는 것을 암시할 수도 있다. 많은 형식은 이러한 요구 사항을 강제하지 않는다.

특정 "청크"를 식별하는 정보는 "필드 이름", "식별자", "레이블" 또는 "태그"를 포함하여 다양한 이름으로 불릴 수 있다. 식별자는 종종 사람이 읽을 수 있으며 데이터의 일부를 분류한다. 예를 들어 "성씨", "주소", "직사각형", "글꼴 이름" 등이다. 이것들은 데이터베이스 키나 일련번호의 의미에서의 식별자와는 다르다(식별자가 그 연관 데이터를 그러한 키로 식별할 수는 있지만).

이러한 유형의 파일 구조에서 특정 청크 식별자를 모르는 도구는 이해하지 못하는 것들을 단순히 건너뛴다. 건너뛴 데이터의 실제 의미에 따라 이것이 유용할 수도 있고 그렇지 않을 수도 있다(CSS는 이러한 동작을 명시적으로 정의한다).

이 개념은 RIFF(IFF에 대응하는 Microsoft-IBM의 형식), PNG, JPEG 저장소, DER(Distinguished Encoding Rules) 인코딩된 스트림 및 파일(원래 CCITT X.409:1984에서 설명되어 IFF보다 앞섬), 그리고 구조화 데이터 교환 형식(SDXF)에서 반복적으로 사용되었다.

실제로 모든 데이터 형식은 구성 요소의 중요성을 어떻게든 식별해야 하며, 내장된 경계 마커는 이를 수행하는 명백한 방법이다.

• MIME 헤더는 각 논리적 행의 시작 부분에 콜론으로 구분된 레이블을 사용하여 이를 수행한다. MIME 헤더는 다른 MIME 헤더를 포함할 수 없지만, 일부 헤더의 데이터 내용은 다른 관습에 의해 추출될 수 있는 하위 부분을 가질 수 있다.
• CSV 및 유사한 파일은 종종 필드 이름이 있는 헤더 레코드를 사용하고 필드 경계를 표시하기 위해 쉼표를 사용하여 이를 수행한다. MIME과 마찬가지로 CSV는 두 개 이상의 수준을 가진 구조를 지원하지 않는다.
• XML과 그 친척들은 데이터 요소가 청크 식별자와 유사한 마크업에 의해 식별되므로 청크 기반 형식의 일종으로 느슨하게 간주될 수 있다. 그러나 스키마 및 유효성 검사와 같은 공식적인 장점뿐만 아니라 트리, DAG 및 차트와 같은 더 복잡한 구조를 표현하는 능력도 갖추고 있다. 만약 XML이 "청크" 형식으로 간주된다면, SGML과 그 전신인 IBM GML은 그러한 형식의 가장 초기 사례 중 하나이다.
• JSON은 스키마, 상호 참조, 또는 반복된 필드 이름의 의미에 대한 정의가 없는 XML과 유사하며, 프로그래머들에게 종종 편리하다.
• YAML은 JSON과 유사하지만 들여쓰기를 사용하여 데이터 청크를 구분하며 JSON이나 XML보다 사람이 읽기 더 편한 것을 목표로 한다.
• 프로토콜 버퍼는 다시 JSON과 유사한데, 특히 데이터의 경계 마커를 필드 번호로 대체하며, 이 번호는 외부 메커니즘에 의해 이름과 매핑된다.

디렉토리 기반 형식

이것은 파일 시스템과 매우 유사한 또 다른 확장 가능한 형식이며(OLE 문서는 실제 파일 시스템이다), 파일이 자신의 시그니처(및 특정 경우의 유형)뿐만 아니라 파일 자체 내의 데이터 위치를 포함하는 '디렉토리 항목'으로 구성된다. 이러한 유형의 파일 구조의 좋은 예로는 디스크 이미지, 실행 파일, OLE 문서, TIFF, 라이브러리 등이 있다.

ODT나 DOCX와 같은 일부 파일 형식은 PKZIP 기반이므로 청크 방식이면서 디렉토리를 포함한다.

디렉토리 기반 파일 형식의 구조는 비구조화 또는 청크 기반 형식보다 더 쉽게 수정할 수 있다. 이러한 유형의 형식의 특성상 사용자가 파일을 정교하게 구성하여 판독 소프트웨어가 형식 설계자가 결코 의도하지 않은 동작을 수행하게 만들 수 있다. 그 예가 Zip 폭탄이다. 디렉토리 기반 파일 형식은 파일 내의 다른 영역을 가리키는 값을 사용하기도 하는데, 만약 나중의 데이터 값이 이전에 읽은 데이터를 다시 가리키게 되면, 입력 파일이 유효하다고 가정하고 맹목적으로 루프를 따르는 판독 소프트웨어에게 무한 루프를 초래할 수 있다.

같이 보기

• 파일 형식 목록
• 오디오 파일 포맷
• 파일 이름