# Content type detection

Here is another annoying and common programming-related problem: content type detection. The commonly applied solutions are:

Filename extensions
  Rather chaotic and unreliable, and usually just a convention, but available in most common scenarios.
MIME (or media) types
  These get standardised (though there are experimental/personal/vendor trees, so it's not hard to use for less common formats), and usually available in network protocols (should be the presentation OSI layer, in practice it's often HTTP) or emails. Since files are usually stored without an association with those, MIME types often get deduced using other methods (and/or just set to something generic) if they are used for static file transfer.
Heuristics (mostly with `file(1)` or `libmagic(3)`)
  Fundamentally unreliable and hacky, yet work sometimes. The other two occasionally are omitted, ignored, or wrong, so this one seems to be the most reliable in practice despite that.

Of course there are related controversies and implementation inconsistencies, and one has to decide what to apply on case-by-case basis.

It could have been mostly solved if each chunk of shared data had a MIME type associated with it right from the moment of authoring (akin to magic numbers, but with no/low likelihood of collisions), maybe via a single-line header only containing that type, yet apparently it's not realistic at all, judging by adoption and support of all the other standards. Would surely be controversial, too. As well as a less radical approach of using media types as filename extensions.

As usual, one can try to set a system like that locally (for oneself), which would take some time and effort, without much of benefit. But in general, reliably picking software for data/file processing (including viewing or editing by a user) is an unsolved problem, which is not likely to get solved in the observable future, and which is particularly annoying because it can be so simple. Though it's not alone in that.