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!

3 Answers 3


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.

  • 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
    Commented Nov 17, 2010 at 16:22

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 = 'עִבְרִית';

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

  • 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. Commented Nov 5, 2010 at 11:46

Convert your file encoding into UTF-8 without BOM.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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