Hussein Shafie wrote: > The file extension of "test.image.jpg" is considered to be "image.jpg" > and not "jpg". And, of course, "image.jpg" is an unsupported format. > > This seems stupid because, in your case, the file extension is obviously > "jpg". But in the general case, this is not always true. Example: > xxe-perso-4_1_0.tar.gz (the file extension is "tar.gz" and not "gz") > > No, the extension is gz which tells you that this is a compressed file. Because the file type tells you that there is another file within, then you can look at that extension and see that it is tar - so you have a compressed archive.
That may lead you to say that the extension is 'tar.gz' but this is imprecise and misleading because you can only say this because you know what the file types are (i.e. what the extension means). Consider the equally sensible filename (in Unix at least) of xxe-perso-4.1.0.tar.gz. Is the extension still tar.gz or 1.0.tar.gz? > Therefore, we are currently not 100% sure that this problem needs to fixed. > > > In my own products I always treat the file extension as the part after the *last *period, not the first. Given the above isn't this the only robust way to do it? (Aside - I just looked in Windows at the file types, and though there are none with periods in you can add one. I have not experimented to see if this actually works, especially in the case where the 'smaller' extension already exists - does it recognise x.tar.gz as gz or tar.gz? But then experiments are a poor second to clear thinking when it comes to design IMHO. It is certainly true that Windows recognises x.y.jpg as a JPEG file and not an unknown type.) Trevor Nash -- Melvaig Technologies Limited voice: +44 (0) 1445 771363 email: tcn at melvaig.co.uk web: http://www.melvaig.co.uk Registered in Scotland No 194737 5 Melvaig, Gairloch, Ross-shire IV21 2EA -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.xmlmind.com/pipermail/xmleditor-support/attachments/20081008/579c4152/attachment.htm
