Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 80349 - bugzilla fails with non-ascii characters in user names
Summary: bugzilla fails with non-ascii characters in user names
Alias: None
Product: Bugzilla
Classification: Community
Component: Bugzilla General
Version: 2.17
Hardware: All
OS: Linux
low vote
Target Milestone: ---
Assignee: David Lawrence
QA Contact: David Lawrence
: 80350 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2002-12-24 21:35 UTC by Pekka Pietikäinen
Modified: 2007-04-18 16:49 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-09-26 08:34:13 UTC

Attachments (Terms of Use)

Description Pekka Pietikäinen 2002-12-24 21:35:46 UTC
Description of problem:

Sometime during the bugzilla upgrade the ä (that is, \"a in TeX syntax in case
bugzilla messes it up) in my name got stripped of the highest bit (ending up
with a d). Fair enough, trying to get it right, I edited my preferences 
with mozilla and got:

Software error:

UPDATE profiles SET realname = 'PietikC$inen, Pekka' WHERE userid = 18:
ERROR:  Invalid UNICODE character sequence found (0xe4696e) at
line 328.

For help, please send mail to the webmaster (, giving
this error message and the time and date of the error.

Solution: replace it with an "a" that works just fine even everywhere even
though it makes my name not quite right ;)

This is probably related to #70443.

Comment 1 Pekka Pietikäinen 2002-12-24 21:40:05 UTC

It worked when I forced the character encoding to UTF-8 on the preferences page.

Comment 2 David Lawrence 2002-12-25 20:40:32 UTC
UTF-8 is what the data fields are using in the database. So maybe I should make 
a note reminding people to configure their browsers for UTF-8 before submitting 
any text containing double byte characters.

Comment 3 Pekka Pietikäinen 2002-12-25 22:01:21 UTC
Can't the server tell the client it should be sending utf-8? (hairy, I know, 
there seems to be a longish paper about UTF-8 as form input around, every browser
works differently etc.)

Comment 4 Aleksey Nogin 2003-01-05 07:12:44 UTC
*** Bug 80350 has been marked as a duplicate of this bug. ***

Comment 5 David Lawrence 2003-01-06 00:53:33 UTC
Does this still fail now that I have altered the META tags to request UTF-8 from
the browsers?

Comment 6 Bernd Bartmann 2003-01-06 09:30:49 UTC
Let me test:

Comment 7 Pekka Pietikäinen 2003-01-06 10:43:32 UTC
Seems to work ok. Well, the emails it sends don't have the mime headers
for telling mail readers the content is utf-8, so they don't know what
to do with the mails either. Technically it should work with

Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

Not sure how mail readers react when they see that, apparently not all react
well, so maybe not worth fixing.

Comment 8 Pekka Pietikäinen 2003-09-26 08:34:13 UTC
Just clearing out old bugs, and it appears bugzilla now uses:

Content-type: text/plain; charset=utf-8 
so even that is now fine.

Note You need to log in before you can comment on or make changes to this bug.