Как кодировать данные JSON для хранения базы данных в MySQL?

Question

У меня есть страница, обогащенная javascript, которая передает большой JSON в формате php для помещения в базу данных MySQL. Данные в JSON включают строки, отправленные пользователем, и будут содержать строки, содержащие базовый html (<a>, <strong> и т. Д.).

Проблема, с которой я сталкиваюсь, заключается в том, что при экранировании строки, содержащей кавычку ', я не могу удалить косую черту, что приводит к сложным символам экранирования, таким как

<a href=\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'example.com\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'></a>

Каждый раз, когда пользователь сохраняет это, это усложняется, сильно раздувая поле базы данных.

Мое преобразование строки для вставки данных в MySQL:

$correspondenceArray = base64_encode(json_encode($_POST['saveArray']['correspondenceObject']));

И чтобы вернуть данные:

function stripslashes_deep($value)
{
    $value = is_array($value) ?
                array_map('stripslashes_deep', $value) :
                stripslashes($value);

    return $value;
}

$correspondenceJSON = stripslashes_deep(json_decode(base64_decode($resultArray['correspondence_array']), true));

Из того, что я сделал, я собираюсь убрать косые черты данных, поступающих из базы данных, чтобы в javascript содержались неэкранированные данные

Редактировать

Я понимаю, что json_encode($a,JSON_HEX_QUOT) может помочь, но сервер, на котором я работаю, имеет PHP 5.2.16, поэтому эта функция недоступна)

Answer 1

Не использовать генерацию строк для SQL.

Если используются заполнители, не будет проблем (с хранилищем) и не будет магического выходатребуется .Просто сохраните его как тип VARCHAR.Готово и сделано.

Санитарная обработка для вывода ( и во время ввода) должна также выполняться с использованием соответствующих библиотек - есть две разные операции ;однако это отдельная проблема, чем хранилище.

Редактировать

См. PDO как одну реализацию подготовленного оператора (читай: заполнитель).Другие могут существовать (я не использую PHP, но чувствую себя обязанным исправить увлечение ошибками проектирования, относящимися к построенным вручную SQL-запросам на основе строк.)

Параметры для подготовленных выражений don 'должны быть процитированы;водитель автоматически обрабатывает это. Если приложение использует исключительно подготовленные операторы, разработчик может быть уверен, что SQL-инъекция не произойдет (однако, если другие части запроса создаются с неэкранированным вводом, SQL-инъекция все еще возможна).

Звучит слишком хорошо, чтобы быть правдой.Теперь прекратил использование строковых операторов .Пожалуйста.

Удачного кодирования.