У меня есть приложение Flex с кодировкой UT8. Он отправляется обратно на сервер (PHP), и данные записываются в Mysql (UT8 charset, utf8_general_ci). У меня нет никаких проблем при записи / чтении Umlaute из / в базу данных.
Я только понял, посмотрев данные с PHPmyadmin, что Umlaute каким-то образом преобразуется в:
ö => ö ü => ¼ и т. д.
Как я уже сказал, у меня не было никаких проблем. Странная вещь, когда я пишу Umlaute напрямую с PHPmyAdmin в базу данных, они отображаются правильно
Теперь я печатаю PDF, и мне нужно вызвать ut8_decode () для всех значений, чтобы отобразить их правильно. Однако те, которые введены вручную в БД (которые отображаются корректно в phpmyadmin), не декодируются.
Я полагаю, что они не записываются в Db в UT8, тогда как декодирование порождает их?
Thx, Martin
Я долгое время боролся с одной и той же проблемой. Запустите этот запрос, как только вы подключитесь к базе данных, и ваше веб-приложение отобразит символы, как они появляются в phpmyadmin:
SET NAMES 'utf8'
По какой-то причине MySQL настроен на мои системы, чтобы предположить, что ввод и вывод закодированы как latin1, что означает, что когда я отправляю его вход utf8, он неправильно хранит его в базе данных, но поскольку преобразование отменено для вывода, беспорядок отменяется и он отображается корректно в браузере (кроме случаев использования phpmyadmin, который точно отображает его). Это справедливо только тогда, когда преобразование приводит к символам, которые разрешены набором символов, используемым в поле базы данных, где он хранится, поэтому вы можете получить ошибки, если не прекратите это преобразование из-за вышеуказанного запроса.
Вы можете либо выполнить запрос SET NAMES 'utf8' каждый раз, когда вы открываете соединение с сервером MySQL, либо если у вас есть доступ администратора к серверу sql, вы можете добавить эти строки в свой файл my.cnf . Это установит UTF-8 как набор символов по умолчанию для каждого нового соединения и каждой новой созданной базы данных и таблицы:
[client] default-character-set=utf8 [mysql] default-character-set=utf8 [mysqld] collation-server = utf8_unicode_ci init-connect='SET NAMES utf8' character-set-server = utf8по[client] default-character-set=utf8 [mysql] default-character-set=utf8 [mysqld] collation-server = utf8_unicode_ci init-connect='SET NAMES utf8' character-set-server = utf8по[client] default-character-set=utf8 [mysql] default-character-set=utf8 [mysqld] collation-server = utf8_unicode_ci init-connect='SET NAMES utf8' character-set-server = utf8
Фундаментальный факт, который вы должны иметь в виду, когда речь идет об этой проблеме, заключается в следующем: байты и текст – две разные вещи, и всякий раз, когда вы конвертируете между ними, вы должны использовать правильную кодировку символов, то есть то же, что было / будет использоваться для обратного преобразования и один, который поддерживает все используемые символы.
Проблема в том, что с каждым дополнительным преобразованием и каждым дополнительным приложением, которое задействовано, есть шанс, что все пойдет не так. Веб-приложения – худший возможный случай в этом отношении, поскольку всегда есть несколько конверсий (обычно 2 * (количество приложений-1)) и несколько различных приложений – по крайней мере: веб-приложение, браузер и БД. В вашем случае также PHPMyAdmin.
Трудно сказать, какое преобразование пошло не так, когда их так много. Тем не менее, похоже, что ваши проблемы вызваны PHPmyAdmin, поскольку он отображает умлауты в виде двух символов, что типично для приложений, которые пытаются интерпретировать кодированные байты UTF-8 как Latin1. Теперь возникает вопрос, происходит ли ошибочное преобразование, когда PHPmyAdmin получает данные из БД или когда он передает данные в ваш браузер. Что такое кодировка, объявленная PHPmyAdmin в заголовках HTML-страниц? У вас есть возможность доступа к БД через не-веб-приложение, такое как DbVisualizer ? Если это так, сделайте это, так как оно исключает одно преобразование (и, следовательно, потенциал для ошибки).
Существует множество разных мест для установки набора символов в MySQL, это замечательно.
Похоже, вы на самом деле не храните UTF8, а вместо этого сохраняете строки UTF8 как latin1. Если они каким-то образом преобразуются в UTF8 при чтении из базы данных, они все равно будут отображаться правильно в вашем приложении.
Вы устанавливаете свои соединения с UTF-8, например?
SET CHARACTER SET utf8; SET SESSION character_set_server = utf8; SET character_set_connection = utf8;
Вот одна из возможностей:
Похоже, phpMyAdmin отображает данные UTF-8 как Latin-1. Проверьте заголовок Content-Type, который выдает phpMyAdmin. Если у вас есть firefox с помощью панели инструментов webdev, вы можете напрямую просмотреть заголовки, перейдя в раздел Информация -> Просмотреть заголовки ответов или информацию -> Просмотреть информацию о странице
У меня такая же проблема. Я сохранил данные с PHP в моей базе данных. Когда я показал данные скриптом PHP, все было в порядке. Но когда я просмотрел данные в phpmyadmin, умлауты были показаны неправильно. Ядро проблемы заключалось в том, что PHP, работающий на моем компьютере с Windows, по умолчанию сообщал в latin1 с сервером mysql, несмотря на то, что сам sever был установлен на utf8. Я решил проблему, вручную установив кодировку после того, как я подключился к моему mysql-серверу PHP:
$mysqliObj->set_charset("utf8");
Теперь данные сохраняются и отображаются правильно.
Используйте mysqli_set_charset(<connection goes here>,'utf8'); сразу после того, как вы открыли соединение mysqli.
Кстати, PHP предпочитает использовать эту функцию:
Это предпочтительный способ изменить кодировку. Использование mysqli_query () для его установки (например, SET NAMES utf8) не рекомендуется. Дополнительную информацию см. В разделе концепций набора символов MySQL. ( http://php.net/manual/mysqli.set-charset.php )
Для latin1_general_ci работала сортировка latin1_general_ci .