Немецкий Умлауте в Мысле / Phpmyadmin - PullRequest
6 голосов
/ 27 июня 2009

У меня есть приложение Flex с кодировкой UT8. Он отправляет обратно на сервер (PHP), а данные записываются в Mysql (кодировка UT8, utf8_general_ci). У меня нет проблем при записи / чтении Umlaute из / в базу данных.

Я только понял, просмотрев данные с помощью PHPmyadmin, что Umlaute каким-то образом преобразуется в:

ö => ¶¶ ü => ¼¼ и т.д.

Как я уже сказал, у меня вообще не было проблем. Странно то, что когда я пишу Umlaute напрямую с помощью PHPmyAdmin в базу данных, они отображаются правильно

Теперь я печатаю PDF, и мне нужно вызвать ut8_decode () для всех значений, чтобы правильно их отобразить. Однако те, которые введены вручную в БД (которые правильно отображаются в phpmyadmin), не декодируются.

Я полагаю, что они не записываются в БД в UT8, так как декодирование их нарушает?

  1. ) Но почему в БД в первую очередь странным образом отображаются значения в кодировке UT8? 2.) Как я могу вводить данные в mysql с PHPmyAdmin в UTF-кодировке? (Я установил соединение на ut8).

Thx, Martin

Ответы [ 8 ]

18 голосов
/ 04 августа 2010

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

SET NAMES 'utf8'

По какой-то причине MySQL настроен на мои системы, чтобы предполагать, что вход и выход кодируются как latin1, что означает, что когда я отправляю его на ввод utf8, он сохраняет его в базе данных неправильно, но поскольку преобразование обращено для вывода, беспорядок отменяется и отображается правильно в браузере (кроме случаев использования phpmyadmin, который отображает его точно). Это верно только в том случае, если результатом преобразования являются символы, разрешенные набором символов, используемым в поле базы данных, где оно хранится, поэтому вы можете получить ошибки, если не прекратите это преобразование с помощью вышеуказанного запроса.

2 голосов
/ 25 января 2017

У меня была такая же проблема. Я сохранил данные с PHP в моей базе данных. Когда я показал данные с помощью сценария PHP, все было хорошо. Но когда я смотрел данные в phpmyadmin, умлауты показывались неправильно. Суть проблемы заключалась в том, что PHP, работающий на моей машине с Windows, по умолчанию общался на латыни с сервером mysql, несмотря на то, что сам сервер был настроен на utf8. Я решил проблему, установив кодировку вручную после подключения к моему mysql-серверу с помощью PHP:

$mysqliObj->set_charset("utf8");

Теперь данные хранятся и отображаются правильно.

2 голосов
/ 12 августа 2013

Вы можете выполнить запрос 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
1 голос
/ 27 июня 2009

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

Проблема в том, что с каждым дополнительным преобразованием и каждым дополнительным приложением есть шанс, что что-то пойдет не так. Веб-приложения являются наихудшим возможным случаем в этом отношении, поскольку всегда существует несколько конверсий (обычно 2 * (количество приложений-1)) и задействовано несколько различных приложений - как минимум: веб-приложение, браузер и БД. В вашем случае PHPMyAdmin также.

Трудно сказать, какое преобразование пошло не так, когда их так много. Тем не менее, похоже, что ваши проблемы вызваны PHPmyAdmin, так как он отображает умлауты в виде двух символов, что типично для приложений, которые пытаются интерпретировать байты в кодировке UTF-8 как Latin1. Теперь вопрос заключается в том, происходит ли ошибочное преобразование, когда PHPmyAdmin получает данные из БД или отправляет данные в ваш браузер. Какая кодировка объявлена ​​PHPmyAdmin в заголовках его HTML-страниц? У вас есть возможность доступа к БД через не веб-приложение, такое как DbVisualizer ? Если это так, сделайте это, так как это устраняет одно преобразование (и, следовательно, возможность ошибки).

0 голосов
/ 22 ноября 2017

Собрание latin1_general_ci у меня сработало.

0 голосов
/ 20 февраля 2017

Используйте mysqli_set_charset(<connection goes here>,'utf8'); сразу после открытия подключения mysqli.

Кстати, спецификация PHP предпочитает использовать эту функцию вместо выполнения с запросом:

Это предпочтительный способ изменить кодировку. Использование mysqli_query () устанавливать его (например, SET NAMES utf8) не рекомендуется. Смотрите MySQL раздел концепций набор символов для получения дополнительной информации. (http://php.net/manual/mysqli.set-charset.php)

0 голосов
/ 27 июня 2009

Вот одна из возможностей:

Похоже, phpMyAdmin отображает данные UTF-8 как Latin-1. Проверьте заголовок Content-Type, который выдает phpMyAdmin. Если у вас есть Firefox с панелью инструментов webdev, вы можете увидеть заголовки напрямую, перейдя в Информация -> Просмотр заголовков ответа или Информация -> Просмотр информации о странице

0 голосов
/ 27 июня 2009

В MySQL так много разных мест для установки набора символов, это замечательно.

Похоже, вы на самом деле не храните UTF8, а вместо этого сохраняете строки UTF8 как latin1. Если они каким-то образом конвертируются в UTF8 при чтении из базы данных, они все равно будут корректно отображаться в вашем приложении.

Настраиваете ли вы подключения к UTF-8, вот так?

SET CHARACTER SET utf8;
SET SESSION character_set_server = utf8;
SET character_set_connection = utf8;
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...