id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
6784	options with content in strange languages do not deserialize properly	Olav Kolbu	anonymous	"Put this in a php-page that has access to the get_option()/update_option() fns and load page TWICE.

$test = get_option('my_test');
if ( is_bool($test) ) {
   print ""1st time<br>"";
   $test = array();
   $test[] = 'ي';
   update_option('my_test', $test);
   print 'Arabic : '.gettype(get_option('my_test')).'<br>';
} else {
   print ""2nd time<br>"";
   print ""got a "".gettype($test)."" which looks like '$test'"";
}

Note that the content of the string on line 5 is an arabic character. If you're having troubles regenerating it, print & # 1610 ; (without spaces...) on a webpage and cut'n'paste it from there. I have also attached it to this bug report, I hope. 

First time the page loads, the output is:

1st time
Arabic : array

Which is what you would expect. Note specifically that the array tested is the one that is stored and then fetched again, not the original array.

Now reload page and you get:

2nd time
got a string which looks like 'a:1:{i:0;s:2:""?"";}'

So the backend didn't deserialize the array this time around. Now, I can work around this feature/bug in my own plugin-code by never storing strings with strange characters, but this also bites me when I use the MagpieRSS caching features, as the feed stored may contain strange characters and I can't control the content of those.
"	defect (bug)	closed	normal	2.8	General	2.5	normal	fixed	deserialize, get_option, character sets