Bug 80349 - bugzilla fails with non-ascii characters in user names
bugzilla fails with non-ascii characters in user names
Status: CLOSED CURRENTRELEASE
Product: Bugzilla
Classification: Community
Component: Bugzilla General (Show other bugs)
2.17
All Linux
medium Severity low (vote)
: ---
: ---
Assigned To: David Lawrence
David Lawrence
:
: 80350 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-12-24 16:35 EST by Pekka Pietikäinen
Modified: 2007-04-18 12:49 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-09-26 04:34:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Pekka Pietikäinen 2002-12-24 16:35:46 EST
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 globals.pl
line 328.

For help, please send mail to the webmaster (bugzilla@redhat.com), 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 16:40:05 EST
Ha!

It worked when I forced the character encoding to UTF-8 on the preferences page.
Comment 2 David Lawrence 2002-12-25 15:40:32 EST
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 17:01:21 EST
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 02:12:44 EST
*** Bug 80350 has been marked as a duplicate of this bug. ***
Comment 5 David Lawrence 2003-01-05 19:53:33 EST
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 04:30:49 EST
Let me test:
äöüß
ÄÖÜ
Comment 7 Pekka Pietikäinen 2003-01-06 05:43:32 EST
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 04:34:13 EDT
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.