Bug #26568 forge doesn't support unicode/highbit characters like ø
Submitted: 22 Feb 2007 13:34 Modified: 21 Feb 2014 19:12
Reporter: Ask Bjørn Hansen (Basic Quality Contributor) Email Updates:
Status: Unsupported Impact on me:
None 
Category:MySQL Websites: MySQLForge Severity:S3 (Non-critical)
Version: OS:Any
Assigned to: Assigned Account CPU Architecture:Any
Tags: qc

[22 Feb 2007 13: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 16: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 16:43] Sveta Smirnova
See for example snippet at http://forge.mysql.com/snippets/view.php?id=61
[22 Feb 2007 16: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 16: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 18:18] Lenz Grimmer
Confirmed, the emails are garbled. Sorry about that, we're looking into it.
[22 Feb 2007 18: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 18: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 0: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
[21 Feb 2014 19:12] Sveta Smirnova
MySQL Forge has been discontinued.