I am using a plugin the updates the option table using update_option command. When I update content with hebrew characters it turns into gibrish. My database does support hebrew (or any other utf8 chars). Is there any workaround?

Thank you!

link|improve this question
feedback

3 Answers

up vote 4 down vote accepted

Chances is are that the content-type/charset header is not being sent, and that you end up reading the utf8 chars as if they were latin-1.

Also, note that serialize()/unserialize() are not multibyte character-safe. For a subset of characters, the string's length as returned by serialize() will occasionally differ from the expected length as it would be returned by mb_strlen(). This leads to all sorts of hard to debug unserialize problems which, since around WP 2.8, WP tries to discard in order to avoid crashing sites.

link|improve this answer
I think this changed. From my recent tests, serialized strings are headed with the binary length of the string. So serialized/unserialize on it's own should be compatible with any charset encoding as it is to be binary safe. If I miss something here, please let me know. – hakre Nov 17 '10 at 16:22
feedback

As far as I know WordPress is perfectly UTF8-aware.

This test code (hope I got string right, copied from Wikipedia) works fine for me:

$hebrew = 'עִבְרִית';
update_option('hebrew',$hebrew);
var_dump(get_option('hebrew'));

Your issue is likely caused by some other processing done on string by plugin.

link|improve this answer
2  
That one will work fine indeed, because it's not serialized. If you try to store things like array('עִבְרִית'), it usually works; but not always. See WP tickets #6532 and #9549. – Denis Nov 5 '10 at 11:46
feedback

Convert your file encoding into UTF-8 without BOM.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown

Not the answer you're looking for? Browse other questions tagged or ask your own question.