json encode php кириллица
Генератор utf-8 json на php с поддержкой unicode 6
Разумеется, в PHP есть прекрасная функция json_encode. Но до версии 5.3 включительно те же русские символы кодируются в виде \uXXXX — в разы длиннее, чем utf-8. Чтобы уменьшить объем трафика, необходимо убрать преобразование utf-8 символов в \u-последовательности. Да, в PHP 5.4 у json_encode наконец-то появился параметр JSON_UNESCAPED_UNICODE, но многие хостеры до сих пор представляют пользователям выбор только между версиями 5.2 и 5.3.
Я бы не стал изобретать очередной велосипед, но те решения, которые мне попадались, имеют общую проблему — они корректно обрабатывают только символы базовой плоскости юникода.
Способ, в разных модификациях широко распространенный на просторах интернета, заключается в том, что результат работы ф-ции json_encode обрабатывается фильтром, заменяющим все вхождения \uXXXX на utf-8 символы. Например, так:
И этот код работал… До тех пор, пока не понадобилось добавить поддержку юникодных emoji (эмотиконы были добавлены в стандарте Unicode 6), большинство из которых имеет коды более 0x1F000 (первая плоскость unicode).
Дело в том, что \u-последовательности имеют кодировку utf-16: слово (2 байта) на символ с кодом от 0x0000 до 0xFFFF (исключая «окно» 0xD800-0xDFFF) и 2 слова (4 байта) с кодами 0xD800-0xDFFF для символов с кодами более 0xFFFF.
Например, исходный юникод-символ с кодом 0x1f601, имеющий utf-8 представление «\xf0\x9f\x98\x81», будет преобразован функцией json_dencode в строку «\ud83d\ude01» и результатом вышеприведенной ф-ции будет строка «\xed\xa0\xbd\xed\xb8\x81». Вместо одного 4-х байтового символа получили два 3-х байтовых.
Таким образом, для нормальной обработки символов необходим анализ кодов и отдельное преобразование 2-х символьных \u-последовательностей. Например, так:
Данный вариант корректно преобразовывает любые utf-8 символы.
Как правильно хранить json c кирилицей в MySQL?
Впервые столкнулся с такой вот проблемой!
Создаю строку JSON с кириллицей.
json_encode($data);
Вместо кириллицы \uXXX\uXXX
Запихиваю в MySQL и пропадают значки \ остается uXXXuXXX
Никаких экранирующих функций не применяю. Что и как правильно делать?
Я вот так решился сохранять, БД в UTF8,файлы в UTF8, соединение в такой же кодировке.
json_encode($massx,JSON_UNESCAPED_UNICODE);
Насколько это некорректно/опасно?
Заранее спасибо всем ответившим!
У вас слеши пропадают на уровне php, это видимо можно проверить прогнав str_replace(‘\\u’,’\\\\u’,json_encode($data));
Глюки на уровне Mysql можно прореветь переведя тип поля в которое пишется json в тип blob, если стало ок, то что то не так с кодировками в базе или соединении с ней.
json_encode($massx,JSON_UNESCAPED_UNICODE); не решит проблему со слэшами, они используются не только для юникода
слеш в строчках служит для написания непечатных/управляющих кодов в виде букв. Это не mysql это везде так. Например \t это не слеш + t (два символа), это один символ табуляции. так же и \u это не два символа а один, чёрт пойми какой.
если вы сделаете insert into t set col = ‘a\n\n\nb’; а потом select col from t; то вы уведите:
a
b
т.е. три пустые строки межу a и b, если вы хотите сохранить само сочетание \n, то нужно писать insert into t set col = ‘a\\n\\n\\nb’; Тогда при селекте будет a\n\n\nb, т.к. для того, что бы закодировать слеш в строке его нужно экранировать тем же слешем. Это нормально.
json_encode и кириллица
Мальчишки, девчонки, низкий всем поклон! Больше отдыхайте и всё будет отлично!
У меня не работает пишет ошибку:
Warning: json_encode() expects parameter 2 to be long
эм… я на 99,999 уверен, что у меня utf-8.
на всякий случай перед помещением в массив конвертил так:
iconv(‘cp1251’, ‘utf-8’, ‘значение’);
Действительно, null превратился в последовательность типа u0437u0430 и тд.
То есть снова не могу декодировать. Ещё одна проблема в том, что между encode и decode весь JSON сохраняется в БД и декодируется уже оттуда.
Чувствую, что истина где-то рядом, но туплю 🙁
Или изначально работайте c utf-8, но тогда вам скорее всего придется все скрипты переписать (потому что обычные строковые функции уже не подойдут), или заранее конвертируйте данные.
mysql_connect(«localhost», «qwer», «qwer»);
mysql_select_db(«termito»);
mysql_query(‘set names utf8’);
$r = mysql_query(«select * from `company_info` WHERE `id`=».mysql_insert_id());
$r = mysql_fetch_array($r);
$a = json_decode($r[‘info’],true);
echo(($a[‘name’]));
/*на выходе упорно u0437u043du0430u0447u0435u043du0438u0435*/
Кириллица в json_encode
Примечание: не используя второй параметр json_encode и mb-функции.
7 ответов 7
В PHP начиная с версии 5.4.0 появился флаг JSON_UNESCAPED_UNICODE и все стало намного проще:
Пришлось писать свою функцию. Надеюсь, не сильно накосячил?
в начале файла добавь
Указывать Content-Type свой, по ситуации
Предположу, что данные идут с базы данных. В таком случае при подключении к базе данных необходимо указать кодировку подключения — UTF-8.
Вот рекурсивная функция, которая может конвертировать в UTF-8 все строки в массиве и объекте:
Также json_last_error() может быть полезным в отладке json_encode()/json_encode() функций.
Всё ещё ищете ответ? Посмотрите другие вопросы с метками json php или задайте свой вопрос.
Связанные
Похожие
Подписаться на ленту
Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.
дизайн сайта / логотип © 2021 Stack Exchange Inc; материалы пользователей предоставляются на условиях лицензии cc by-sa. rev 2021.9.16.40232
Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.
json_encode в PHP превращает кирилицу в \u041D коды
В несколько более ранних версиях языка PHP (где JSON_UNESCAPED_UNICODE ещё нет) успешно срабатывает вот такая штука:
И применяют её при выводе JSON вот таким образом:
OnYourLips, смысл в том, что серверов много, админов — мало, и обновление не запланировано. а поддерживать мультибайт кодировки надо сейчас. Архитектор проекта не знал, о том что такая проблема возникнет, да и я сам не знал пока не наткнулся на неё.
Решение котороя я использую:
Собственно, «исправлять» не обязательно (хотя в плане перфекционизма я вас хорошо понимаю). Это легитимные JS-строки, в браузере отображаются корректно. Объём данных, правда, больше. Но, с другой стороны, Gzip-сжатием этот фактор минимизируется. 😉
Можно ещё делать так:
Тогда в свежих версиях PHP JSON-код будет наиболее оптимальным по объёму, а в более старых — всего лишь несколько менее оптимальным.