D13315: Detect mime type of local files based on their contents

[Miklós Máté]

miklosm added a comment.


  In D13315#327933 <https://phabricator.kde.org/D13315#327933>, @dfaure wrote:
  
  > No, no. Too unreliable and against the MIME spec.
  >
  > You're testing it for the ideal case, images, which have proper headers.
  >  But there's no reliable "magic" (determination from content) to distinguish for example MSWord .doc vs Excel .xls, because it's all the same OLE storage format. Or many other cases like this.
  >  This is why the MIME spec (which is implemented by mimeTypeForUrl) says: if the extension is known and matches a single mimetype, then that's the one.
  >  This allows users to have control, rather than fuzzy algorithms.
  >
  > Determination from content is only used when there is no extension, when multiple mimetypes are associated with the same extension (example: *.ogg can be audio or video), or when the extension is completely unknown.
  
  
  I've seen web cms systems where all file downloads are named "download.php". Known extension. Matches a single mime type. Completely wrong.
  
  The case of MSWord vs. Excel is easy: Libreoffice can open both.
  
  > If some users want to benefit from magic-mimetype-detection for their images, it's simple, they can just remove all extensions, KDE will take care of the rest.
  >  But for all other cases, we want users to have control over the way their files are detected, and that's what extensions are for.
  
  I accept your reasoning.
  
  There may be an other solution to the problem I was trying to solve with this patch series: remove the jpeg thumbnailer, and let the generic image thumbnailer handle jpeg as well.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D13315

To: miklosm, #frameworks, dfaure, broulik
Cc: broulik, ngraham, apol, kde-frameworks-devel, michaelh, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180918/222e8143/attachment.html>