On 03/07/2011 09:19 AM, Johannes Pfau wrote:
Jonathan M Davis wrote:
On Sunday 06 March 2011 22:51:55 Christopher Nicholson-Sauls wrote:
On 03/07/11 00:24, Jonathan M Davis wrote:
On Sunday 06 March 2011 22:09:22 Nick Sabalausky wrote:
"Jonathan M Davis"<jmdavisp...@gmx.com> wrote in message
news:mailman.2280.1299459971.4748.digitalmar...@puremagic.com...
This reminds me. I should look into mime types one of these days
to see what the
appropriate way (if any) would be to put support for them in
Phobos. It would be
nice to not have to go by extension for the few programs that I
have which have
to worry about file type.
I'm no unix expert, but my understanding is that mime types in the
filesystem don't even exist at all, and that what it *really*
does is use some complex black-box-ish algorithm that takes into
account the first few bytes of the file, the extention, the exec
flag, and god-knows-what-else to determine what type of file it
is. Contrary to how people keep making it sound, mime type is
*not* the determining factor (and cannot possibly be), but rather
nothing more than the way the *result* of all that analysis is
represented.
I thought that the first few bytes of the file _were_ the mime
type. Certainly, from what I've seen, extension has _no_ effect on
most programs. Konqueror certainly acts like it does everything by
mime type
- file associations are set that way.
- Jonathan M Davis
As someone who uses hex editors quite a bit (resorting these days to
using Okteta mainly), I can tell you I have yet to see any file's
mime embedded at the beginning, nor have I seen it in any
headers/nodes when scanning raw. Doesn't mean it's impossible of
course, and certain file systems certainly might do this[1] but I
haven't seen it yet[2].
You are quite right, though, that extension doesn't matter at all,
except in certain corner cases. Even then, they are reasonable and
predictable things -- like SO's having the right extension.
Considering the posix convention of "hiding" files/directories by
starting the name with a dot, it'd be hard to rely on extensions in
any naive way anyhow. ;)
-- Chris N-S
[1] I'd just about expect the filesystem of BeOS/Haiku to do so, or
something similar to it at least.
[2] Also not saying I wouldn't want to see it, necessarily. Done
right, it'd be a damn nifty thing.
I've never studied mime types, so I don't know much about them. It's
just that it was my understanding the the first few bytes in a file
indicated its mime type. If that isn't the case, I have no idea how
you determine the mime type of a file or what's involved in doing so.
I _would_, however, like to have a way to get a file's mime type in D,
so one of these days, I'll likely be looking into the matter.
- Jonathan M Davis
The mime type can be saved as meta data on some filesystems, but it's
not in the file, it's an attribute:
-----------------------------------------------------
Storing the MIME type using Extended Attributes
An implementation MAY also get a file's MIME type from the
user.mime_type extended attribute. The type given here should normally
be used in preference to any guessed type, since the user is able to
set it explicitly. Applications MAY choose to set the type when saving
files. Since many applications and filesystems do not support extended
attributes, implementations MUST NOT rely on this method being
available.
-----------------------------------------------------
If this method is not available, programs look at the content of files
for specific patterns to guess the mime type. It's not the mime type
that is saved in the file though. Consider an mp3 file: there's no
"audio/mp3" in the file, but there always is a mp3 header. If a file
is scanned and a mp3 header is found, it's safe to assume the mime
type. Most file formats also have some kind of magic number at the
beginning, so it's easier to detect those.
More information:
http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-latest.html
I would definitely love an inter-OS standard for storing the MIME-type in every
file's first byte. Esp. the text encoding, when it's text (ask Walter why D
only supports UTF's, and even then the cost in complexity just to determine
which UTF (including byte-order!)). But we're not in such a world.
And you can be sure that numerous (super C experts) would oppose this because
of the space cost.
Denis
--
_________________
vita es estrany
spir.wikidot.com