Opened 7 years ago

Closed 7 years ago

#12645 closed (wontfix)

UnicodeEncodeError when validating forms with non-ascii field names

Reported by: Alan Justino da Silva Owned by: unbracketed
Component: Forms Version: 1.1
Severity: Keywords: unicode
Cc: alan.justino@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: UI/UX:

Description

I am creating forms dynamically, so users can type field names.

Django is raising UnicodeEncodeError when some field name has a non-ascii name. Is simple not acceptable to constrain users to ASCII only.

Baked example:

class UtilizacaoForm(forms.Form):
    pass

ut = UtilizacaoForm()
ut.fields[u'Diâmetro'] = forms.CharField(max_length=3)

ut.is_valid()
File "django/forms/forms.py" in is_valid
  120.         return self.is_bound and not bool(self.errors)
File "django/forms/forms.py" in _get_errors
  111.             self.full_clean()
File "django/forms/forms.py" in full_clean
  242.                 if hasattr(self, 'clean_%s' % name):

Exception Type: UnicodeEncodeError at /novakoski/modelos/detalhe/1/
Exception Value: ('ascii', u'clean_Di\xe2metro', 8, 9, 'ordinal not in range(128)')

Occurs because hasattr(obj, str) can't handle non-ascii at str, before preparing to call clean_fieldname.

Bug found at 1.1.1 (r11612), but stays alive at actual TRUNK (r12264).

Original traceback paste: http://dpaste.com/hold/147583/

Quick fix added.

Attachments (1)

bugfix.diff (1002 bytes) - added by Alan Justino da Silva 7 years ago.
Bugfix - use a try-catch to workarround hasattr ASCII limitation

Download all attachments as: .zip

Change History (6)

Changed 7 years ago by Alan Justino da Silva

Attachment: bugfix.diff added

Bugfix - use a try-catch to workarround hasattr ASCII limitation

comment:1 Changed 7 years ago by Alan Justino da Silva

Summary: UnicodeEncodeError when validating forms with non-ascii namesUnicodeEncodeError when validating forms with non-ascii field names

comment:2 Changed 7 years ago by unbracketed

Owner: changed from nobody to unbracketed
Status: newassigned

comment:3 Changed 7 years ago by unbracketed

Patch needs improvement: set
Triage Stage: UnreviewedAccepted

Patch doesn't cover all cases. For example, printing a form created with the same conditions (dynamically added field with a non-ASCII name) will also generate an exception.

comment:4 Changed 7 years ago by Alan Justino da Silva

Replying to unbracketed:

Patch doesn't cover all cases. For example, printing a form created with the same conditions (dynamically added field with a non-ASCII name) will also generate an exception.

Isn't this because of console encoding issues?. My console is configured to UTF-8, as seen:

alanjds@lgpill:~$ locale
LANG=pt_BR.UTF-8        
LANGUAGE=pt_BR: pt: en_US: en
LC_CTYPE="pt_BR.UTF-8"
(...)
LC_ALL="pt_BR.UTF-8"

When locale config was set as LANG=C, printing from ipython or simple python console throws exceptions yet.

Could you post an example? I would like to try to reproduce this error.

comment:5 Changed 7 years ago by jkocherhans

milestone: 1.2
Resolution: wontfix
Status: assignedclosed

In general I agree that it's not acceptable, but that's partly a limitation of Python itself. You can't use non-ascii values for python variables, so you can't create model fields, or declaratively create form fields with non-ascii values. What you're doing here is essentially a hack to get around that fact. You can still change the label of the field to "Diâmetro" if you want.

Note: See TracTickets for help on using tickets.
Back to Top