Файлови формати

от Уикипедия, свободната енциклопедия

ВНИМАНИЕ: Тази статия се нуждае от частичен или цялостен превод. Ако имате познания по използвания език, не се колебайте! Благодарим Ви, че помагате на Уикипедия!

Начинът по който се съхранява информацията в даден файл се нарича файлов формат.

Тъй като дисковете (disk drive) или всъщност всяко устройство за съхранение на данни може да съхранява само битове, компютърът трябва да има някакъв начин за преобразуване на информацията в нули и единици и обратно. Има различни видове формати за различните видове информация. Всеки формат, например word processor documents, например, само по себе си се състои от няколко различни подформата. Понякога тези формати се съревновават един с друг.

[редактиране] Обща част

Някои файлови формати са създадени, за да съхраняват строго определени типове данни: JPEG форматът, например, е разработен, за да съхранява само статични фотографски изображения. Други формати, обаче, са разработени за да съхраняват различни типове данни: GIF форматът подържа както статични изображения, така и прости анимации, а QuickTime форматът може да се използва като контейнер за различни типове multimedia. Текстов файл е просто филе, който съдържа текст кодиран като ASCII или UTF-8, с малко, ако въобще ги има контролни знаци. Някои файлови формати като HTML, или сорс кода (source code) на някой програмен език, всъщност също са текстови файлове, но отговарят на някои по-специлани правила, които позволяват да бъдат използвани и за други специфични цели.

Възможно е понякога да накараме дадена програма да прочете файл кодиран по един начин все едно, че е кодиран по друг. Например можем да пуснем един Microsoft Word документ все едно че е песен, като използаме прграма за слушане на музика, която борави с безхедърни ("headerless") аудио файлове. Но резултатът със сигурност няма да звучи особено мелодично... Причината за това е, че подредба на битовете, която е смислена за един формат, почти винаги е безсмислена в друг формат.

[редактиране] Спецификации

Много файлови формати включително повечето популярни формати имат публикувани спецификации (обикновено с reference implementation), които описват точно как данните трябва да бъдат кодирани и определят дали дадена програма обработва даден компютърен фрмат коректно. Има две причини, поради които не винаги има спецификация. Първата е, че някои от разработчиците на файлови формати считат техните документи за спецификация за търговска тайна и по тази причина не ги правят публично достояние. Втората - някои от разработчиците на файлови формати никога не хабят време за писането на документация за спецификация; в такъв случай файловият формат по-скоро се определя от самата програма, която го интерпретира.

Using file formats without a publicly available specification can be costly. Learning how the format works will require either reverse engineering it from a reference implementation or acquiring the specification document for a fee from the format developers. This second approach is possible only when there is a specification document, and typically requires the signing of a non-disclosure agreement. Both strategies require significant time, money, or both. Therefore, as a general rule, file formats with publicly available specifications are supported by a large number of programs, while non-public formats are supported by only a few programs.

Patent law, rather than copyright, is more often used to protect a file format. Although patents for file formats are not directly permitted under US law, some formats require the encoding of data with patented algorithms. For example, the GIF file format requires the use of a patented algorithm, and although initially the patent owner did not enforce it, they later began collecting fees for use of the algorithm. This has resulted in a significant decrease in the use of GIFs, and is partly responsible for the development of the alternative PNG format. However, the patent expired in the US in mid-2003, and worldwide in mid-2004. Algorithms are usually held not to be patentable under current European law, which also includes a provision that members "shall ensure that, wherever the use of a patented technique is needed for a significant purpose such as ensuring conversion of the conventions used in two different computer systems or networks so as to allow communication and exchange of data content between them, such use is not considered to be a patent infringement", which would apparently allow implementation of a patented file system where necessary to allow two different computers to interoperate.^[1]

[редактиране] Идентифициране на типа на файла

Програмите виждат файловете като потоци от дани, следователно нужен е метод чрез който да се определи форматът на определен файл от файловата система—един пример за използване на метаданни. Различните операционни системи по традиция използват различни подходи към този проблем, като всеки подход има своите предимства и недостатъци.

Разбира се, повечето модерни операционни системи, както и самостоятелни приложения, трябва да могат да използват всеки един от тези подходи за да обработват различни файлове, или ако не могат да работят пълноценно, поне да четат 'чужди' файлови формати.

[редактиране] Разширения на файловите имена

Един популярен метод, който се използва при някои операционни системи, в това число Mac OS X, CP/M, DOS, VMS, VM/CMS, и Windows, е да се определя форматът на файла на базата на частта от неговото име след последната точка. Тази част от файла е известна като разширение. Например, HTML документите се идентифицират с имена завършващи с .html (или .htm), а GIF изображенията чрез .gif. В оригиналната FAT файлова система, файловите имена бяха ограничени до осем символа за идентификатор и до три символа като разширение, което е известно като 8.3 filename. Поради това много формати все още използват разширения от три символа, въпреки, че модерните операционни системи и приложения вече нямат това ограничение. Тъй като няма стандартен списък с разширения, повече от един формат могат да използват едно и също разширение, което може да обърка операционната система а в последствие и потрбителите.

Една особеност на този подход е, че системата може лесно да бъде измамена да третира файла като различен формат просто като се преименува — един HTML файл, напрмер, може лесно де се третира като обикновен текст като се преименува от filename.html на filename.txt. Although this strategy was useful to expert users who could easily understand and manipulate this information, it was frequently confusing to less technical users, who might accidentally make a file unusable (or 'lose' it) by renaming it incorrectly. This led more recent operating system shells, such as Windows 95 and Mac OS X, to hide the extension when displaying lists of recognized files. This separates the user from the complete filename, preventing the accidental changing of a file type, while allowing expert users to still retain the original functionality through enabling the displaying of file extensions.

[редактиране] Магическо число

Шаблон:Seealso An alternative method, often associated with Unix and its derivatives, is to store a "magic number" inside the file itself. Originally, this term was used for a specific set of 2-byte identifiers at the beginning of a file, but since any undecoded binary sequence can be regarded as a number, any feature of a file format which uniquely distinguishes it can be used for identification. GIF images, for instance, always begin with the ASCII representation of either GIF87a or GIF89a, depending upon the standard to which they adhere. Many file types, most especially plain-text files, are harder to spot by this method. HTML files, for example, might begin with the string <html> (which is not case sensitive), or an appropriate document type definition that starts with <!DOCTYPE, or, for XHTML, the XML identifier, which begins with <?xml. The files could also begin with any random text or several empty lines, but still be usable HTML.

This approach offers better guarantees that the format will be identified correctly, and can often determine more precise information about the file. Since reliable "magic number" tests can be fairly complex, and each file must effectively be tested against every possibility in the magic database, this approach is also relatively inefficient, especially for displaying large lists of files (in contrast, filename and metadata-based methods need check only one piece of data, and match it against a sorted index). Also, data must be read from the file itself, increasing latency as opposed to metadata stored in the directory. Where filetypes don't lend themselves to recognition in this way, the system must fall back to metadata. It is, however, the best way for a program to check if a file it has been told to process is of the correct format: while the file's name or metadata may be altered independently of its content, failing a well-designed magic number test is a pretty sure sign that the file is either corrupt or of the wrong type.

So-called shebang lines in script files are a special case of magic numbers. Here, the magic number is human-readable text that identifies a specific command interpreter and options to be passed to the command interpreter.

[редактиране] Explicit metadata

A final way of storing the format of a file is to explicitly store information about the format in the file system.

This approach keeps the metadata separate from both the main data and the name, but is also less portable than either file extensions or "magic numbers", since the format has to be converted from filesystem to filesystem. While this is also true to an extent with filename extensions — for instance, for compatibility with MS-DOS's three character limit — most forms of storage have a roughly equivalent definition of a file's data and name, but may have varying or no representation of further metadata.

Note that zip files or archive files solve the problem of handling metadata. A utility program collects multiple files together along with metadata about each file and the folders/directories they came from all within one new file (e.g. a zip file with extension .zip). The new file is also compressed and possibly encrypted, but now is transmissible as a single file across operating systems by FTP systems or attached to email. At the destination, it must be unzipped by a compatible utility to be useful, but the problems of transmission are solved this way.

[редактиране] Mac OS type-codes

The Mac OS' Hierarchical File System stores codes for creator and type as part of the directory entry for each file. These codes are referred to as OSTypes, and for instance a HyperCard "stack" file has a creator of WILD (from Hypercard's previous name, "WildCard") and a type of STAK. RISC OS uses a similar system, consisting of a 12-bit number which can be looked up in a table of descriptions — e.g. the hexadecimal number FF5 is "aliased" to PoScript, representing a PostScript file.

[редактиране] Mac OS X Uniform Type Identifiers (UTIs)

Шаблон:Main A Uniform Type Identifier (UTI) is a method used in Mac OS X for uniquely identifying "typed" classes of entity, such as file formats. It was developed by Apple as a replacement for OSType (type & creator codes).

The UTI is a Core Foundation string, which uses a reverse-DNS string. Common or standard types use the public domain (e.g. public.png for a Portable Network Graphics image), while other domains can be used for third-party types (e.g. com.adobe.pdf for Portable Document Format). UTIs can be defined within a hierarchical structure, known as a conformance hierarchy. Thus, public.png conforms to a supertype of public.image, which itself conforms to a supertype of public.data. A UTI can exist in multiple hierarchies, which provides great flexibility.

In addition to file formats, UTIs can also be used for other entities which can exist in the OS X file system, including:

Pasteboard data
Folders (directories)
Translatable types (as handled by the Translation Manager)
Bundles
Frameworks
Streaming data
Aliases and symlinks

[редактиране] OS/2 разширени атрибути

Файловите системи HPFS, FAT12 и FAT16 (но не и FAT32) позволяват съхранението на "разширени атрибути" заедно с файловете. These comprise an arbitrary set of triplets with a name, a coded type for the value and a value, where the names are unique and values can be up to 64 KB long. There are standardized meanings for certain types and names (under OS/2). One such is that the ".TYPE" extended attribute is used to determine the file type. Its value comprises a list of one or more file types associated with the file, each of which is a string, such as "Plain Text" or "HTML document". Thus a file may have several types.

Файловата система NTFS също позволява съхраняването на OS/2 разширени атрибути, as one of file forks, но тази възможнаст присъства само за да поддържа OS/2 подсистемата (не присъства в XP), така, че Win32 подситемата третира тази информация като неразбираем блок от данни и не го използва. Вместо това се разчита на на други файлови разклонения за съхраняването на мета-информация в Win32-специфични формати. OS/2 разширените атрибути все пак могат да бъдат четени и записвани от Win32 програмите, но данните трябва да бъдат изцяло интерпретирани от съответното приложение.

[редактиране] POSIX разширени атрибути

При файловите системи Unix и Uiix-подобни, ext2, ext3, ReiserFS версия 3, XFS, JFS, FFS и HFS+ се позволява съхраняването на разширени атрибути заедно с файловете. Това са произволен списък от стрингове от типа "име=стойност" (като имената са уникални), които могат да бъдат достъпени с техните "име"-части.

[редактиране] PRONOM Unique Identifiers (PUIDs)

The PRONOM Persistent Unique Identifier (PUID) is an extensible scheme of persistent, unique and unambiguous identifiers for file formats, which has been developed by The National Archives of the UK as part of its PRONOM technical registry service. PUIDs can be expressed as Uniform Resource Identifiers using the info:pronom/ namespace. Although not yet widely used outside of UK government and some digital preservation programmes, the PUID scheme does provide greater granularity than most alternative schemes.

[редактиране] MIME типове

MIME types are widely used in many Internet-related applications, and increasingly elsewhere, although their usage for on-disc type information is rare. These consist of a standardised system of identifiers (managed by IANA) consisting of a type and a sub-type, separated by a slash — for instance, text/html or image/gif. These were originally intended as a way of identifying what type of file was attached to an e-mail, independent of the source and target operating systems. MIME types identify files on BeOS, as well as store unique application signatures for application launching.

There are problems with the MIME types though; several organisations and people have created their own MIME types without registering them properly with IANA, which makes the use of this standard awkward in some cases.

[редактиране] Идентификатори на файловия формат (FFIDs)

File format identifiers is another, not widely used way to identify file formats according to their origin and their file category. It was created for the Description Explorer suite of software. It is composed of several digits of the form NNNNNNNNN-XX-YYYYYYY. The first part indicates the organisation origin/maintainer (this number represents a value in a company/standards organisation database), the 2 following digits categorize the type of file in hexadecimal. The final part is composed of the usual file extension of the file or the international standard number of the file, padded left with zeros. For example, the PNG file specification has the FFID of 000000001-31-0015948 where 31 indicates an image file, 0015948 is the standard number and 000000001 indicates the ISO Organisation.

[редактиране] Файлова структура

Има различни начини за структуриране на данните във файл. Най-често използваните са описани по-долу.

[редактиране] Raw memory dumps/unstructured formats

Earlier file formats used raw data formats that consisted of directly dumping the memory images of one or more structures into the file.

This has several drawbacks. Unless the memory images also have reserved spaces for future extensions, extending and improving this type of structured file is very difficult. It also creates files that might be specific to one platform or programming language (for example a structure containing a Pascal string is not recognized as such in C). On the other hand, developing tools for reading and writing these types of files is very simple.

The limitations of the unstructured formats led to the development of other types of file formats that could be easily extended and be backward compatible at the same time.

[редактиране] Chunk based formats

Electronic Arts and Commodore-Amiga pioneered this file format in 1985, with their IFF (Interchange File Format) file format. In this kind of file structure, each piece of data is embedded in a container that contains a signature identifying the data, as well the length of the data (for binary encoded files). This type of container is called a chunk. The signature is usually called a chunk id, chunk identifier, or tag identifier.

With this type of file structure, tools that do not know certain chunk identifiers simply skip those that they do not understand.

This concept has been taken again and again by RIFF (Microsoft-IBM equivalent of IFF), PNG, JPEG storage, DER (Distinguished Encoding Rules) encoded streams and files, and Structured Data Exchange Format (SDXF). Even XML can be considered a kind of chunk based format, since each data element is surrounded by tags which are akin to chunk identifiers.

[редактиране] Directory based formats

This is another extensible format, that closely resembles a file system (OLE Documents are actual filesystems), where the file is composed of 'directory entries' that contain the location of the data within the file itself as well as its signatures (and in certain cases its type). Good examples of these types of file structures are disk images, OLE documents and TIFF images.