Por que o WordPress escolhe a serialização de dados em vez de json_encode?

Na minha pouca idade com o WordPress, vi o próprio WordPress e seus plugins amigáveis ​​estão usando PHP serialize()para armazenar dados no db em muitos casos. Mas, em uma pesquisa recente, encontrei um sério apoio da comunidade para o mundo json_encode()todo serialize().

• Um teste que prova json_encode()ser melhor que serialize()- StackOverflow
• Razões pelas quais json_encode()pode ser usado e por que não - StackOverflow

E eu pessoalmente testei uma matriz associativa com os dois, que mostra:

• serialize() armazena 342 caracteres
• json_encode() armazena 285 caracteres

Por que estou perguntando isso?

Estou em um projeto enquanto vou armazenar meta-campos repetidos em uma postagem. Onde:

• Os dados seriam basicamente em inglês, mas às vezes podem ser bengalis
• Os dados seriam uma matriz associativa, com três níveis de profundidade (espero entender os níveis corretamente):

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

Eu verifiquei que o campo postmetada tabela é meta_valueum longtext, o que significa um comprimento de 4.294.967.295 caracteres (4 GB).

Então, preciso de uma solução robusta para armazenar coisas.

Eu acho que, não 100% de certeza que esta foi a verdadeira razão os desenvolvedores WP tomou esta abordagem, mas o senso comum me que preserva serializar os tipos de variáveis e têm um mini construído em detecção de erros e lojas JSON apenas valores de cadeia diz { key : value }, então quando você voltar ao PHP, você terá que adivinhar o formato ou fazer um analisador para ele. Isso forçará você a ter duas maneiras diferentes de manipular seus dados: anterior, para armazenar os dados como json e após decodificar o json, ele retornará como um objeto totalmente diferente.

Esta é a principal razão da diferença de tamanho, o PHP está armazenando não apenas uma matriz; está armazenando quantos elementos estavam na matriz quando ela foi serializada, seus tipos e valores.

Você não está armazenando apenas pares de valores-chave no banco de dados, mas também pode estar armazenando um objeto com diferentes tipos de variáveis.

A codificação JSON foi introduzida no PHP 5.2, o WordPress é muito mais antigo e nasceu (e projetado para) o PHP 4.

A serialização de dados é uma coisa difundida no WordPress, portanto, passar da serialização PHP para a codificação JSON significaria um enorme problema de compatibilidade com versões anteriores, e se eu conhecer um pouco o WordPress, isso nunca acontecerá.

Dito isto, se você acha que a codificação JSON é melhor para você do que a serialização PHP, basta usá-la.

Se você passar uma string (que é a versão codificada em JSON dos seus dados) para postar meta-funções, o WordPress não tocará nela, mas você precisará se lembrar de decodificar os dados em JSON na recuperação.

Se o tamanho do armazenamento do banco de dados for muito importante para você, provavelmente valerá o trabalho adicional; caso contrário, deixe o WordPress usar o que usa e não se importe com isso.

Talvez você possa avaliar se é o caso de tabelas personalizadas para salvar seus dados.

Estou tentado a encerrar isso como "sujeito a opinião", mas acho que há algumas boas respostas para a pergunta. Eu vou com a "história".

1) json_encodeé relativamente novo no núcleo do PHP.

json_encode

(PHP 5> = 5.2.0, PECL json> = 1.2.0) json_encode - Retorna a representação JSON de um valor

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

json_encodenão seria confiável nos primeiros dias do WordPress. Ele foi lançado apenas no PHP "principal" na versão 5.2, embora estivesse disponível como uma extensão PECL muito antes disso.

Segundo, se você alimentar um objeto como um WP_Queryobjeto, json_encodevocê o stdClasscoloca json_decode. serialize/ unserializepreservará o objeto.