Bug #26568 forge doesn't support unicode/highbit characters like ø

• Submitted: 22 Feb 2007 14:34
• Modified: 23 Feb 2007 1:06
• Reporter: Ask Bjørn Hansen (Basic Quality Contributor)
• Status: Analyzing
• Category: MySQLForge
• Severity: S3 (Non-critical)
• OS: Any
• Assigned to: Bugs System
• Tags: qc

[22 Feb 2007 14:34] Ask Bjørn Hansen

Description:
On forge.mysql.com my name shows up as "Ask Bj�rn Hansen."

In the CLA email confirmation my name was written as  "Ask Bjørn Hansen" which is the
typical sending utf-8 but claiming it is iso-8859-1 mistake.

How to repeat:
Change your name in your mysql account to include æøå and watch it not work on the
forge site.

[22 Feb 2007 17:38] Sveta Smirnova

Thank you for the report.

I can not repeat it. Which language did you set up in your profile?

[22 Feb 2007 17:43] Sveta Smirnova

See for example snippet at http://forge.mysql.com/snippets/view.php?id=61

[22 Feb 2007 17:48] Ask Bjørn Hansen

Hi,

In my profile - http://www.mysql.com/profile/ - I set my last name to "Bjørn Hansen". 
On bugs.mysql.com for example it's working fine (as you can see).

I will attach a screenshot of how it displays on the forge site.

[22 Feb 2007 17:52] Ask Bjørn Hansen

mysql forge screenshot (Safari on OS X 10.4.8).

Attachment: Picture 28.png (image/png, text), 55.18 KiB.

[22 Feb 2007 19:18] Lenz Grimmer

Confirmed, the emails are garbled. Sorry about that, we're looking into it.

[22 Feb 2007 19:32] Lenz Grimmer

Commited a fix to change the phpmailer to use UTF-8 instead of the default iso-8859-1
charset. Now trying to reproduce/analyze the screen name problem.

[22 Feb 2007 19:53] Jay Pipes

Hi!

The issue is that the cookie (which holds the user's display name for a caching
mechanism) is written in ASCII and therefore cuts out the high byte.  See the following:

jpipes@shakedown:/var/www/apache2-default/web-forge/work/lib$ grep "USER_DISPLAY_NAME" *
-n1
load.template.engine.php-24-    }
load.template.engine.php:25:    $GLOBALS['TEngine']->Assign("USER_DISPLAY_NAME",
$GLOBALS['WebSession']->Get('display_name'));
load.template.engine.php-26-}

The WebSession->Get() method simply reads in the cookie content, which is loaded in the
constructor:

:    function CookieSession() {
25-        include_once(DIR_LIB . 'functions.crypt.php');
26-        if (func_num_args() > 0) {
27-            // Rename based on supplied name
28-            $this->_cookie_name = func_get_arg(0);
29-            if (func_num_args() > 1) {
30-                $this->_expiration_seconds = func_get_arg(1);
31-            }
32-        }
33-        if (isset($_COOKIE[$this->_cookie_name])) {
34-            $this->_Variables = unserialize(decrypt($_COOKIE[$this->_cookie_name]));
35-        }
36-    }

Unfortunately, either the writing of the cookie, or possibly the decrypt/encrypt
functions (which use mcrypt_ ...) are stripping the high bytes.

This problem won't be fixed anytime soon... just due to resource issues in the community
team :(

Cheers,

Jay

[23 Feb 2007 1:06] Ask Bjørn Hansen

"This problem won't be fixed anytime soon... just due to resource issues in the
community team :("

Hi Jay,

That's fine - I just noticed it and wanted to make sure you knew about it.   Having a
MySQL site not deal well with character encodings could easily make someone falsely
believe that mysql (the software) doesn't either.  :-)

 - ask