Bug 80349 - bugzilla fails with non-ascii characters in user names
Summary: bugzilla fails with non-ascii characters in user names
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Bugzilla
Classification: Community
Component: Bugzilla General   
(Show other bugs)
Version: 2.17
Hardware: All Linux
medium
low vote
Target Milestone: ---
Assignee: David Lawrence
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords:
: 80350 (view as bug list)
Depends On:
Blocks:
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:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-09-26 08:34:13 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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 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 21:40:05 UTC
Ha!

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.