Bugzilla – Bug 2532
Unicode entered in input boxes in the web interface is mangled
Last modified: 2008-09-15 14:38:10 UTC
When I enter some non-latin character in an input field of the setup pages (eg. player name) it gets crippled. I'm rather sure it's an utf8 character not correctly recognized as such. As it's similar behaviour to the faulty StringEditor version, might the values simply miss being Slim::Utils::Unicode::utf8decode_guess()ed?
Should have mentioned that the problem exists in 6.2.1, too. And on Linux server as well.
Michael - do you have a patch for this?
I'm sorry, I did not have the time yet. And I hoped whoever did the GET->POST change would exactly know what to do...
Does changing line 407 of Slim/Web/HTTP.pm from Slim::Utils::Unicode::utf8decode to Slim::Utils::Unicode::utf8decode_guess fix the issue?
No, it does not. utf8decode_guess() doesn't change the strings representation when printed to the logs.
Well, the string represenation in the log may not be correct.. what about the actual value that is written?
The value seems to be correctly written to slimserver.pref, but not represented in the web interface.
While the following patch will correctly display the entered value in the setup pages, the value does not seem to be stored in the expected way: Index: D:/eclipse/svn/Slim/Web/HTTP.pm =================================================================== --- D:/eclipse/svn/Slim/Web/HTTP.pm (revision 5516) +++ D:/eclipse/svn/Slim/Web/HTTP.pm (working copy) @@ -368,7 +368,11 @@ # string with the appropriate magic set. if ($value ne '*' && $value ne '') { - $value = Slim::Utils::Unicode::utf8decode($value); + if ($] > 5.007) { + $value = Slim::Utils::Unicode::utf8decode($value, 'utf8'); + } else { + $value = Slim::Utils::Unicode::utf8toLatin1($value); + } } $params->{$name} = $value; This is ok in setup.html - but eg. a player's name will still be displayed in the main menu as if it was stored unencoded. Where else would we need to tweak the setup pages?
Created attachment 1092 [details] Allow high bit characters in player names etc. Dan, I think change 3936 is the culprit for my problem (http://svn.slimdevices.com/?rev=3936&view=rev). With this patch (which undoes 3936) I can use high bit characters for eg. player names. But the paths are broken. What can we do?
Oops... let me add that slimserver won't accept "d:\�" even without my patch. It therefore does not seem to break anything that's not already broken. Comments?
Change the summary after discussion in the forum: http://forums.slimdevices.com/showthread.php?t=19989
As this issue is affecting searches from the web interface ("Ang�lique" isn't found) and others, too, I'm increasing severity.
Change 5919 should fix this.
Thanks a LOT! Playername "B�rnerb�r" as well as the path "d:\M�sig" or the search for "Ang�lique" are working for me. Tested on 6.2.x only, though, as the trunk is broken on Windows (http://forums.slimdevices.com/showthread.php?t=20524)
Ok, confirmed for trunk as well. Thanks!
Search with unicode has never worked with me; I'm kind of surprised to find this bug long fixed. Or maybe I'm talking about a different bug? SlimServer Version: 6.5.5 - 15454 - Windows Server 2003 - EN - cp1251 Server IP address: 192.168.11.6 Perl Version: 5.8.8 MSWin32-x86-multi-thread MySQL Version: 5.0.22-community-nt