PHP/MySQL Encoding

У меня есть веб-сайт с арабским контентом, который был перенесен с другого сервера. На старом сервере все отображалось правильно, предположительно все кодировалось UTF-8.PHP/MySQL Encoding

На текущем сервере данные начали неправильно отображаться, показывая Ü † Ø¨Ø ° Ø © Ø¹у † и аналогичные символы.

Приложение основано на CakePHP Framework.

После многих испытаний я изменил параметр 'encoding' в массиве соединений MySql, чтобы стать «latin1». Для людей, которые не знают CakePHP, это устанавливает кодировку соединения MySql. Установка этого значения в UTF8 ничего не изменила, даже после шагов, описанных ниже.

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

Я уже прошел через все проверки базы данных и сервера, подтверждая, что:

база данных создана в UTF-8.
Таблица UTF-8.
В столбцах явно не указывается какая-либо кодировка, закодированная в UTF-8.
Набор символов по умолчанию в РНР настройки mysql.cnf UTF-8
по умолчанию UTF-8

После этого я восстановил мои данные и петельные через него, выводя кодирование каждой строки (из каждая строка) с использованием mb_detect_encoding. Строки, которые отображаются правильно, возвращают UTF8, пока он ничего не возвращает для поврежденных строк.

Данные веб-сайта были отредактированы на нескольких типах, возможно с различными кодировками, это то, что я точно не знаю. Однако я могу подтвердить, что только 2 кодирования, которые эти данные могли пройти, - это UTF-8 и latin1.

Есть ли способ восстановить данные, когда mb_detect_encoding ничего не возвращает, а текущий набор данных неизвестен?

ОБНОВЛЕНИЕ: Я выяснил, что, когда база данных была активна на новом сервере, my.cnf был обновлен. Приведенная ниже директива была изменена:

символьный набор-сервер = utf8

Для

по умолчанию-символьный набор = utf8

Я не уверен, насколько это имеет значение, хотя.

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

источник

2015-06-17 Adon

если у вас есть phpmyadmin .. вы можете увидеть свои данные в таблицах ... правильно ли они отформатированы .. я имею в виду арабские символы ?? –

Нет, данные повреждены внутри phpmyadmin. Я на самом деле выводю данные, которые я читаю, и он поврежден, поэтому это в основном та же логика. – Adon

, если данные повреждены внутри вашей базы данных .. это означает, что ваша проблема не в Cackephp .. это из самой базы данных. Экспорт вашей базы данных снова с старого сервера с UTF8 –

Попробуйте исправить проблему с DB стороны .. не из PHP или соединения DB

Я советую вам идти на ваш старый сервер и экспортировать БД снова с набором символов UTF8

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

, то вы можете перейти проверить следующий

DB соединение
кодирования PHP файл
кодирование заголовка в HTML

, как я знаю, что если проблема с БД .. нет никакого способа, без экспорта снова данные от старого сервера

Edit:

если у вас нет доступа к вашей старой БД, пожалуйста, проверьте this answer, это может вам помочь

источник

2015-06-17 18:28:09

Как я уже говорил ранее, у меня больше нет доступа к старому серверу. Это решение не будет работать для меня. Я опубликую соответствующее обновление, потому что у меня есть новый вход. – Adon

@Adon я отредактировал мой ответ –

Я проверю это как можно скорее и сообщит вам. Благодарю. – Adon

Вы ожидали, что نبذة عن? Кракозябры. См. duplicate для обсуждения и решения, в том числе, как восстановить данные через пару ALTER TABLEs.

источник

2015-06-24 21:20:43

Это правильно. Мне интересно, как вы это достигли. Я уже пробовал решение, и это не сработало для меня. Я должен использовать тип данных 'text' вместо' varchar' из-за ограничений по размеру, но я не думаю, что это вызовет проблему, потому что они в основном хранят данные одинаково. Я использую mysql 5.5.42, но я также считаю, что это не проблема, так как это поведение должно быть одинаковым во всех последних версиях 5.x. Любые мысли об этом? – Adon

'TEXT' vs' VARCHAR' - они работают одинаково. Версия 5.x - Проблема проявляется аналогично с 4.1. 'BINARY (CONVERT ('Ü † Ø¨Ø ° Ø © Ø¹" † USING latin1)) = نبذة عن'. Сохраненные данные должны быть (в HEX): D986D8A8 ...; HEX для того, что вы говорите, это C383E284A2C3A2E282AC ... [Подробнее обсуждение] (http://mysql.rjweb.org/doc.php/charcoll). –

Правда, я получаю правильную шестнадцатеричную строку. Проблема заключается в обращении к правильной строке. Он преобразуется обратно в тот же неузнаваемый текст. Запросы: 'alter table dynamic_page_i18n изменить COLUMN content varbinary (1000) NOT NULL DEFAULT '';' а затем 'alter table dynamic_page_i18n изменить текст содержимого COLUMN CHARACTER SET utf8 NOT NULL DEFAULT '';' Не повезло. Я знаю, что они должны работать, но это не так. База данных - utf8, таблица - utf8, а сортировка - utf8_general_ci. – Adon

У меня была аналогичная проблема с миграцией таблиц базы данных, закодированных с utf8 с общего сервера на localhost. Разрешение было в настройке кодировки локального сервера с помощью PHP

$db->set_charset("utf8")

сразу после mysqli соединения.

Теперь он работает правильно.

источник

2017-07-28 11:00:44

PHP/MySQL Encoding

ответ

Смежные вопросы