Shared MIME-info Database


Table of Contents
1. Introduction
1.1. Version
1.2. What is this spec?
1.3. Language used in this specification
2. Unified system
2.1. Directory layout
2.2. The source XML files
2.3. The MEDIA/SUBTYPE.xml files
2.4. The glob files
2.5. The magic files
2.6. The XMLnamespaces files
2.7. The icon files
2.8. The treemagic files
2.9. The mime.cache files
2.10. Storing the MIME type using Extended Attributes
2.11. Subclassing
2.12. Recommended checking order
2.13. Non-regular files
2.14. Content types for volumes
2.15. URI scheme handlers
2.16. Security implications
2.17. User modification
3. Contributors
References

1. Introduction

1.1. Version

This is version 0.20 of the Shared MIME-info Database specification, last updated 8 October 2010.

1.2. What is this spec?

Many programs and desktops use the MIME system[MIME] to represent the types of files. Frequently, it is necessary to work out the correct MIME type for a file. This is generally done by examining the file's name or contents, and looking up the correct MIME type in a database.

It is also useful to store information about each type, such as a textual description of it, or a list of applications that can be used to view or edit files of that type.

For interoperability, it is useful for different programs to use the same database so that different programs agree on the type of a file and information is not duplicated. It is also helpful for application authors to only have to install new information in one place.

This specification attempts to unify the MIME database systems currently in use by GNOME[GNOME], KDE[KDE] and ROX[ROX], and provide room for future extensibility.

The MIME database does NOT store user preferences (such as a user's preferred application for handling files of a particular type). It may be used to store static information, such as that files of a certain type may be viewed with a particular application.

1.3. Language used in this specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119[RFC-2119].