Why does WordPress use serialize rather than json_encode for the options table? [duplicate]

I have a basic understanding of serialize (I come across it often when I’m migrating WordPress installs) and I just discovered json_encode.

Given that serialize causes so much trouble with replacing strings in the database (eg. editing an optinos field directly), why does WordPress prefer serialize to (the
seemingly similar) json_encode, which doesn’t insert the string length into the stored value.

My first thought was that it may provide some security or error-checking benefits – WordPress will ignore the option if the string lengths are incorrect.. but I’m interested in a qualified explanation 🙂

• serialize representation can be stored in text and reversed
• JSON representation can be stored in text but cannot always be precisely reversed

Run this example:

$query = new WP_Query();
var_dump( $query );
var_dump( unserialize( serialize( $query ) ) );
var_dump( json_decode( json_encode( $query ) ) );

• After going through serialize accurate WP_Query object is re-created.
• After going through JSON you get stdClass object.

In a nutshell serialize is native part of PHP and has a lot of synergy with manipulating data in it. JSON is language-agnostic format that is convenient for systems talking to each other, but far from comprehensive and cannot do things in PHP which serialize does without second thought.