Почему WordPress выбирает сериализацию данных вместо json_encode?

В моем маленьком возрасте с WordPress я видел сам WordPress, и его дружественные плагины используют PHP serialize()для хранения данных в БД во многих случаях. Но в недавнем поиске я нашел серьезную поддержку сообщества для json_encode()более serialize().

• Тест, который оказывается json_encode()лучше, чем serialize()- StackOverflow
• Причины, почему json_encode()можно использовать, а почему нет - StackOverflow

И я лично проверил ассоциативный массив с обоими из них, который показывает:

• serialize() хранит 342 символа
• json_encode() хранит 285 символов

Почему я спрашиваю это?

Я нахожусь в проекте, в то время как я собираюсь сохранить повторяющиеся мета-поля в сообщение. Где:

• Данные будут в основном на английском языке, но иногда могут быть бенгальскими
• Данные будут ассоциативным массивом глубиной 3 уровня (надеюсь, я правильно понял уровни ):

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

Я проверил поле postmetaтаблицы, meta_valueэто longtext, что означает длину 4 294 967 295 символов (4 ГБ).

Поэтому мне нужно надежное решение для хранения вещей.

Я не уверен на 100%, что именно по этой причине разработчики WP выбрали такой подход, но здравый смысл подсказывает мне, что serialize сохраняет типы переменных и имеет мини-встроенное средство обнаружения ошибок, а json хранит только строковые значения { key : value }, поэтому, когда вы Вернитесь к PHP, вам нужно будет угадать формат или создать для него парсер. Это заставит вас иметь два разных способа обработки ваших данных: предыдущий, чтобы сохранить данные как json, и после декодирования json они вернутся как совершенно другой объект.

Это основная причина разницы в размерах, PHP хранит не только массив; он хранит, сколько элементов было в массиве, когда он был сериализован, их типы и их значения.

Вы храните не только пары ключ-значение в базе данных, но вы также можете хранить объект с различными типами переменных.

Кодировка JSON была введена в PHP 5.2, WordPress намного старше, и она родилась (и предназначена для) PHP 4.

Сериализация данных широко распространена в WordPress, поэтому переход от сериализации PHP к кодированию JSON означал бы огромную проблему обратной совместимости, и если я немного знаю WordPress, этого никогда не произойдет.

Тем не менее, если вы думаете, что кодировка JSON лучше для вас, чем сериализация PHP, просто используйте ее.

Если вы передаете строку (то есть версию ваших данных в кодировке JSON) для публикации мета-функций, WordPress не будет к ней прикасаться, но тогда вам нужно будет помнить JSON-декодирование данных при извлечении.

Если для вас очень важен размер хранилища БД, то это, вероятно, стоит дополнительной работы, в противном случае просто позвольте WordPress использовать то, что он использует, и не заботиться об этом.

Может быть, вы можете оценить, если это случай пользовательских таблиц для сохранения ваших данных.

Я испытываю желание закрыть это как "предмет для мнения", но я думаю, что есть несколько хороших ответов на вопрос. Я собираюсь пойти с "историей".

1) json_encodeявляется относительно новым в ядре PHP.

json_encode

(PHP 5> = 5.2.0, PECL json> = 1.2.0) json_encode - возвращает JSON-представление значения

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

json_encodeне было бы надежным в первые дни WordPress. Он был внедрен в «основной» PHP в 5.2, хотя задолго до этого он был доступен как расширение PECL.

Во-вторых, если вы вводите объект, такой как WP_Queryобъект, json_encodeвы получаете stdClassобъект json_decode. serialize/ unserializeсохранит объект.