파일 형식

File format
"파일 형식"은 여기서 리디렉션됩니다.파일 유형은 UNIX 파일 형식 또는 파일 이름 확장자를 나타낼 수도 있습니다.
wav 파일: 2.1 MB.
ogg 파일: 154 킬로바이트.

파일 형식은 컴퓨터 파일에 저장하기 위해 정보를 인코딩하는 표준 방법입니다.디지털 저장 매체의 정보를 인코딩하는 데 비트가 사용되는 방법을 지정합니다.파일 형식은 독자 사양이거나 무료일 수 있습니다.

일부 파일 형식은 매우 특정 유형의 데이터를 위해 설계되었습니다. 예를 들어 PNG 파일은 무손실 데이터 압축을 사용하여 비트맵 이미지를 저장합니다.그러나 다른 파일 형식은 여러 가지 다른 유형의 데이터를 저장하도록 설계되어 있습니다. Ogg 형식은 텍스트(자막 등)와 메타데이터를 포함하거나 포함하지 않고 오디오와 비디오의 조합을 포함한 다양한 유형의 멀티미디어의 컨테이너 역할을 할 수 있습니다.텍스트 파일은 가능한 제어문자를 포함한 임의의 문자 스트림을 포함할 수 있으며, 다양한 문자 부호화 방식 중 하나로 부호화된다.HTML, 확장 가능한 벡터 그래픽스 및 컴퓨터 소프트웨어의 소스 코드와 같은 일부 파일 형식은 특정 목적에 사용할 수 있도록 정의된 구문을 가진 텍스트 파일입니다.

사양

파일 형식에는 인코딩 방법을 설명하고 프로그램 의도된 기능을 테스트할 수 있도록 하는 공개 사양이 있는 경우가 많습니다.모든 포맷이 자유롭게 이용 가능한 사양 문서를 가지고 있는 것은 아닙니다.부분적으로는 일부 개발자가 그들의 사양 문서를 영업비밀로 간주하고, 다른 개발자가 공식적인 사양 문서를 작성하지 않기 때문입니다.또한 이 포맷을 사용하는 다른 기존 프로그램에 의해 만들어진 전례가 이러한 기존 PR의 방법을 통해 포맷을 정의하는 것을 허용하기 때문입니다.ograms가 사용합니다.

포맷 개발자가 무료 사양을 공개하지 않을 경우, 해당 파일을 사용하려는 다른 개발자는 파일을 리버스 엔지니어링하여 읽는 방법을 알아보거나 포맷 개발자로부터 사양 문서를 유료 및 비공개 계약에 서명하여 입수해야 합니다.후자의 접근방식은 정식 사양 문서가 존재하는 경우에만 가능합니다.두 전략 모두 상당한 시간과 비용 또는 두 가지 모두를 필요로 하기 때문에 공개적으로 사용 가능한 사양의 파일 형식이 더 많은 프로그램에서 지원되는 경향이 있습니다.

특허

파일 형식을 보호하기 위해 저작권보다는 특허법이 더 많이 사용됩니다.파일 포맷에 대한 특허는 미국 법률에 의해 직접 허가되지 않지만 일부 포맷은 특허받은 알고리즘을 사용하여 데이터를 인코딩합니다.예를 들어 GIF 파일 형식에서의 압축을 사용하려면 특허 알고리즘을 사용해야 하며, 특허 소유자가 처음에는 특허를 강제하지 않았지만 나중에 로열티 수수료를 징수하기 시작했다.이로 인해 GIF 사용이 크게 감소했으며, 대체 PNG 형식의 개발에 부분적으로 책임이 있다.그러나 GIF 특허는 2003년 중반 미국에서, 2004년 중반 전 세계적으로 만료되었습니다.

파일 형식 식별

운영체제에 따라 특정 파일 형식을 결정하는 방식이 달라지며 각각의 접근 방식에는 장점과 단점이 있습니다.대부분의 최신 운영 체제 및 개별 애플리케이션은 완전히 작동하지는 않더라도 "외부" 파일 형식을 읽기 위해 다음과 같은 모든 방법을 사용해야 합니다.

파일 이름 확장자

주요 기사:파일 이름 확장자

Windows, macOS, CP/M, DOS, VMS 및 VM/CMS를 포함한 많은 운영 체제에서 널리 사용되는 방법 중 하나는 파일 이름 끝, 특히 마지막 마침표 뒤의 문자를 기반으로 파일 형식을 결정하는 것입니다.파일명의 이 부분을 파일명 확장자라고 부릅니다.예를 들어 HTML 문서는 다음 문자로 끝나는 이름으로 식별됩니다. .html(또는 .htm) 및 .gif의 GIF 이미지.원래의 FAT 파일시스템에서는, 파일명은 8 문자의 식별자와 8.3 파일명으로 알려진 3 문자의 확장자로 제한되어 있었습니다.3글자 내선번호는 한정되어 있으며, 이로 인해 여러 프로그램에서 특정 내선번호가 사용될 수 있습니다.최신 운영 체제 및 응용 프로그램에는 더 이상 이러한 제한이 없지만 많은 형식에서 여전히 3자 확장자를 사용합니다.표준 확장자 목록이 없으므로 여러 형식에서 동일한 확장자를 사용할 수 있으므로 운영 체제와 사용자가 모두 혼동될 수 있습니다.

이 어프로치의 아티팩트 중 하나는 파일명을 변경하는 것만으로 시스템이 파일을 다른 형식으로 취급하도록 쉽게 속일 수 있다는 것입니다.예를 들어 HTML 파일은 파일명을 filename.html에서 filename으로 변경함으로써 일반 텍스트로 쉽게 취급할 수 있습니다.txt. 이 전략은 이 정보를 쉽게 이해하고 조작할 수 있는 전문 사용자에게는 유용했지만, 이름이 잘못되어 파일을 사용할 수 없게 하거나 "분실"할 수 있는 기술력이 낮은 사용자에게는 종종 혼란스러웠습니다.

이로 인해 대부분의 Windows 및 Mac OS 버전은 파일을 나열할 때 확장자를 숨겼습니다.이것에 의해, 유저가 파일 타입을 잘못 변경하는 것을 방지해, 익스퍼트 유저가 이 기능을 오프 해 확장자를 표시할 수 있습니다.

그러나 확장자를 숨기면 동일한 폴더에 두 개 이상의 동일한 파일 이름이 나타날 수 있습니다.예를 들어 회사 로고는 (게시용) .eps 형식과 (웹 사이트용) .png 형식 모두 필요할 수 있습니다.확장자가 표시되어 있으면, 「CompanyLogo.eps」및 「CompanyLogo.png」의 고유 파일명으로 표시됩니다.한편 확장자를 숨기면 둘 다 "CompanyLogo"로 표시되므로 혼란을 초래할 수 있습니다.

내선번호를 숨기는 것도 보안상의 [1]위험을 초래할 수 있습니다.예를 들어 악의적인 사용자가 "Holiday photo.jpg.exe"와 같은 무해한 이름의 실행 프로그램을 만들 수 있습니다.".exe"는 숨겨져 있고, 의심하지 않는 사용자에게는 "Holiday photo.jpg"가 표시됩니다.이것은 JPEG 이미지로서 통상 머신에 해를 끼칠 수 없습니다.다만, OS 에서는 확장자 「.exe」가 표시되고, 프로그램이 실행되기 때문에, 컴퓨터가 손상될 가능성이 있습니다.확장자가 1개뿐인 파일도 마찬가지입니다.이 파일은 사용자에게 표시되지 않기 때문에 파일을 명시적으로 조사하지 않으면 파일에 대한 정보를 추론할 수 없습니다.사용자를 속이기 위해 프로그램 내부에 아이콘을 저장할 수 있습니다.이 경우 일부 운영체제의 실행 파일(.exe)에 대한 아이콘 할당이 JPEG 이미지를 나타내기 위해 일반적으로 사용되는 아이콘으로 덮어쓰게 되어 프로그램이 이미지처럼 보이게 됩니다.확장자도 스푸핑할 수 있습니다.일부 Microsoft Word 매크로 바이러스는 템플릿 형식으로 Word 파일을 생성하여 .doc 확장자로 저장합니다.Word는 일반적으로 확장자를 무시하고 파일 형식을 조사하기 때문에 확장자는 템플릿으로 열리고 [citation needed]실행되며 바이러스가 확산됩니다.이는 확장 숨김이 기본적으로 켜져 있는 윈도우즈 시스템에 실질적인 문제를 나타냅니다.

내부 메타데이터

파일 포맷을 식별하는 두 번째 방법은 파일 자체에 저장된 포맷에 대한 정보(이 목적을 위한 정보 또는 일부 형식의 파일에서 항상 특정 위치에 있는 바이너리 문자열)를 사용하는 것입니다.이러한 영역을 찾는 가장 쉬운 장소는 선두에 있기 때문에 이러한 영역은 보통 파일헤더(몇 바이트보다 클 경우) 또는 매직넘버(몇 바이트 길이에 불과할 경우)

파일 헤더

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

파일 헤더에는 파일 형식을 식별할 뿐만 아니라 파일 및 파일 내용에 대한 메타데이터가 포함될 수 있습니다.예를 들어, 대부분의 이미지 파일에는 이미지 형식, 크기, 해상도 및 색 공간에 대한 정보 및 선택적으로 이미지를 만든 사람, 언제, 어디서 만들었는지, 사용된 카메라 모델 및 사진 설정(Exif) 등의 오서링 정보가 저장됩니다.이러한 메타데이터는 로드 프로세스 중 및 로드 후에 소프트웨어를 통해 파일을 읽거나 해석할 수 있습니다.

운영체제는 파일 헤더를 사용하여 파일에 대한 정보를 메모리에 로드하지 않고 빠르게 수집할 수 있지만, 그렇게 하면 디렉토리 정보에서 직접 읽는 것보다 컴퓨터의 리소스가 더 많이 사용됩니다.예를 들어, 그래픽 파일 관리자가 폴더의 내용을 표시해야 하는 경우 적절한 아이콘을 표시하기 전에 많은 파일의 헤더를 읽어야 하지만, 이러한 헤더는 저장 매체 상의 다른 위치에 위치하기 때문에 액세스에 시간이 걸립니다.썸네일 정보 등 복잡한 메타데이터를 가진 많은 파일이 포함된 폴더는 표시할 때까지 상당한 시간이 걸릴 수 있습니다.

특히 메타데이터 콘텐츠 보호를 위해 헤더 자체를 인식하기 위해 복잡한 해석이 필요하도록 헤더가 바이너리 하드 코딩되어 있으면 파일 형식이 잘못 해석될 위험이 있습니다.그것은 심지어 출처에서 잘못 쓰여졌을지도 모른다.이로 인해 메타데이터가 손상되어 극히 나쁜 경우 파일을 읽을 [clarification needed]수 없게 될 수도 있습니다.

파일 헤더의 보다 복잡한 예로는 래퍼(또는 컨테이너) 파일 형식에 사용되는 헤더가 있습니다.

매직 넘버

다음 항목도 참조하십시오.매직 넘버 (프로그래밍) in 파일 내

종종 Unix 및 그 파생 제품과 관련된 파일 형식 메타데이터를 통합하는 한 가지 방법은 파일 자체에 "매직 번호"를 저장하는 것입니다.원래 이 용어는 파일의 시작 부분에서 2바이트 식별자의 특정 집합을 위해 사용되었지만, 이진 시퀀스는 숫자로 간주될 수 있으므로 고유하게 구별하는 파일 형식의 모든 기능을 식별에 사용할 수 있습니다.예를 들어, GIF 이미지는 항상 GIF87a 또는 GIF89a의 ASCII 표현으로 시작합니다.이 표현은 GIF87a 또는 GIF89a에 준거하고 있습니다.이 방법으로는 많은 파일 형식, 특히 일반 텍스트 파일을 찾기 어렵습니다.예를 들어 HTML 파일은 문자열 <html>(대문자와 소문자가 구분되지 않음)로 시작하거나 <!>로 시작하는 적절한 문서 유형 정의를 사용할 수 있습니다.DOSCTYPE HTML > 또는 XHTML의 경우 <?xml로 시작하는 XML 식별자입니다.파일은 HTML 주석, 랜덤 텍스트 또는 빈 행으로 시작할 수도 있지만 HTML을 사용할 수도 있습니다.

매직넘버접근법을통해포맷이정확하게식별될수있음을확실히보여주고많은경우파일에대한정확한정보를판단할수있는경우가많습니다.합리적으로 신뢰성이 높은 "매직 넘버" 테스트는 매우 복잡할 수 있으며 각 파일은 매직 데이터베이스 내의 모든 가능성에 대해 효과적으로 테스트해야 하므로 이 접근법은 특히 대량의 파일 목록을 표시하는 데 있어 상대적으로 비효율적입니다(반면 파일 이름 및 메타데이터 기반 방식은 하나의 데이터만 체크하여 일치시킬 필요가 있습니다).분류된 인덱스에 대해).또한 데이터는 파일 자체에서 읽어야 하므로 디렉토리에 저장된 메타데이터가 아니라 지연 시간이 길어집니다.파일 형식이 이러한 방식으로 인식되지 않는 경우 시스템은 메타데이터로 폴백해야 합니다.그러나 프로그램이 처리하도록 지시받은 파일이 올바른 형식인지 확인하는 가장 좋은 방법은 파일 이름 또는 메타데이터가 내용과 독립적으로 변경될 수 있지만 잘 설계된 매직 넘버 테스트가 실패하면 파일이 손상되었거나 잘못된 유형임을 보여주는 매우 확실한 신호입니다.한편, 유효한 매직 넘버가 파일의 파손이나 올바른 타입을 보증하는 것은 아닙니다.

스크립트 파일에 있는 소위 shebang 행은 매직넘버의 특별한 경우입니다.여기서 매직넘버는 특정 명령어인터프리터와 명령어인터프리터에 전달되는 옵션을 식별하는 사람이 읽을 수 있는 텍스트입니다.

매직넘버를 사용하는 또 다른 운영체제는 AmigaOS로 매직넘버는 "매직쿠키"라고 불리며 Hunk 실행파일 포맷의 실행파일을 인식하여 단일 프로그램, 도구 및 유틸리티가 저장된 데이터 파일 또는 기타 종류의 파일 형식을 자동으로 처리할 수 있도록 표준시스템으로 채택되었습니다.데이터 추가.그 후 이 시스템은 Amiga 표준 데이터 유형 인식 시스템으로 강화되었습니다.또 다른 방법은 Macintosh의 OSType에서 유래한 FourCC 방식이며, 나중에 Interchange File Format(IFF) 및 파생 모델에 의해 채택되었습니다.

외부 메타데이터

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

이 접근방식은 메타데이터를 메인 데이터와 이름 모두로부터 분리하여 유지하지만 포맷을 파일 시스템에서 파일 시스템으로 변환해야 하기 때문에 파일 확장자 또는 "매직 번호"보다 휴대성이 떨어집니다.예를 들어 MS-DOS의 3글자 제한과의 호환성을 위해 파일 확장자에 대해서도 마찬가지이지만, 대부분의 스토리지 형식은 파일의 데이터 및 이름에 대해 거의 동일한 정의를 가지지만 이후 메타데이터에 대한 표현은 다양하거나 아예 없을 수 있습니다.

zip 파일 또는 아카이브 파일은 메타데이터 처리 문제를 해결합니다.유틸리티 프로그램은 각 파일에 대한 메타데이터와 함께 여러 파일을 수집하며, 각 파일에서 가져온 폴더/디렉토리(예: 확장자가 .zip인 zip 파일)를 하나의 새 파일로 만듭니다.새로운 파일도 압축되어 암호화되어 있을 가능성이 있습니다만, 현재는 FTP 송신에 의해서 operating system간에 1개의 파일로 송신하거나 첨부 파일로 이메일로 송신하거나 할 수 있습니다.수신처에서는, 호환성이 있는 유틸리티에 의해서 수신된 단일 파일의 압축을 해제해 둘 필요가 있습니다.메타데이터 처리 문제는 zip 파일 또는 아카이브 파일을 사용하여 해결됩니다.

Mac OS 타입 코드

Mac OS의 계층 파일 시스템은 각 파일에 대한 디렉터리 항목의 일부로 생성자 및 유형에 대한 코드를 저장합니다.이러한 코드를 OSType이라고 부릅니다.이 코드들은 임의의 4바이트 시퀀스가 될 수 있지만, ASCII 표현이 어플리케이션 이름이나 개발자의 이니셜의 줄임말과 같은 의미 있는 문자의 시퀀스를 형성하기 위해 종종 선택되었다.예를 들어 HyperCard "stack" 파일에는 WILD 생성자(HyperCard의 이전 이름인 "WildCard"에서 유래)와 STAK 유형이 있습니다.BBEdit 텍스트에디터의 작성자 코드는 다음과 같습니다.R*ch원조 프로그래머인 리치 시겔을 언급했습니다.유형 코드는 파일 형식을 지정하는 반면, 생성자 코드는 사용자가 두 번 클릭했을 때 파일을 열 때 사용하는 기본 프로그램을 지정합니다.예를 들어, 사용자는 TEXT 유형 코드를 가진 여러 개의 텍스트 파일을 가질 수 있지만, 각각 다른 생성자 코드를 가지고 있기 때문에 다른 프로그램에서 열 수 있습니다.이 기능은 예를 들어 사람이 읽을 수 있는 일반 텍스트 파일을 범용 텍스트 편집기에서 열 수 있도록 설계되었으며 프로그래밍 또는 HTML 코드 파일은 전문 편집기 또는 IDE에서 열 수 있도록 설계되었습니다.그러나 이 기능은 파일을 더블클릭했을 때 어떤 프로그램이 실행될지 예측할 수 없었기 때문에 종종 사용자 혼란의 원인이 되었습니다.RISC OS는 12비트 숫자로 구성된 동일한 시스템을 사용합니다.이 숫자는 설명표에서 검색할 수 있습니다(16진수 등).FF5는 PostScript 파일을 나타내는 PoScript와 "에일리어스"되어 있습니다.

Mac OS X UTI(Uniform Type Identifier)

주요 기사:균일 유형 식별자

UTI(Uniform Type Identifier)는 파일 형식과 같은 엔티티의 "유형" 클래스를 고유하게 식별하기 위해 MacOS에서 사용되는 방법입니다.OSType(타입 & 크리에이터 코드)을 대체하기 위해 애플에 의해 개발되었습니다.

UTI는 리버스 DNS 스트링을 사용하는 Core Foundation 문자열입니다.일부 일반 및 표준 유형은 public이라는 도메인을 사용하고(예: Portable Network Graphics 이미지의 경우 public.png), 다른 도메인은 서드파티 유형(예: Portable Document Format의 경우 com.adobe.pdf)으로 사용할 수 있습니다.UTI는 준거 계층이라고 불리는 계층 구조 내에서 정의할 수 있습니다.따라서 public.png은 public.image의 슈퍼타입에 준거하고 있으며, 그 자체는 public.data의 슈퍼타입에 준거하고 있습니다.UTI는 여러 계층에 존재할 수 있기 때문에 유연성이 뛰어납니다.

UTI는 파일 형식 외에도 다음과 같은 MacOS에 존재할 수 있는 다른 엔티티에도 사용할 수 있습니다.

  • 페이스트보드 데이터
  • 폴더(디렉토리)
  • 번역 가능한 유형(Translation Manager에 의해 처리됨
  • 번들
  • 프레임워크
  • 데이터 스트리밍
  • 에일리어스 및 심볼링크

OS/2 확장 속성

HPFS, FAT12 및 FAT16(단, FAT32는 제외) 파일 시스템에서는 파일과 함께 "확장 속성"을 저장할 수 있습니다.이들은 이름, 값의 코드화된 유형 및 값을 가진 임의의 세쌍둥이로 구성됩니다.이 경우 이름은 고유하며 값은 최대 64KB까지 사용할 수 있습니다.특정 유형 및 이름에 대해 표준화된 의미가 있습니다(OS/2).그 중 하나가 "이다.TYPE" 확장 속성은 파일 유형을 결정하는 데 사용됩니다.이 값은 "일반 텍스트" 또는 "HTML 문서"와 같은 문자열인 하나 이상의 파일 형식 목록으로 구성됩니다.따라서 파일에는 여러 유형이 있을 수 있습니다.

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

POSIX 확장 어트리뷰트

Unix 및 Unix 유사 시스템에서는 ext2, ext3, ext4, ReiserFS 버전 3, XFS, JFS, FFS 및 HFS+ 파일 시스템에서는 확장 속성을 파일과 함께 저장할 수 있습니다.여기에는 "name=value" 문자열의 임의 목록이 포함됩니다. 여기서 이름은 고유하며 관련 이름을 통해 값에 액세스할 수 있습니다.

PRONOM 고유 식별자(PUID)

PRONOM Persistent Unique Identifier(PUID; 지속적 고유 식별자)는 파일 형식의 확장 가능한 스킴으로, 영국 국립 아카이브(National Archives of UK)가 PRONOM 기술 레지스트리 서비스의 일환으로 개발했습니다.PUID는 info:pronom/네임스페이스를 사용하여 Uniform Resource Identifier로 표시할 수 있습니다.영국 정부 및 일부 디지털 보존 프로그램 이외에서는 아직 널리 사용되지 않지만, PUID 계획은 대부분의 대체 계획보다 더 세분성을 제공한다.

MIME 타입

MIME 유형은 많은 인터넷 관련 응용 프로그램에서 널리 사용되며 디스크 형식 정보에 대한 사용은 드물지만 점점 더 늘어나고 있습니다.이들은 유형 및 하위 유형으로 구성된 표준화된 식별자 시스템(IANA에 의해 관리됨)으로 구성되며, 예를 들어 text/html 또는 image/gif와 같이 슬래시로 구분됩니다.이것들은 원래 소스 운영체제 및 타깃 운영체제와는 무관하게 이메일에 첨부되어 있는 파일 유형을 식별하기 위한 목적으로 작성되었습니다.MIME 유형은 BeOS, AmigaOS 4.0 및 MorphOS 상의 파일을 식별하고 응용 프로그램 부팅을 위한 고유한 응용 프로그램 서명을 저장합니다.인아미가OS와 MorphOS는 MIME 타입 시스템이 Amiga 고유의 데이터 타입 시스템과 병렬로 동작합니다.

그러나 MIME 유형에는 문제가 있습니다. 여러 조직과 사람들이 IANA에 제대로 등록하지 않고 자체 MIME 유형을 생성했기 때문에 경우에 따라서는 이 표준을 사용하는 것이 어색합니다.

파일 형식 식별자(FFID)

파일 형식 식별자는 파일 형식을 원본 및 파일 범주에 따라 식별하는 또 다른 방법으로 널리 사용되지 않습니다.Description Explorer 소프트웨어 스위트용으로 작성되었습니다.폼의 여러 자릿수로 구성됩니다.NNNNNNNNN-XX-YYYYYYY첫 번째 부분은 조직의 출처/유지자(이 숫자는 회사/표준 조직 데이터베이스의 값을 나타냄)를 나타냅니다.다음 2자리 숫자는 파일 유형을 16진수로 분류합니다.마지막 부분은 파일의 일반적인 파일 이름 확장자 또는 파일의 국제 표준 번호로 구성되어 있으며 왼쪽에는 0이 패딩되어 있습니다.예를 들어 PNG 파일 사양의 FFID는 다음과 같습니다.000000001-31-0015948어디에31이미지 파일을 나타냅니다.0015948표준번호입니다.000000001는 International Organization for Standardization(ISO; 국제표준화기구)를 나타냅니다.

파일 콘텐츠 기반 형식 식별

파일 형식을 식별하는 또 다른 방법으로는 파일 형식 간에 구분할 수 있는 패턴이 있는지 파일 내용을 조사하는 방법이 있습니다.파일의 내용은 일련의 바이트이며 바이트에는 256개의 고유한 순열(0 ~255)이 있습니다.따라서 바이트 빈도 분포라고 불리는 바이트 패턴의 발생을 세면 파일 유형을 식별할 수 있는 패턴을 얻을 수 있습니다.바이트 빈도 분포를 사용하여 파일 유형의 대표 모델을 구축하고 통계 및 데이터 마이닝 기술을 사용하여 파일[2] 유형을 식별하는 컨텐츠 기반 파일 유형 식별 방식이 많이 있습니다.

파일 구조

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

구조화되지 않은 형식(원시 메모리 덤프)

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

여기에는 몇 가지 단점이 있습니다.메모리 이미지에도 향후 확장자를 위한 공간이 예약되어 있지 않는 한 이러한 유형의 구조화 파일을 확장 및 개선하는 것은 매우 어렵습니다.또한 하나의 플랫폼 또는 프로그래밍 언어에 고유한 파일을 생성합니다(예를 들어 Pascal 문자열을 포함하는 구조는 C에서 인식되지 않음).한편, 이러한 종류의 파일을 읽고 쓸 수 있는 툴을 개발하는 것은 매우 간단합니다.

구조화되지 않은 형식의 제한으로 인해 쉽게 확장되고 동시에 하위 호환이 가능한 다른 유형의 파일 형식이 개발되었습니다.

청크 기반 형식

이러한 종류의 파일 구조에서는 각 데이터가 어떻게든 데이터를 식별하는 컨테이너에 포함되어 있습니다.컨테이너의 범위는 어떤 종류의 시작 및 끝 표시자, 어딘가에 있는 명시적 길이 필드 또는 파일 형식 정의의 고정 요건에 의해 식별될 수 있습니다.

1970년대 내내, 많은 프로그램들이 이런 종류의 일반적인 형식을 사용했다.예를 들어 troff, Script, Scribe 등의 워드프로세서와 CSV 등의 데이터베이스 내보내기 파일이 있습니다.Electronic Arts와 Commodore-Amiga도 1985년에 IFF(Interchange File Format) 파일 포맷과 함께 이러한 파일 형식을 사용했습니다.

컨테이너를 "chunk"라고 부르기도 합니다.단, "chunk"는 각 조각이 작거나 다른 청크를 포함하지 않는 것을 의미할 수도 있습니다.많은 포맷은 이러한 요건을 부과하지 않습니다.

특정 "chunk"를 식별하는 정보는 "field name", "identifier", "label" 또는 "tag"와 같은 여러 가지 용어로 불릴 수 있습니다.식별자는 종종 사람이 읽을 수 있으며 데이터의 일부(예: "surname", "address", "prectangle", "font name" 등)를 분류합니다.이것들은 데이터베이스 키나 시리얼 번호의 의미에서는 식별자와는 다릅니다(단, 식별자는 관련 데이터를 키로 식별할 수 있습니다).

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

이 개념은 RIFF(IFF에 상당하는 Microsoft-IBM), PNG, JPEG 스토리지, DER(Distinguished Encoding Rules) 인코딩된 스트림과 파일(원래 CCITT X.409:1984에서 설명되었으므로 IFF보다 이전 버전인 Structured Data Format(SDF; 구조화 데이터 교환 규칙)에 의해 여러 번 사용되고 있습니다.

실제로 모든 데이터 형식은 구성요소 부분의 중요성을 식별해야 하며, 임베디드 경계 표시기가 이를 위한 명백한 방법입니다.

  • MIME 헤더는 이를 위해 각 논리행의 선두에 콜론으로 구분된 라벨을 사용합니다.일부 헤더의 데이터 내용에는 다른 규칙에 따라 추출할 수 있는 하위 부분이 있지만 MIME 헤더는 다른 MIME 헤더를 포함할 수 없습니다.
  • CSV 및 유사한 파일에서는 필드 이름과 쉼표를 사용하여 필드 경계를 표시하는 헤더레코드를 사용하는 경우가 많습니다.MIME과 마찬가지로 CSV에는 여러 레벨을 가진 구조에 대한 프로비저닝이 없습니다.
  • XML 및 XML의 kin은 데이터 요소가 청크 식별자와 유사한 마크업으로 식별되기 때문에 느슨하게 청크 기반 형식이라고 볼 수 있습니다.그러나 스키마 및 검증과 같은 공식적인 이점은 물론 트리, DAG, 차트 등의 보다 복잡한 구조를 나타낼 수 있습니다.XML을 "chunk" 형식으로 간주하는 경우, SGML과 그 이전 IBM GML이 이러한 형식의 가장 초기 예에 속합니다.
  • JSON은 스키마, 상호 참조 또는 반복 필드 이름의 의미에 대한 정의가 없는 XML과 유사하며 프로그래머에게 종종 편리합니다.
  • YAML은 JSON과 비슷하지만 들여쓰기를 사용하여 데이터 청크를 구분하고 JSON이나 XML보다 사람이 읽기 쉬운 것을 목표로 합니다.
  • Protocol Buffer는 JSON과 유사하며, 특히 데이터의 경계 마커를 필드 번호로 대체하며, 필드 번호는 외부 메커니즘에 의해 이름에 매핑됩니다.

디렉토리 기반 형식

이것은 파일 시스템(OLE Documents는 실제 파일 시스템)과 매우 유사한 확장 가능한 또 다른 형식입니다.여기서 파일은 파일 자체의 데이터 위치 및 서명(경우에 따라서는 그 유형)을 포함하는 '디렉토리 엔트리'로 구성됩니다.이러한 파일 구조의 좋은 예로는 디스크 이미지, OLE 문서 TIFF, 라이브러리 등이 있습니다.PKZIP 기반인 ODT 및 DOCX는 청크되며 디렉토리도 전송됩니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ PC World (23 December 2003). "Windows Tips: For Security Reasons, It Pays To Know Your File Extensions". Archived from the original on 23 April 2008. Retrieved 20 June 2008.
  2. ^ "File Format Identification". Archived from the original on 2009-08-14. Retrieved 2009-07-21.

외부 링크

무료 사전인 Wiktionary에서 파일 형식을 검색합니다.
라이브러리 리소스 정보
파일 사용