Bugzilla – Bug 16830
CLI returns double-encoded UTF-8 for metadata when locale not using UTF-8 encoding
Last modified: 2011-05-12 15:05:07 UTC
See referenced forum thread. Problem appears to be Windows specific. Current as of 7.6 r31813
== Auto-comment from SVN commit #31847 to the slim repo by ayoung == == http://svn.slimdevices.com/slim?view=revision&revision=31847 == Fixed bug 16830: CLI returns double-encoded UTF-8 for metadata when local not using UTF-8 encoding Fixes for the original problem: Fix encoding of simple values in Slim::Control::Request::renderAsArray(). All input to renderAsArray() should already be in perl internal character-string format, so just use Slim::Utils::Unicode::utf8encode() instead of Slim::Utils::Unicode::from_to(). Fixes to ensure that the CLI charset param (continues to ?) work with the changes above. Slim::Control::Stdio::array_to_string() needs to allow output character-set encodings other than just UTF-8. The current locale has nothing to do with encoding CLI results. Fixes to related issues discovered as part of the investigation: Slim::Utils::Unicode::encodingFromString() will return 'utf8' immediately if the flag is already set on the supplied string, unless this test is defeated by a parameter. This will avoid the problem of double-encoding when the encoding is already known. utf8::decode() is not idempotent so protect against this in a few places.
Verified fixed in 7.6.0, 32398