Lukas V is IMO missing some point. The MIME type of a file may not be corresponding to the file suffix.

Imagine someone would obfuscate some PHP code in a .gif file, the file suffix would be 'GIF' but the MIME would be text/plain or even text/html.

Another example is files fetched via a distant server (wget / fopen / file / fsockopen...). The server can issue an error, i.e. 404 Not Found, wich again is text/html, whatever you save the file to (download_archive.rar).

His provided function should begin by the test of the function existancy like :

I see a lot of comments suggesting doing file extension sniffing (i.e. assuming .jpg files are JPEG images) when proper file-type sniffing functions are unavailable.I want to point out that there is a much more accurate way.If neither mime_content_type() nor Fileinfo is available to you and you are running *any* UNIX variant since the 70s, including Mac OS, OS X, Linux, etc. (and most web hosting is), just make a system call to 'file(1)'.Doing something like this:<?phpecho system("file -bi '<file path>'");?>will output something like "text/html; charset=us-ascii". Some systems won't add the charset bit, but strip it off just in case.The '-bi' bit is important. However, you can use a command like this:<?phpecho system("file -b '<file path>'"); // without the 'i' after '-b'?>to output a human-readable string, like "HTML document text", which can sometimes be useful.The only drawback is that your scripts will not work on Windows, but is this such a problem? Just about all web hosts use a UNIX.It is a far better way than just examining the file extension.

Here's a simple function to return MIME types, based on the Apache mime.types file. [The one in my previous submission, which has since been replaced by this one] only works properly if mime.types is formatted as Windows text. The updated version below corrects this problem. Thanks to Mike for pointing this out.

Notes:
[1] Requires mime.types file distributed with Apache (normally found at ServerRoot/conf/mime.types). If you are using shared hosting, download the file with the Apache distro and then upload it to a directory on your web server that php has access to.

[2] First param is the filename (required). Second parameter is path to mime.types file (optional; defaults to home/etc/).

Since I enabled the mime_magic extension on my IIS, I also got the error message "invalid magic file, disabled" in my phpinfo. After I add these lines to my php.ini, the message disappeared and it works great!

and string detection on text files may fail if you check a file encoded with signed UTF-8. The UTF-8 signature is a two bytes code (0xFF 0xFE) that prepends the file in order to force UTF-8 recognition (you may check it on an hexadecimal editor).

The first one may not work if "<?php" is not at the very beginning of your file, e.g., if some HTML preceeds the first bit of PHP code. The second one should work because "<?xml" *should* be the first thing in every XML file.

The function mime_content_type only worked for me on Microsoft Windows after I added the directive "mime_magic.debug" to my php.ini with the value of "On". The default value appears to be "Off". Exampe:

I'm not sure if anyone is still using the functions shown below (I'm guessing someone must still be, since the latest update to the functions was made a few months ago), but I think you'd be better off using an explode statement rather than the regex shown in most of the functions to find the filesuffix.

The regex shown is only going to catch files with extensions between 2 and 4 characters. While filenames with more or less than that are extremely rare, they do exist. If you open the regex up to start accepting those types of things, however, you're making your life complicated for no reason.

In addition, I don't see the need for the overhead produced by the preg_match function when you could just use the explode and array_pop functions together.

If you explode the filename, using the dot as a separator, you can simply pop the last element off of the array to get the real file extension, no matter how short or long it is, without the overhead of a regex (unless one of those functions calls a regex in the background of which I'm not aware).

Therefore, where the regex would return no results on something like:/var/www/html/example.backupor/var/www/html/example-program.c

the explode function would simply split it wherever it finds a dot and you can pop the last one off:

Then, to put the rest of the file name back together, you can use the implode function on the remainder of the finfo array. Alternatively, when putting the rest of the file name back together, you could use the str_replace function to replace the dot and the extension with nothing, but then you run the rare risk of removing the same string from the middle of the file name somewhere (not very likely, but possible nonetheless).

Also, on a side note, the last function example is going to return the wrong value if the file extension is not in the list and the mime_content_type function exists. Because that part of the function re-sets the $fileSuffix variable, without returning a value, the function is going to move on to the next statement, which is only going to return the first letter of whatever was returned by the mime_content_type function.