Red Hat Bugzilla – Bug 80349
bugzilla fails with non-ascii characters in user names
Last modified: 2007-04-18 12:49:16 EDT
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:
UPDATE profiles SET realname = 'PietikC$inen, Pekka' WHERE userid = 18:
ERROR: Invalid UNICODE character sequence found (0xe4696e) at globals.pl
For help, please send mail to the webmaster (firstname.lastname@example.org), 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.
It worked when I forced the character encoding to UTF-8 on the preferences page.
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.
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.)
*** Bug 80350 has been marked as a duplicate of this bug. ***
Does this still fail now that I have altered the META tags to request UTF-8 from
Let me test:
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
Content-Type: text/plain; charset=utf-8
Not sure how mail readers react when they see that, apparently not all react
well, so maybe not worth fixing.
Just clearing out old bugs, and it appears bugzilla now uses:
Content-type: text/plain; charset=utf-8
so even that is now fine.