Pourquoi WordPress a choisi la sérialisation des données plutôt que json_encode?

Dans mon petit âge avec WordPress, j'ai vu WordPress lui-même et ses plugins conviviaux utilisent PHP serialize()pour stocker des données dans db dans de nombreux cas. Mais lors d'une récente recherche, j'ai trouvé un soutien communautaire sérieux pour les json_encode()plus de serialize().

• Un test qui prouve json_encode()est meilleur que serialize()- StackOverflow
• Pourquoi json_encode()utiliser et pourquoi pas - StackOverflow

Et j'ai personnellement testé un tableau associatif avec les deux, qui montre:

• serialize() stocke 342 caractères
• json_encode() stocke 285 caractères

Pourquoi je demande ça?

Je suis sur un projet pendant que je vais stocker des champs méta répétés dans un message. Où:

• Les données seraient essentiellement en anglais, mais peuvent parfois être en bengali
• Les données seraient un tableau associatif, 3 niveaux de profondeur (j'espère avoir bien compris les niveaux ):

array(
    1 => array(
        'key'=>'value',
        'key2'=>'value'
    ),
    2 => array(
        'key'=>'value',
        'key2'=>'value'
    )
)

J'ai vérifié le champ de la postmetatable, meta_valuec'est un longtext, ce qui signifie une longueur de 4 294 967 295 caractères (4 Go).

J'ai donc besoin d'une solution robuste pour stocker les choses.

Je pense, pas sûr à 100% que c'était la vraie raison pour laquelle les développeurs WP ont adopté cette approche, mais le bon sens me dit que la sérialisation préserve les types de variables et a une mini détection d'erreur intégrée, et json stocke uniquement les valeurs de chaîne { key : value }, donc quand vous revenir à PHP, vous devrez deviner le format, ou faire un analyseur pour cela. Cela vous obligera à avoir deux façons différentes de gérer vos données: précédente, pour stocker les données en json et après décodage du json, il reviendra comme un objet totalement différent.

C'est la principale raison de la différence de taille, PHP ne stocke pas seulement un tableau; il stocke le nombre d'éléments dans le tableau lors de sa sérialisation, leurs types et leurs valeurs.

Vous ne stockez pas uniquement des paires de valeurs clés dans la base de données, mais vous pouvez également stocker un objet avec différents types de variables.

L'encodage JSON a été introduit en PHP 5.2, WordPress est bien plus ancien, et il est né (et conçu pour) PHP 4.

La sérialisation des données est une chose omniprésente dans WordPress, donc passer de la sérialisation PHP au codage JSON signifierait un énorme problème de compatibilité descendante, et si je connais un peu WordPress, cela ne se produira jamais.

Cela dit, si vous pensez que l'encodage JSON est meilleur pour vous que la sérialisation PHP, utilisez-le.

Si vous passez une chaîne (c'est-à-dire la version codée JSON de vos données) pour publier des méta-fonctions, WordPress ne la touchera pas, mais alors vous devez vous rappeler de décoder les données JSON lors de la récupération.

Si la taille du stockage de base de données est très importante pour vous, cela vaut probablement la peine de faire du travail supplémentaire, sinon laissez simplement WordPress utiliser ce qu'il utilise et ne vous en souciez pas.

Vous pouvez peut-être évaluer si c'est le cas des tables personnalisées pour enregistrer vos données.

Je suis tenté de clore cela comme "sujet à avis" mais je pense qu'il y a quelques bonnes réponses à la question. Je vais aller avec "l'histoire".

1) json_encodeest relativement nouveau dans le noyau PHP.

json_encode

(PHP 5> = 5.2.0, PECL json> = 1.2.0) json_encode - Retourne la représentation JSON d'une valeur

http://php.net/manual/en/function.json-encode.php

json_encoden'aurait pas été fiable au début de WordPress. Il a seulement été intégré au PHP "core" en 5.2, bien qu'il soit disponible en tant qu'extension PECL bien avant.

Deuxièmement, si vous introduisez un objet tel qu'un WP_Queryobjet, json_encodevous obtenez un stdClassobjet json_decode. serialize/ unserializepréservera l'objet.