New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add preferred extensions for MIME types #40993
Comments
Instead of returning the first in the list of |
Logged In: YES How would you suggest finding out what the most reasonable |
Logged In: YES in mimetypes.py there is already a common_types = {
'.jpg' : 'image/jpg',
... .txt could be added, background: my intent was to save MIME attachment as |
Logged In: YES common_types is for adding some non-standard types, not for |
Logged In: YES While I agree with the original poster that returning '.txt' Is using a custom comparison function along with the list |
Confirmed on trunk. |
I'll close this in a couple of weeks unless someone wants it kept open. |
I think you are closing too aggressively. Python 3.2a0 (py3k:81783, Jun 6 2010, 16:07:26)
[GCC 4.1.3 20080623 (prerelease) (Ubuntu 4.1.2-23ubuntu3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import mimetypes
>>> mimetypes.guess_extension('text/plain')
'.ksh'
>>> |
While I agree that getting .ksh is an unfortunate guess, I am not sure how you can guess in the face of many options (especially when the those options are parsed out of a mimetypes file or the windows registry). Perhaps there should be a "resonable_defaults" map that is checked first for very basic types where there are multiple extensions for a type? |
6 years old and still not fixed? http://www.stdicon.com/mimetype/text/plain Please return txt |
ksh is a text/plain to, all this extension are text/plain: I hope helped |
Rafael, There is already a method which returns all the extensions. What is required is a flag (or separate dict) which provides a canonical extension. The questions is whether it is sufficient to rely on the default provided mimetypes for the default in the face of mimetypes read out of the mimetypes files or windows registry. I don't see a way to fix the bug, without also providing an API to "pick the winner" for those cases that are not provided in the default list. |
The proposed patch does not solve the issue. In the current API, there is no way to do it, so this bug requires a new feature. I think it would involve a new dict, like preferred_extensions, which would be seeded with default values, like .jpg for image/jpeg and .txt for text/plain, and a few functions/methods to query the dict or add items. |
I'm running into a similar issue with this function. My bug is that get_type('foo.png') returns image/x-png. This occurs on windows because there are mappings to both image/png and image/x-png in the registry (as there should be, since that key is actually a reverse mapping) and the code simply picks the first key that it enumerates over. This issue strikes in both directions. Chris and others bring up a valid issue: how to decide what the winning result is? I think the answer is pretty clear - you use the common_types mapping already in the file and expand it as appropriate. If the mimetype can't be found, only then do you go to the windows registry. The behavior on Linux is even stranger to me (now we'll dig through an arbitrary list of files that might contain MIME info or may have completely irrelevant data) but it's a pragmatic solution. If someone needs to customize what guess_type returns, they can simply wrap the guess_type function in their own code or monkey patch if they don't have access to the source they're running. Changing such a mime type is a really advanced and unusual operation. If that's unacceptable, the code can provide a hook for an 'apache MIME config' file on windows in a standard place (either pythonpath, or %system% or wherever) that it will check before going to common_types or to the registry. Making this change doesn't require changing the API at all, just the implementation changes. |
I don't think it is unreasonable to return a well-known extension for certain mime types, text/plain being the most obvious (and most in need of repair; .ksh??). I've attached a patch based on the previous discussion. |
Here is a related question on SO: http://stackoverflow.com/questions/352837/how-to-add-file-extensions-based-on-file-type-on-linux-unix |
Anyone interested in picking this up, or at least commenting on the approach I suggested in the patch? Seems like an easy fix for a long-standing bug. |
See also <https://bugs.python.org/issue6626#msg91205\>, which mentions using a list of tuples instead of a dictionary, which sounds like it might help with this issue. Doing it that way you might be able avoid some duplication in the lists. |
Confirming that I've also bumped into this for Python 3.5. A docs update would seem to be the lowest-cost option to start with. Right now |
I think this has been fixed in Python 3.7+ via #14375 - at least for a couple of types. Comparing Python 3.6 with the current state, the following changed (which can be used as an "override" dict before calling mimetypes.guess_extension):
|
PR14375 indeed adds a test for this as well (test_preferred_extension). |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: