WordPress neden json_encode üzerinden veri serileştirmeyi seçiyor?

WordPress ile benim küçük yaşımda, WordPress'in kendisini gördüm ve dostu eklentileri serialize()birçok durumda db'ye veri depolamak için PHP kullanıyor . Ama yeni bir aramayla I için ciddi topluluk desteği bulundu json_encode()üzerinde serialize().

• Kanıtlayan bir test json_encode()daha iyidir serialize()- StackOverflow
• Neden json_encode()ve neden kullanılamıyor? - StackOverflow

Ve ben şahsen, her ikisini de içeren bir ilişkisel dizi test:

• serialize() mağazalar 342 karakter
• json_encode() mağaza 285 karakter

Bunu neden soruyorum?

Bir gönderide yinelenen meta alanları depolayacağım sırada bir projedeyim. Nerede:

• Veriler temel olarak İngilizce olacaktır, ancak bazen Bengalce olabilir
• Veri ilişkisel dizi, 3 seviye derin olacaktır (Umarım seviyeleri doğru anladım ):

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

postmetaTablonun meta_valuealanını kontrol ettim longtext, yani 4.294.967.295 karakter (4GB) uzunluğunda.

Bu yüzden şeyleri depolamak için sağlam bir çözüme ihtiyacım var.

Bence, bunun% 100 WP geliştiricilerinin bu yaklaşımı almasının gerçek nedeni olduğundan emin değilim, ancak sağduyu bana serileştirmenin değişken türlerini koruduğunu ve bir mini yerleşik hata algılama özelliğine sahip olduğunu ve json'un yalnızca dize değerlerini sakladığını { key : value }söylüyor. PHP'ye geri dönün, biçimi tahmin etmeniz veya bunun için bir ayrıştırıcı yapmanız gerekir. Bu sizi verilerinizi işlemenin iki farklı yoluna sahip olmaya zorlayacaktır: daha önce, verileri json olarak depolamak ve json'un kodunu çözdükten sonra tamamen farklı bir nesne olarak geri gelecektir.

Bu, boyut farkının ana nedenidir, PHP sadece bir dizi saklamak değildir; serileştirildiğinde dizide kaç öğe olduğunu, türlerini ve değerlerini depolar.

Veritabanında yalnızca anahtar / değer çiftlerini depolamıyorsunuz, aynı zamanda farklı değişken türlerine sahip bir nesneyi de saklıyor olabilirsiniz.

JSON kodlaması PHP 5.2'de tanıtıldı, WordPress çok daha eski ve PHP 4'te doğdu (ve için tasarlandı).

Veri serileştirme WordPress'te yaygın bir şeydir, bu yüzden PHP serileştirmeden JSON kodlamasına geçmek büyük bir geriye dönük uyumluluk problemi anlamına gelir ve WordPress'i biraz biliyorsanız, bu asla olmayacak.

Bununla birlikte, JSON kodlamasının sizin için PHP serileştirmesinden daha iyi olduğunu düşünüyorsanız, bunu kullanın.

Meta işlevler göndermek için bir dize (verilerinizin JSON kodlu sürümü) iletirseniz, WordPress ona dokunmaz, ancak alma sırasında JSON kodunu çözmeyi hatırlamanız gerekir.

DB depolama boyutu sizin için çok önemliyse, muhtemelen ek çalışmaya değer, aksi takdirde WordPress'in kullandığı şeyi kullanmasına izin vermeyin ve umursamayın.

Belki verilerinizi kaydetmenin özel tablolar olup olmadığını değerlendirebilirsiniz.

Ben bunu "görüşe tabi" olarak kapatmak için cazipim ama soruya birkaç iyi cevap olduğunu düşünüyorum. Ben "tarih" ile gideceğim.

1) json_encodePHP çekirdeğinde nispeten yenidir.

json_encode

(PHP 5> = 5.2.0, PECL json> = 1.2.0) json_encode - Bir değerin JSON temsilini döndürür

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

json_encodeWordPress'in ilk günlerinde güvenilir olmazdı. Bundan önce PECL uzantısı olarak mevcut olmasına rağmen, 5.2'de sadece "çekirdek" PHP'ye getirildi.

İkincisi, böyle bir şekilde bir nesne beslemek eğer WP_Queryiçine nesne json_encodebir olsun stdClassnesneyi json_decode. serialize/ unserializenesneyi korur.