Hello,

I need this now and after some Googling I couldn't find anything. So I was wondering, maybe we already have this somewhere in FPC or Lazarus? If not it might be something to consider adding to LazUtils.

Hi,

you should look at turbopower_ipro/iputils.pas - it has function GetLocalContent(const TheFileName: string): string; with valid windows implementation and array-lookup for other OS'es.

Also there is lmimewrapper.pp in LNet:
procedure TMimeFileSection.SetContentType(const aFileName: string);

it has a big IF statement for selecting type.

Regards,
?ilvinas

No, we don't have a builtin one. However using any mime.types file (I forgot where I got mine, it's either from one of fpweb/lnet demo or my apache/php installation) you can do what you want:

uses
  fpmimetypes;
...
TheMimeType := MimeTypes.GetMimeType(ExtractFileExt(AFileName));
// TheMimeType now contains, e.g., 'application/octet-stream'

Oh, I forgot that you need to:

MimeTypes.LoadFromFile(AMimeTypesFile);

first.

On what platform? On Windows you'd want something related to ftype/assoc (i.e. possibly looking at the underlying registry), on some (but possibly not all) unix desktops xdg-mime. In the latter cases it's very much dependent on the distro providing the xdg- family of tools, and also on there being an active desktop session (not just a remote shell).

wouldn't it be better to use mimemagic instead of relying on the file's extension?

i can easily name foo.gif as foo.txt and those systems that do properly look into the file to determine its format/type will open it with the proper tool instead of bringing it up in the app indicated by the extension...

FPC contains this unit:

fpmimetypes.pp

It is used by fcl-web. On linux, it loads /etc/mime.types. On windows not yet, I must still look up how to do this.

Michael.

waldo kitty wrote

wouldn't it be better to use mimemagic instead of relying on the file's extension?

You mean opening the file and reading the first bytes? For my use case that's an over complication, and subject to multiple possible errors: Permission errors for example. Not really nice.

I am implementing LCLIntf.OpenDocument and LCLIntf.OpenURL for Android, and here it might be good to just let whatever app that is choosen handle the file and never open it myself.

i can easily name foo.gif as foo.txt and those systems that do properly look

Though luck of whoever changed the extension. That makes choosing the file in dialogs also problematic. I don't care about this use case.

FPC contains this unit: fpmimetypes.pp It is used by fcl-web. On linux, it loads /etc/mime.types. On windows not yet, I must still look up how to do this.

I just opened "adb shell" and there is no such file in my HTC Wildfire.

I'd really like a standard list here. As less system-dependent as possible.

Distribute a mime.types from a unix box with your app and load this in the fpmimetypes unit using the provided function.

That's what I do on Windows. By far the easiest solution :)

Michael.

Distribute a mime.types from a unix box with your app and load this in the fpmimetypes unit using the provided function. That's what I do on Windows. By far the easiest solution :)

My code is the LCL, so I cannot do that without forcing all LCL-CustomDrawn-Android users to deploy this file. I think I will steal the code from TurboPower iPro and put it somewhere in LazUtils.

+1

Windows and Mac OS X fails that test. Linux rules in that regards. :)

Side note:
Sad thing is, I believe Mac OS 9 and earlier used to use mimemagic, but with OS X they simply look at the file extension - dumb move.

It is used by fcl-web. On linux, it loads /etc/mime.types.

I don't know the exact format of that file, I guessed "mime type name" then "file extension list"

But on my Ubuntu 10.04 that file has many lines only showing the "mime type name" with no extension mentioned. So how reliable is that file really?

I know Linux (at least Gnome) uses magic numbers (first 2-4 bytes of a file) to detect the real file type without looking at the file extension. These magic numbers information is stored somewhere in linux (can't remember where now), and it includes the magic number and mime type mapping. I'll see if I can find the file I am talking about. But as with everything Linux, this is probably highly distro specific etc.

That's what I do on Windows. By far the easiest solution :)

Ingenious solution. :-)

/usr/share/misc/magic.mgc (which on my system is a symlink to somewhere else). It's a big file: 1.8MB.

Linking to libmagic will get you most the functionality of the `file` command, afaik.

Henry

Correct.

Based on my personal experience: very.
I've had this file in use since 18 years at least, since the first NCSA webserver installations.

I know Linux (at least Gnome) uses magic numbers (first 2-4 bytes of a file) to detect the real file type without looking at the file extension.

A webserver does not do that. It uses the mime file.

the 'file' command looks at the magic numbers, but for example KDE looks at the extension.

Michael.

On windows it looks in the registry. Good luck with that on Android :-)

For other OSes there are about 4 or 5 mime types defined. Not really useful.

So my suggestion is probably still the best. I don't see why you'd need to force this on all users, only the ones that need mime types need the file ?

Or you could convert it to an include file that just registers all more or less known types in fpmimetypes.pp. Then people can include this include file and be done with it.

Michael.

yeah, i remember when we were playing with this back when fidonet was in its heyday... many in the programming echos were looking at this for their tools and apps they were writing :)

Side note: Sad thing is, I believe Mac OS 9 and earlier used to use mimemagic, but with OS X they simply look at the file extension - dumb move.

definitely a dumb move... especially when tricks like using the wrong extension are used in malware, trojan and virus attacks...

yes, it is the best way... but not all are at the beginning, either...

For my use case that's an over complication, and subject to multiple possible errors: Permission errors for example. Not really nice.

true... but then the user wouldn't have access to those files, either... correct?

I am implementing LCLIntf.OpenDocument and LCLIntf.OpenURL for Android, and here it might be good to just let whatever app that is choosen handle the file and never open it myself.

ahhh, yes... that would be the easiest...

> i can easily name foo.gif as foo.txt and those systems that do properly look Though luck of whoever changed the extension. That makes choosing the file in dialogs also problematic. I don't care about this use case.

understood... it has been used in exploits, though... especially in the winwhatever world and is still used quite regularly... those of us in the security world have network traffic sniffers specifically looking for traffic that says it is one mime type yet the file extension says it is another and finally the magic numbers say it is something else altogether... this traffic is definitely red flag traffic and warrants a deeper look...

Please see "MimeTypeFromExt" function in Synapse project:

https://synalist.svn.sourceforge.net/svnroot/synalist/trunk/mimepart.pas

silvioprog wrote

Please see "MimeTypeFromExt" function in Synapse project: https://synalist.svn.sourceforge.net/svnroot/synalist/trunk/mimepart.pas

The default list in synapse is very small.

I just created my own list:

http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/lcl/interfaces/customdrawn/customdrawnobject_android.inc?root=lazarus&r1=37244&r2=37243&pathrev=37244

2012/5/10 Felipe Monteiro de Carvalho :

Nice.

the 'file' command looks at the magic numbers, but for example KDE looks at the extension.

my KDE, sic 3, looks at the magic numbers... I can rename a .pdf to whatever, even no extension at all, an it will still display the correct icon and open it with adobe reader.

So maybe with KDE 4 they did the same silly OS X move...

A.