In discussions about these systems, it was clear that the differences between the databases were simply a result of them being separate, and not due to any fundamental disagreements between developers. Everyone is keen to see them merged.
This specification proposes:
A standard way for applications to install new MIME related information.
A standard way of getting the MIME type for a file.
A standard way of getting information about a MIME type.
Standard locations for all the files, and methods of resolving conflicts.
Further, the existing databases have been merged into a single package [SharedMIME].
There are two important requirements for the way the MIME database is stored:
Applications must be able to extend the database in any way when they are installed, to add both new rules for determining type, and new information about specific types.
It must be possible to install applications in /usr, /usr/local and the user's home directory (in the normal Unix way) and have the MIME information used.
The directories to be used to store the files in the database are:
/usr/share/mime/
/usr/local/share/mime/
~/.mime/
In the rest of this document, paths shown with the prefix
<MIME> indicate the files should be loaded from
all the directories listed above. For example, “Load all the
<MIME>/text/html.xml files” means to load
/usr/share/mime/text/html.xml,
/usr/local/share/mime/text/html.xml, and
~/.mime/text/html.xml (if they exist).
Each application that wishes to contribute to the MIME database will install a
single XML file, named after the application, into one of the three
<MIME>/packages/ directories (depending on where the user requested
the application be installed). After installing, uninstalling or modifying this
file, the application MUST run the update-mime-database command,
which is provided by the freedesktop.org shared database[SharedMIME].
update-mime-database is passed the mime
directory containing the packages subdirectory which was
modified as its only argument. It scans all the XML files in the packages
subdirectory, combines the information in them, and creates a number of output files.
Where the information from these files is conflicting, information from directories
lower in the list takes precedence.
Any file named Override.xml takes precedence over all other files in
the same packages directory. Tools which let the user edit the
database should edit the file ~/.mime/packages/Override.xml.
The files created by update-mime-database are:
<MIME>/globs (contains a mapping from extension to MIME type)
<MIME>/magic (contains a mapping from file contents to MIME type)
<MIME>/MEDIA/SUBTYPE.xml (one file for each MIME
type, giving details about the type)
The format of these generated files and the source files in packages
are explained in the following sections. This step serves several purposes. First, it allows
applications to quickly get the data they need without parsing all the source XML files (the
base package alone is over 700K). Second, it allows the database to be used for other
purposes (such as creating the /etc/mime.types file if
desired). Third, it allows validation to be performed on the input data,
and removes the need for other applications to carefully check the input for
errors themselves.
Each application provides only a single XML source file, which is installed in the
packages directory as described above. This file is an XML file
whose document element is named mime-info and whose namespace URI
is http://www.freedesktop.org/standards/shared-mime-info. All elements
described in this specification MUST have this namespace too.
The document element may contain zero or more mime-type child nodes,
in any order, each describing a single MIME type. Each element has a type
attribute giving the MIME type that it describes.
Each mime-type node may contain any combination of the following elements,
and in any order:
glob elements have a pattern attribute. Any file
whose name matches this pattern will be given this MIME type (subject to conflicting rules in
other files, of course).
KDE's glob system replaces GNOME's and ROX's ext/regex fields, since it is trivial to detect a pattern in the form '*.ext' and store it in an extension hash table internally. The full power of regular expressions was not being used by either desktop, and glob patterns are more suitable for filename matching anyway.
magic elements contain a list of
match elements, any of which may match, and an optional
priority attribute for all of the contained rules. Low
numbers should be used for more generic types (such as 'gzip compressed data')
and higher values for specific subtypes (such as a word processor format that
happens to use gzip to compress the file). The default priority value is 50, and
the maximum is 100.
Each match element has a number of attributes:
| Attribute | Required? | Value |
|---|---|---|
| type | Yes |
string, host16,
host32, big16,
big32, little16,
little32 or byte.
|
| offset | Yes | The byte offset(s) in the file to check. This may be a single number or a range in the form `start:end', indicating that all offsets in the range should be checked. The range is inclusive. |
| value | Yes | The value to compare the file contents with, in the format indicated by the type attribute. |
| mask | No | The number to AND the value in the file with before comparing it to `value'. Masks for numerical types can be any number, while masks for strings must be in base 16, and start with 0x. |
Each element corresponds to one line of
file(1)'s magic.mime file.
They can be nested in the same way to provide the equivalent of continuation
lines.
comment elements give a human-readable textual description of the MIME
type. There may be many of these elements with different xml:lang attributes
to provide the text in multiple languages.
Applications may also define their own elements, provided they are namespaced to prevent collisions.
Unknown elements are copied directly to the output XML files like comment
elements. A typical use for this would be to indicate the default handler
application for a particular desktop
("Galeon is the GNOME default text/html browser"). Note that this doesn't
indicate the user's preferred application, only the (fixed) default.
Here is an example source file, named diff.xml:
<?xml version="1.0"?>
<mime-info xmlns='http://www.freedesktop.org/standards/shared-mime-info'>
<mime-type type="text/x-diff">
<comment>Differences between files</comment>
<comment xml:lang="af">verskille tussen lêers</comment>
...
<magic priority="50">
<match type="string" offset="0" value="diff\t"/>
<match type="string" offset="0" value="***\t"/>
<match type="string" offset="0" value="Common subdirectories: "/>
</magic>
<glob pattern="*.diff"/>
<glob pattern="*.patch"/>
</mime-type>
</mime-info>
In practice, common types such as text/x-diff are provided by the freedesktop.org shared database. Also, only new information needs to be provided, since this information will be merged with other information about the same type.
These files have a mime-type element as the root node. The format is
as described above. They are created by merging all the mime-type
elements from the source files and creating one output file per MIME type. Each file may contain
information from multiple source files. The magic and
glob elements will have been removed.
The example source file given above would (on its own) create an output file called
<MIME>/text/x-diff.xml containing the following:
<?xml version="1.0" encoding="utf-8"?> <mime-type xmlns="http://www.freedesktop.org/standards/shared-mime-info" type="text/x-diff"> <!--Created automatically by update-mime-database. DO NOT EDIT!--> <comment>Differences between files</comment> <comment lang="af">verskille tussen lêers</comment> ... </mime-type>
This is a simple list of lines containing a MIME type and pattern, separated by a colon. For example:
# This file was automatically generated by the # update-mime-database command. DO NOT EDIT! ... text/x-diff:*.diff text/x-diff:*.patch ...
Applications MUST first try a case-sensitive match, then a case-insensitive
one. This is so that main.C will be seen as a C++ file,
but IMAGE.GIF will still use the *.gif pattern.
If several patterns match then the longest pattern SHOULD be used. In
particular, files with multiple extensions (such as
Data.tar.gz) MUST match the longest sequence of extensions
(eg '*.tar.gz' in preference to '*.gz'). Literal patterns (eg, 'Makefile') must
be matched before all others. It is acceptable to match patterns of the form
'*.text' before other wildcarded patterns (that is, to special-case extensions
using a hash table).
There may be several rules mapping to the same type. They should all be merged. If the same pattern is defined twice, then they MUST be ordered by the directory the rule came from, as described above.
Common types (such as MS Word Documents) will be provided in the X Desktop Group's package, which MUST be required by all applications using this specification. Since each application will then only be providing information about its own types, conflicts should be rare.
The magic data is stored in a binary format for ease of parsing. The old magic database had complex escaping rules; these are now handled by update-mime-database.
The file starts with the magic string "MIME-Magic\0\n". There is no version number in the file. Incompatible changes will be handled by creating both the current `magic' file and a newer `magic2' in the new format. Where possible, compatible changes only will be made. All numbers are big-endian, so need to be byte-swapped on little-endian machines.
The rest of the file is made up of a sequence of small sections. Each section is introduced by giving the priority and type in brackets, followed by a newline character. Higher priority entries come first. Example:
[50:text/x-diff]\n
Each line in the section takes the form:
[ indent ] ">" start-offset "=" value [ "&" mask ] [ "~" word-size ] [ "+" range-length ] "\n"
| Part | Example | Meaning |
|---|---|---|
| indent | 1 | The nesting depth of the rule, corresponding to the number of '>' characters in the traditional file format. |
| ">" start-offset | >4 | The offset into the file to look for a match. |
| "=" value | =\0x0\0x2\0x55\0x40 | Two bytes giving the (big-endian) length of the value, followed by the value itself. |
| "&" mask | &\0xff\0xf0 | The mask, which (if present) is exactly the same length as the value. |
| "~" word-size | ~2 | On little-endian machines, the size of each group to byte-swap. |
| "+" range-length | +8 | The length of the region in the file to check. |
Note that the value, value length and mask are all binary, whereas everything else is textual. Each of the elements begins with a single character to identify it, except for the indent level.
The word size is used for byte-swapping. Little-endian systems should reverse the order of groups of bytes in the value and mask if this is greater than one. This only affects `host' matches (`big32' entries still have a word size of 1, for example, because no swapping is necessary, whereas `host32' has a word size of 4).
The indent, range-length, word-size and mask components are optional. If missing, indent defaults to 0, range-length to 1, the word-size to 1, and the mask to all 'one' bits.
Indent corresponds to the nesting depth of the rule. Top-level rules have an indent of zero. The parent of an entry is the preceding entry with an indent one less than the entry.
If an unknown character is found where a newline is expected then the whole line should be ignored (there will be no binary data after the new character, so the next line starts after the next "\n" character). This is for future extensions.
The text/x-diff above example would (on its own) create this magic file:
00000000 4d 49 4d 45 2d 4d 61 67 69 63 00 0a 5b 35 30 3a |MIME-Magic..[50:| 00000010 74 65 78 74 2f 78 2d 64 69 66 66 5d 0a 3e 30 3d |text/x-diff].>0=| 00000020 00 05 64 69 66 66 09 0a 3e 30 3d 00 04 2a 2a 2a |..diff..>0=..***| 00000030 09 0a 3e 30 3d 00 17 43 6f 6d 6d 6f 6e 20 73 75 |..>0=..Common su| 00000040 62 64 69 72 65 63 74 6f 72 69 65 73 3a 20 0a |bdirectories: .|
An implementation MAY also get a file's MIME type from the user.mime_type extended
attribute. The type given here should normally be used
in preference to any guessed type, since the user is able to set it explicitly. Applications MAY choose to
set the type when saving files. Since many applications and filesystems do not support extended attributes,
implementations MUST NOT rely on this method being available.
The system described in this document is intended to allow different programs to see the same file as having the same type. This is to help interoperability. The type determined in this way is only a guess, and an application MUST NOT trust a file based simply on its MIME type. For example, a downloader should not pass a file directly to a launcher application without confirmation simply because the type looks `harmless' (eg, text/plain).
Do not rely on two applications getting the same type for the same file, even if they both use this system. The spec allows some leeway in implementation, and in any case the programs may be following different versions of the spec.
The MIME database is NOT intended to store user preferences. Users should never edit the database. If they wish to make corrections or provide MIME entries for software that doesn't provide these itself, they should do so by means of the Override.xml mentioned in the section called “Directory layout”. Information such as "text/html files need to be opened with Mozilla" should NOT go in the database.