Why does the FindMimeFromData function from Urlmon.dll return MIME type “application/octet-stream” for many file types, whereas checking MIME type by file extension (I.e. against windows registry) returns a more precise type?
For example, mp3 is an “application/octet-stream” instead of “audio/mp3”.
Basically, I want to verify an uploaded file with incorrect extension. This method seems to work for many image files, xml, etc.
The question is similar to this one, but the provided solution is not suited for validating uploaded files, because of different/ambiguous MIME types returned.
Reading the documentation for FindMimeFromData lead me to MIME Type Detection in Internet Explorer. According to that information it is hard-coded to find 26 different MIME types, which is quite small in today's world. "audio/mp3" is not one of them.
FindMimeFromData contains hard-coded tests for (currently 26) separate MIME type (see Known MIME Types). This means that if a given buffer contains data in the format of one of these MIME types, a test exists in FindMimeFromData that is designed (by scanning through the buffer contents) to recognize the corresponding MIME type. A MIME type is known if it is one of these N MIME types. A MIME type is ambiguous if it is "text/plain," "application/octet-stream," an empty string, or null (that is, the server failed to provide it).
Unfortunately, it looks like FindMimeFromData won't be very useful for determining modern MIME types.
There's a nice solution here: https://stackoverflow.com/a/9435701/74585 which tries to determine the file type from the registry (by file extension?) if FindMimeFromData returns "application/octet-stream" "text/plain" or nothing at all.
Here's a .NET file type detecting library http://filetypedetective.codeplex.com/ but it only detects a smallish number of files at the moment.
来源：https://stackoverflow.com/questions/4833113/why-does-the-findmimefromdata-function-from-urlmon-dll-return-mime-type-applica