Hello, Are you using MySQL and what is the collation of your database. I am running 1.2.1 and encountering similar problems.
My issue involves utf8_bin collation on mysql 5.1.41-3ubuntu12.3. The issue is thus: I create a model with an ImageField and save a new instance to my utf8_bin collated mysql backend. This instance has a file associated with non-ascii characters in it, e.g. "Sinéad_OConnor.jpg". Next I attempt delete the file (via the admin) and I get a: 'ascii' codec can't decode byte 0xc3 in position 18: ordinal not in range(128) FYI, MySQLdb does not return unicode strings with a utf8_bin collation set. for a brief description of that issue see: http://code.djangoproject.com/ticket/8340#comment:4 The traceback from my exception reveals the exception being thrown in "django/db/models/fields/files.py" in get_prep_value (line 248). FileField is a subclass of Field, but implements the same backend MySQL type (varchar) as a CharField. However it seems that FileField and CharField have completely different implementations of get_prep_db. Here is CharField's implementation: def to_python(self, value): if isinstance(value, basestring) or value is None: return value return smart_unicode(value) def get_prep_value(self, value): return self.to_python(value) Here is Filefield's: def get_prep_value(self, value): "Returns field's value prepared for saving into a database." # Need to convert File objects provided via a form to unicode for database insertion if value is None: return None return unicode(value) My experimentations revealed that if I replace the FileField implementation of get_prep_value with the CharField, the exception goes away. The issue is that the default encoding is ascii and so unicode() called on a utf8 byte str blows up. The CharField implementation simply checks if the value is an instance of basestring and just passes it through. This latter approach seems better to me. As it stands, I'm inclined to think this issue is a bug. Thanks much, -Sam On Jun 13, 6:22 pm, Karen Tracey <kmtra...@gmail.com> wrote: > On Sun, Jun 13, 2010 at 6:18 PM, MichaleHjulskov <needb...@gmail.com> wrote: > > Hi Karen, I did not know there was a new release, sorry. > > > So if I just install the new release, it will solve the problem just > > like that? > > Or do I still need to do something, in order to make it work with > > special chars in the filenames? > > No, with the current release you still need to ensure your environment is > set properly to allow Django to pass unicode to file system functions. The > behavior I am guessing you are seeing (absent the full traceback to be sure) > is not a bug in Django, it's an error in your environment setup. I pointed > to the place in the doc where this is mentioned, and where some details of > properly setting things up for Apache is covered, in the first paragraph of > my first response. > > I just mentioned upgrading from the alpha level of code because there are > plenty of bugs that were fixed between alpha and release, and your life will > likely be easier if you use release level code instead of alpha. > > Karen -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
