Hide Forgot
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.
Ha! 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 the browsers?
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 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.
Just clearing out old bugs, and it appears bugzilla now uses: Content-type: text/plain; charset=utf-8 so even that is now fine.