Joel Natividad Reporter
	Description • 19 years ago

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7

Working with some guys in Sweden, named Åke and Östenberg.

In 2.18.3, their real names were displayed properly.  After the cvs upgrade to
2.20 and running checksetup.pl, it became ?ke and ?stenberg.

Running on Debian 3.1 stable, Apache 1.3.33, MySQL 4.0.24, Perl 5.8.4,
DBD::mysql 2.9006

Reproducible: Always

	Joel Natividad Reporter
	Comment 1 • 19 years ago

Yikes, even while entering the names here, it got mangled.

It is Ake and Ostenberg with the Swedish equivalents. Check out
http://www.wiscocomputing.com/language/swedish.htm

	:glob ✱
	Comment 2 • 19 years ago

have you enabled the utf-8 parameter?

	Joel Natividad Reporter
	Comment 3 • 19 years ago

Byron,
If you're referring to the change in CGI.pm
(http://www.bugzilla.org/docs/tip/html/security-bugzilla.html), I did that after
the upgrade.  

And once I changed the Real Name to the proper characters, they are now visible
again in 2.20.

What perplexes me is that how come they were displayed properly in 2.18.3? 
Could it be someting that checksetup.pl is doing after a CVS upgrade?

	:glob ✱
	Comment 4 • 19 years ago

> If you're referring to the change in CGI.pm
> (http://www.bugzilla.org/docs/tip/html/security-bugzilla.html)

no, i was refering to the utf8 parameter.  i wasn't aware of that page, however
 the end result is the same.

> I did that after the upgrade.  
>
> And once I changed the Real Name to the proper characters, they are now
> visible again in 2.20.

the encoding of non 7-bit characters would have been different -- the existing
data would have been saved using a different encoding than utf8.  setting the
charset or the utf8 paramter won't convert encoded data to utf8 automatically.

bug 280633 is tracking migration of existing data.

	Marc Schumann [:Wurblzap]
	Comment 5 • 19 years ago

The utf8 parameter doesn't exist in 2.20 yet (see bug 126266).

As you're saying you applied the http://www.bugzilla.org/docs/tip/html/security-bugzilla.html patch *after* the upgrade, I suspect that what went into 2.18.3 was probably something non-UTF-8 (ISO-8859-1 or cp1252 or something), which cannot be displayed now that you're enforcing UTF-8.

Unless you think that there is something else behind this, please mark this bug as a duplicate of either bug 126266 or bug 280633.

	Joel Natividad Reporter
	Comment 6 • 19 years ago

*** This bug has been marked as a duplicate of 280633 ***