I've recently upgraded my project environment to django 1.6. After the upgrade, I found out that all the static files in the existing projects do not work anymore, even if I create a new project following the tutorial, the static file still does not work. Can any one help me out?

Here is my project structure

    -mysite
        manage.py
        -mysite
            urls.py
            views.py
            settings.py
            __init__.py
            wsgi.py
            -static
                jqury.js

settings.py looks like this

    INSTALLED_APPS = (
        ...
        'django.contrib.staticfiles',
    )

    TEMPLATE_DIRS = (
        os.path.join(BASE_DIR, 'WorldCup\\templates'),
    )

    TEMPLATE_CONTEXT_PROCESSORS = [
        'django.core.context_processors.static',
        'django.contrib.auth.context_processors.auth',
    ]

    STATIC_URL = '/static/'

    STATICFILES_DIRS = (
        os.path.join(BASE_DIR, 'WorldCup\\static'),
    )

    print STATICFILES_DIRS

    STATICFILES_FINDERS = (
        'django.contrib.staticfiles.finders.FileSystemFinder',
        'django.contrib.staticfiles.finders.AppDirectoriesFinder',
        #'django.contrib.staticfiles.finders.DefaultStorageFinder',
    )

I print the staticfiles_dirs, the result is ('G:\django_project\mysite\mysite\static',), which correctly points to my static file folder.

The html file looks like:

    {% load staticfiles %}
    <script type="text/javascript" src="{% static "WorldCup/jquery-1.10.2.js" %}" 

    <body>
        hello world======{% static "WorldCup/jquery-1.10.2.js" %}=======
    </body>

the page displays "hello world======/static/jquery-1.10.2.js=======", which seems correct.

But the Console complained with:

    Traceback (most recent call last):
    File "D:\Python27\lib\wsgiref\handlers.py", line 85, in run
       self.result = application(self.environ, self.start_response)
    File "D:\Python27\lib\site-packages\django\contrib\staticfiles\handlers.py", l
       ine 68, in __call__
    return super(StaticFilesHandler, self).__call__(environ, start_response)
    File "D:\Python27\lib\site-packages\django\core\handlers\wsgi.py", line 206, i
       n __call__
    response = self.get_response(request)
    File "D:\Python27\lib\site-packages\django\contrib\staticfiles\handlers.py", l
       ine 58, in get_response
    return self.serve(request)
    File "D:\Python27\lib\site-packages\django\contrib\staticfiles\handlers.py", l
       ine 51, in serve
    return serve(request, self.file_path(request.path), insecure=True)
    File "D:\Python27\lib\site-packages\django\contrib\staticfiles\views.py", line
       41, in serve
    return static.serve(request, path, document_root=document_root, **kwargs)
    File "D:\Python27\lib\site-packages\django\views\static.py", line 61, in serve

    content_type, encoding = mimetypes.guess_type(fullpath)
    File "D:\Python27\lib\mimetypes.py", line 297, in guess_type
       init()
    File "D:\Python27\lib\mimetypes.py", line 358, in init
       db.read_windows_registry()
    File "D:\Python27\lib\mimetypes.py", line 258, in read_windows_registry
       for subkeyname in enum_types(hkcr):
    File "D:\Python27\lib\mimetypes.py", line 249, in enum_types
       ctype = ctype.encode(default_encoding) # omit in 3.x!
    UnicodeDecodeError: 'ascii' codec can't decode byte 0xb9 in position 0: ordinal
       not in range(128)
    [01/Dec/2013 07:42:33] "GET /static/jquery-1.10.2.js HTTP/1.1" 500 59

Even if I change to the image file instead of js file, I still get those errors....

有帮助吗?

解决方案

My best guess based on your error message is that you have non-ASCII characters in your Windows registry, and something in the mimetypes module (part of the Python standard library) is choking on that. I assume either the Django statics server, or the Django staticfiles app itself, is calling mimetypes.

This is not a problem with your system per se; if I'm correct in my diagnosis it's clearly a bug in mimetypes.

Here are some options:

  • You could upgrade to Python 3.3 or 3.4 beta. Django 1.6 is fully compatible with Python 3 and I would be very surprised to see that this bug still exists in Py3 because one of the explicit goals of Py3 was to make unicode encode/decode errors less common.

  • You could downgrade back to Django 1.5.

  • You could use a different operating system for development work. Relatively few Python programmers do their dev work in Windows, although the number is not zero either. You are less likely to run into extremely obscure bugs if you use OS X or Linux for development work. That having been said, Windows is an officially supported platform, so if there is a problem with the interaction between CPython and Windows, then that is a CPython bug.

  • You could try to find exactly what change between 1.5 and 1.6 caused this problem, but that is likely a fool's errand and, assuming it's not an outright bug in Django, will at best result in you having to maintain a fork with your patch for your personal use (not recommended).

  • You could try to find the offending line in your registry and scrub it, but I don't know how you would go about doing this. You may have a combination of locale settings, the localized version of Windows, non-English installed software or custom MIME types that is causing this problem. Since it seems likely that it is a bug in the mimetypes library and not the fault of your system, you could easily find that the problems in your registry are simply a consequence of some normal function of your computer.

  • If the problem is with the Django statics server in a way that wouldn't affect your application in production (where the Django statics server, which is only suitable for development, would presumably be disabled) then you could disable the Django statics server and use some other statics serving solution for development. This is inconvenient but would probably work, as long as the problem is with the Django statics server only. To test, set DEBUG to False or otherwise turn off the statics server and run your application -- if it still crashes, then it's not a Django statics server issue; otherwise, it likely is.

  • Finally, you could try to track down the actual bug and fix it. This is a complex process -- you would need to isolate the bug, see whether it needs to be fixed in the CPython standard library or in Django (I suspect the former), file a report with either of those projects, then write a patch and submit it or get someone else to do likewise. Until it is submitted and accepted, you could theoretically maintain a fork of CPython with the fix applied, but that is a maintenance nightmare.

There is still the possibility that I am outright wrong about the cause and it's not a bug in mimetypes -- in that case you might have more options.

其他提示

very unfortunetly I have this problem as well. I was using python 3.3, everything works fine. But since my production side is running python 2.7, so I created an a virtualenv with python 2.7.6, and then installed South, debug toolbar, which is the same as my Python3.3 environment. But it just simply not work with python2.7 virtualenv. My Django version is 1.6. So my simple way around this is to switch back to my python3.3.

For more details, my guess would be something related models/database goes wrong. I recall that after a database migration in my virtualenv python2.7 version, this problem appears, while before that everything goes well.

So I would suggest you to run a virtualenv with Python3.3, and debug for the old problem whenever you have more time. Anyway, to save time first. I find Django is really a nice framework, but Python with its multiple packages just have too much buggy stuff that you just do not want to waste your time to go over every one of them.

I have same problem. Today I have access only to machine, with windows XP. I've debugged this error and found, that key in windows registry has bad value. In my case it was: 'BDATuner.���������'. I hadn't enouth time to edit registry so I temporary add exception to File "D:\Python27\lib\mimetypes.py", line 249, in enum_types

            try:
                ctype = ctype.encode(default_encoding) # omit in 3.x!
            except UnicodeEncodeError, UnicodeDecodeError:
                pass
            else:
                yield ctype

I solved my problems.

I know that patching django code that way is bad, so it's only workaround. The correct way is to get rid of bad registry values (regedit - next search for this values).

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top