MIME types are just a way to name types. They don't have anything to do with how the type of a file is determined.
There are two ways to determine the type of a file: a) Look at its extension and hope that it is accurate or b) look at its contents and then guess based on that. If a file has no extension b is the only option.
Many (binary) file formats have a specific header that you can look at to determine their type. This makes option b quite reliable for those types.
Plain text file formats can often be determined by their structure (if a file contains a lot of html tags, it's probably a html file).
On unix and linux systems you can use the file
command line utility to find out the type of a file based on its contents.
File manager often use some combination of option a and b (e.g. look at the file extension first, if it's not known (or the file does not have an extension), look at the contents).
A file's type is not stored as metadata on common linux file systems.
Years later, I've made a small utility that scans MIME database (both system and user) and register all known native mime-types in Windows registry.
It uses xdg-open
to open a file if there is a default (native) application for that
mime type, otherwise uses packagekit
to search for a package that can handle
that file (just like what Nautilus does). So my initial requirement of registering only extensions that have an installed, native application was not needed anymore. However, an early version of the script did filter only such types. The snippet that made it possible was:
perl -e '
use strict; use warnings;
use File::MimeInfo::Magic; use File::MimeInfo::Applications;
while (my $line = <STDIN>) {
chomp($line);
my ($ext, $mime) = (split/\t/, $line);
my ($def, @apps) = mime_applications_all($mime);
print "$line\n" if ($def || @apps)
}'
By default my script only registers native types that have no handler in windows
registry, but it can also override such associations (so, for example, jpeg
files are opened in native viewer instead of the default Gecko wine browser).
It can also ignore some extensions even if they have no handler in windows.
It tries its best to be winemenubuilder-friendly, meaning all associations it
creates is not published as native associations (or as x-wine-extension
mimetypes) by winemenubuilder, which would be ugly and potentially cause loops.
This is very tricky and not yet perfect, specially with mixed-case extensions
(.C and .c for example)
That said, I hope this script is helful for everyone:
https://github.com/MestreLion/wine-tools/blob/master/wine-import-extensions
Improvements welcome!
Best Answer
I suggest Ubuntu-Tweak to configure the file associations, as Anwar Shah suggests here: Change all associations from gedit to another application.
First you must download the installer (a .deb file) from http://ubuntu-tweak.com/. Then open the file and install the program from Ubuntu Software Center. Finally, Open Ubuntu-Tweak an go to Admins -> File Type Manager.
At the list, look for your filetype and clic Edit -> Add to choose your custom application.
If you are trying to associate a Wine app (i. e. MS-Word to open .doc and .docx filetypes), you can add the application to the list if you edit the .desktop file located in ~/.local/share/applications/. Then, locate the "Exec=" parameter and, at the end of the line, add %U.
For MS-Word 2007:
At the end of "Exec=" line, add %U. My file looks like this now:
For more detailed info, look the answer of user24185 at: How to associate file types with wine in nautilus.