Меню Рубрики

Установка кодировки соединения php mysql

Исправление и изменение кодировок MySQL

В связи с тем, что довольно много людей обращается с просьбой помочь исправить проблему с кодировками MySQL, решил написать статью с описанием, как «лечить» наиболее часто встречающиеся случаи.

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

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

Небольшое отступление. Sypex Viewer

В какой-то момент надоело отправлять людей в громоздкий phpMyAdmin, и была написана крошечная утилитка Sypex Viewer. Она представляет собой один PHP-файл, использует современные Web 2.0 технологии AJAX, JSON и другие. Основные задачи, которые ставилась при создании — минимальный вес, и максимальное удобство и скорость работы. В дальнейшем в примерах будут скриншоты из неё, но все те же действия можно сделать и в phpMyAdmin.

Данные в cp1251 таблицы в latin1

Наверное, самая популярная проблема. Когда данные в кодировке cp1251 (Windows-1251), а у таблиц указана кодировка по умолчанию latin1. Такие ситуации возникают в следующих случаях:

  • при неграмотном обновлении с версии MySQL меньше 4.1 на более новые;
  • очень часто возникает в «буржуйских» скриптах, которых вполне устраивает кодировка по умолчанию, и они «забывают», что неплохо бы указывать кодировку, как таблиц, так и соединения;
  • также бывают случаи, когда переезжают с одного сервера (у которого установлена дефолтная кодировка cp1251, в частности, так сделано в Денвере) на другой (у которого стоит стандартная кодировка latin1).

В результате на сайте вроде как всё нормально, но если посмотреть в Sypex Viewer, то русские символы будут выглядеть как «кракозябры» (как их обычно называют пользователи).

В статье я рассмотрю один из вариантов преобразование кодировок с помощью бесплатного php-скрипта Sypex Dumper, в качестве готового решения.

  1. На вкладке «Экспорт» выбираем нужные таблицы.
  2. Кодировка должна быть auto (остальные параметры неважны, можно комментарий добавить, например, «Дамп перед исправлением кодировки»).
  3. Нажимаем «Выполнить». Теперь у нас есть бэкап (его в любом случае желательно делать при любых преобразованиях базы данных).
  4. Переходим на вкладку «Импорт»
  5. Выбираем только что сделанный файл бэкапа.
  6. Выбираем кодировку cp1251 и помечаем опцию «Коррекция кодировки».
  7. Нажимаем «Выполнить».
  8. Вот и всё заходим в Sypex Viewer, чтобы убедиться, что русские символы выводятся корректно.

Данные и таблицы в utf8, но кодировка соединения latin1

Теперь рассмотрим более запущенный случай. Набирающая популярность в последнее время проблема, в связи с повальным увлечением UTF-8. Создатели софта стали переводить свои детища на UTF-8, но и тут не всё так гладко, как хотелось бы.

Возникает проблема в основном в случае, когда у таблиц указана кодировка UTF-8, данные в UTF-8, но кодировка соединения установлена по умолчанию latin1 (типичный пример, vBulletin 4, хоть там и есть в конфигах настройка кодировки соединения, но она закомментирована по умолчанию).

В результате в MySQL присылаются данные в UTF-8, но поскольку указана кодировка соединения latin1, то MySQL пытается преобразовать данные из latin1 в UTF-8. В итоге русские символы выглядят так:

Ситуация более запущенная, но исправляется проблема почти также, как в первом случае, только в пункте 2 нужно выбрать кодировку latin1, а в пункте 6 нужно выбрать utf8 кодировку.

Изменение кодировки

Также часто встречающаяся проблема преобразования кодировки из cp1251 в UTF-8. До выполнения этого шага обязательно убедитесь, что русские символы у вас правильно показываются в Sypex Viewer или phpMyAdmin, если это не так, то предварительно исправьте кодировку.
Итак, опять заходим в Sypex Dumper.

  1. Во вкладке «Экспорт» выбираем нужные таблицы.
  2. Устанавливаем кодировку, в которую хотите преобразовать таблицы, в данном случае utf8.
  3. Нажимаем «Выполнить».
  4. После чего заходим в «Импорт» и выбираем нужный файл.
  5. Выставляем кодировку utf8 и опцию «Коррекция кодировки».
  6. Нажимаем «Выполнить».
  7. Вот и всё таблицы в UTF-8. Не забываем, что нужно еще установить кодировку соединения, сконвертировать ваши скрипты и шаблоны в UTF-8, выставить правильную кодировку в заголовках.

Кодировка соединения

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

Для чего достаточно пройтись поиском по файлам, и найти где вызывается функция mysql_connect (или mysqli_connect). После этой строки нужно добавить строку которая укажет кодировку соединения.

Где вместо cp1251, указать нужную кодировку соединения.

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

источник

mysql_set_charset

mysql_set_charset — Устанавливает кодировку клиента

Данное расширение устарело, начиная с версии PHP 5.5.0, и удалено в PHP 7.0.0. Используйте вместо него MySQLi или PDO_MySQL. Смотрите также инструкцию MySQL: выбор API и соответствующий FAQ для получения более подробной информации. Альтернативы для данной функции:

Описание

Устанавливает кодировку по умолчанию для текущего соединения.

Читайте также:  Установка ubuntu разметка диска gpt

Список параметров

Корректное название кодировки.

Соединение MySQL. Если идентификатор соединения не был указан, используется последнее соединение, открытое mysql_connect() . Если такое соединение не было найдено, функция попытается создать таковое, как если бы mysql_connect() была вызвана без параметров. Если соединение не было найдено и не смогло быть создано, генерируется ошибка уровня E_WARNING .

Возвращаемые значения

Возвращает TRUE в случае успешного завершения или FALSE в случае возникновения ошибки.

Примечания

Данная функция требует MySQL версии 5.0.7 или выше.

Это наиболее предпочитаемый способ для смены кодировки. Использование mysql_query() в этих целях (например SET NAMES utf8) не рекомендуется. Смотрите раздел кодировка символов в MySQL для подробной информации.

Смотрите также

User Contributed Notes 8 notes

I needed to access the database from within one particular webhosting service. Pages are UTF-8 encoded and data received by forms should be inserted into database without changing the encoding. The database is also in UTF-8.

Neither SET character set ‘utf8’ or SET names ‘utf8’ worked properly here, so this workaround made sure all variables are set to utf-8.

// . (creating a connection to mysql) .

mysql_query ( «SET character_set_results = ‘utf8’, character_set_client = ‘utf8’, character_set_connection = ‘utf8’, character_set_database = ‘utf8’, character_set_server = ‘utf8′» , $conn );

$re = mysql_query ( ‘SHOW VARIABLES LIKE «%character_set%»;’ )or die( mysql_error ());
while ( $r = mysql_fetch_assoc ( $re )) < var_dump ( $r ); echo "
» ;> exit;

?>

All important variables are now utf-8 and we can safely use INSERTs or SELECTs with mysql_escape_string($var) without any encoding functions.

Here’s an example of how to use this feature :

I wanted to store arabic characters as UTF8 in the database and as suggested in many of the google results, I tried using

mysql_query(«SET NAMES ‘utf8′»);

mysql_query(«SET CHARACTER SET utf8 «);

Using the following, it worked flawlessly

$link = mysql_connect(‘localhost’, ‘user’, ‘password’);
mysql_set_charset(‘utf8’,$link);

Once this is set we need not manually encode the text into utf using utf8_encode() or other functions. The arabic ( or any UTF8 supported ) text can be passed directly to the database and it is automatically converted by PHP.
For eg.
= mysql_connect ( ‘localhost’ , ‘user’ , ‘password’ );
mysql_set_charset ( ‘utf8’ , $link );
$db_selected = mysql_select_db ( ’emp_feedback’ , $link );
if (! $db_selected ) < die ( 'Database access error : ' . mysql_error ());>
$query = «INSERT INTO feedback ( EmpName, Message ) VALUES (‘ $_empName ‘,’ $_message ‘)» ;
mysql_query ( $query ) or die( ‘Error, Feedback insert into database failed’ );
?>
Note that here $_empName is stored in English while $_message is in Arabic.

Massage for nabeelmoidu at gmail dot com:

For me works following code:

$mysqli = mysqli_connect( . );
mysqli_query( $mysqli, ‘SET NAMES «utf8» COLLATE «utf8_general_ci»‘ );

mysqli_set_charset( $mysqli, ‘utf8’ );

I just hope that the text below will help someone who is struggling with charset encoding, specially when php-charset is different from the mysql-charset. Let me add that I really think that the php man-pages on the mysql-functions are lacking a lot of details on this important issues. Could someone add some useful text here?

Here is my situation. PHP5.2.4, MySql 4.1.15. A php web-application fully utf-8 encoded and a mysql database in latin1 charset.

To make this work I had to:

1. create and store all code files (php, html, inc, js, etc) in the utf-8 charset. Your editor should have an option for this, if not dump it.

2. check that your editor does not add a BOM (http://en.wikipedia.org/wiki/Byte-order_mark) at the beginning of the file. Use a hex-editor to detect them if needed.

3. Set your apache environment to utf-8 by adding ‘AddDefaultCharset utf-8’ to your .htaccess. If you do not use apache add ‘default_charset utf-8’ to your php.ini. You have to do either of them (not both), php will use the apache setting where needed.

4. Additionally add this meta-tag to your html-header: ‘ ‘. This will help silly browsers (Oeps, IE again?) that ignore the utf-response-header send to them.

5. Check that the above line are listened to by check the ‘page info’ of your pages in firefox. It should show 2 (!!) utf-8 entries.

======== all of the above sofar has nothing to do with mysql 😉 ======

6. Do *NOT* (repeat NOT!) set the ‘names’ (set names *) or _ANY_ ‘character set’ (set character set *) (opposed to what they tell you on these pages).

7. Check the previous item by listing the results of the mysql query ‘SHOW session VARIABLES’. All char_sets here should say ‘latin1’, except for the system one which is always ‘utf8’. All collations should say ‘latin1_*’. Furthermore the php function mysql_client_encoding() should also return latin1 (though I don’t understand why; what does this value mean, I would think if php (being the client) is utf8 encoded this would be utf8?)

8 Finally test the above by storing this string in your db and output it in your webpage: ‘Iñtërnâtiônàlizætiøn and €’.

Now what was interesting during testing and debugging of the above findings was:
1. If I would run ‘mysql_set_charset(‘utf8′)’ _OR_ ‘mysql_query(«SET NAMES ‘utf8′»);’ and then run a query in which I would have ‘where char_column = ‘abc»it would die with ‘Illegal mix of collations’

Читайте также:  Установка лед ламп в фары приора

2. If I would run ‘mysql_query(«SET character_set_client = ‘utf8’;»); mysql_query(«SET character_set_result = ‘utf8′;»)’ the query would work BUT the non-ascii-characters would show scrambled in the browser.

3. BUT these 2 points above work just fine on my local dev-machine (php 5.2.3 & mysql 5.0.45).

This draws me to these 3 conclusions:

1. The Php-mysql-function library (5.2.+) does a fine job translating utf-8 queries & results to/from latin1! It’s better to let php handle this for you then to have mysql do this.

2. Mysql (4.0.+) has 1 or more bugs (well, let’s say unfinished features) that involve the charset-translations that are solved in 5.0.+.

3. It is not well enough documented! (Otherwise I would have to write this)

One last remark: clearly characters that exist in utf8 and not in latin1 (and vv.) will get lost during utf8-latin1-utf8 translation.

If any of the above is not correct or not complete feel free to correct this! (Or better yet, add a chapter to the php manual 🙂

источник

Использование кодировок в MySQL >= 4.1

Когда я только начал осваивать InnoDB и транзакции в MySQL (понадобилось обновить версию с 3.23 до 4.1) столкнулся с проблемой некорректного обмена данными между PHP и MySQL которая проявлялась в том, что сервер вместо символов кириллицы, в запросах генерируемых php-скриптом, вставлял в ячейки таблиц БД знаки вопроса. В процессе «выкуривания» документации, чтения форумов и изучения статей пришло понимание проблемы и нашелся способ ее решения.

Первопричиной проблемы оказалось то, что до версии 4.1 кодировку можно было задать только для всего сервера (определив значение параметра —default-charset ), а начиная с версии 4.1 разработчики добавили возможность определения кодировки на разных уровнях иерархии СУБД (для всего сервера, БД, таблиц, столбцов).

Немного терминологии

CHARACTER SET — это некий набор символов, называемых кодировкой. Разные CHARACTER SET включают в себя различные наборы символов. Различные CHARACTER SET могут включать примерно одинаковые наборы символов но в различном порядке (см. например koi8ru и cp1251). MySQL необходимо знать какой CHARACTER SET будет использован для данных в таблице, чтобы корректно проводтиь сортировку и индексацию данных.

COLLATION — способ, с помощью которого следует упорядочивать и сравнивать данные в БД.
Для одного и того же CHARACTER SET существует как правило несколько COLLATION. Например: cp1251_general_ci — сравнение не чувствительное к регистру, cp1251_bin — чувствительное к регистру.

Для того чтобы избежать проблем с кодировками нужно иметь представление о том, как для разных уровней иерархии СУБД их можно задать.

Способы задания кодировок

1) Для всего сервера при компиляции, определив параметры —with-charset и —with-collation :

Работа с клиентскими программами

Любой mysql-клиент при соединении с сервером может установить несколько переменных:

  • character_set_client — указывает, в какой кодировке будут поступать данные от клиента;
  • character_set_connection — указывает, в какую кодировку следует преобразовать данные полученые от клиента перед выполнением запроса;
  • collation_connection — указывает, каким образом сравнивать между собой строки в запросах;
  • character_set_results — указывает серверу не необходимость перекодировать результаты запроса в определенную кодировку перед выдачей их клиенту.

Для корректной работы клиента с сервером следует установть как минимум character_set_client, character_set_connection, character_set_results при помощи оператора SET:

источник

Выставляем кодировку UTF-8

На сколько бы это глупо не казалось, но для удачного выставления кодировки необходимо выполнить целых 11(!) правил.
Хочу зарание предупредить, если какая-то из настроек в .htaccess повлечет за собой ошибку 500, это значит, что хостинг запретил менять этот параметр на сервере. В таком случае проверьте тот факт, что у Вас UTF-8 и в случае чего обратитесь к админам хостинга.
И для тех, кто попал на эту страницу с вопросами об Ajax: Ajax работает в кодировке UTF-8.

Правило №1: Указываем в HTML верстке в теге первой строчкой, кроме случаев, где мы будем использовать тег , так как он так же как и кодировка имеет приоритет над расположением, следующий код:

Правило №2: Указываем кодировку для PHP и самого файла, для этого нам необходимо выставить заголовок функцией header(). Выставляем его в самом начале нашего файла (абсолютно в самом начале), сразу после указания уровня вывода ошибок:

Правило №3: Кодировка для подключения к к БД MySQL. Устанавливается после подключения к БД и выбора бд (mysql_connect, mysql_select_db). Если у нас модуль mysql:

или улучшенный модуль mysqli:

Правило №4: Кодировка в .htaccess:

Правило №5: Кодировка для библиотеки mb, начиная с версии php 5.4 можно не указывать, так как по умолчанию будет использоваться именно UTF-8. Ну а пока прописываем её в файле .htaccess:

Либо в самом PHP, что в итоге выполнит одни и те же действия:

Правило №6: При сохранении файлов (обязательно ВСЕХ!) выбрать кодировку UTF-8 without BOM, повторюсь, without BOM — это необходимая настройка, в противном случае Ваш сайт не будет работать как надо. Для тех, кто пользуется удобной программой DreamWeaver:
Modify => Page Properties => Title/Encoding и выставляем «Encoding: UTF-8», после чего нажимаем ReLoad, убираем галочку с BOM «Include Unicode Signature (BOM)». Apply + OK.
Модификации => Свойства страницы => Заголовок/Кодировка и выставляем кодировку UTF-8. Нажимаем «перезагрузить», убрали галочку с Подключить Юникод Сигнатуры (BOM). Применить и OK.

Читайте также:  Установка влагоотделителя на камаз 5320

Правило №7: если на данный момент какой-то из текстов был введён на странице или в БД — его необходимо перенабрать. Дело в том, что символ в одной кодировке представляет один набор бит для русских символов, а в другой — другой. Именно поэтому необходимо его либо перенабрать, либо перекодировать. Современные программы имеют возможность перевести текст из одной кодировки в другую. Об этой возможности интересуйтесь в мануалах Ваших программ.

Правило №8: Есть исключение, когда текст приходит к Вам на страницу с другого сайта в другой кодировке. Тогда на PHP есть удобная функция для перевода из одной кодировки в другую:

Правило №9: Для строковых функций strlen, substr, необходимо использовать их аналоги на библиотеке mb_, а именно: mb_strlen, mb_substr, то есть к функции дописываем mb_ .

Правило №10: Для работы с регулярными выражениями необходимо указывать модификатор u . Это обязательный параметр!

Правило №11: Для CSS файлов указывается кодировка так:

В заключение скажу, что символы в кодировке WIN-1251 состоят из 1 байта, то есть 8 бит, а в свою очередь в кодировке UTF-8 символы могут состоять от 1 до 4 байт, всё дело в том, что кодировка UTF-8 позволяет создавать мультиязычные сайты, так как все существующие в мире символы в ней присутствуют.
Ради любопытства русская буква в кодировке UTF-8 занимает 2 байта, именно поэтому за 1 символ функция strlen возвращает длину 2, то есть 2 байта, а mb_strlen возвращает уже правильную длину в 1 символ.

источник

Настройка MySQL

Установка всего программного обеспечения как MySQL, так и прочих пакетов (PHP, Phpmyadmin) была произведена на самом начальном этапе, — если помните, делали мы это командой: apt-get install apache2 php5 php5-mysql mysql-server phpmyadmin — см. подробнее->>>.

На какую процедуру пришлось убить больше всего времени при настройке MySQL, так это настройка кодировки. При извлечении информации из базы средствами PHP русские слова отображаются как вопросительные знаки — . Здесь существует проблема с кодировкой, так как загружаемая MySQL из репозитория Linux (Ubuntu 13.04) имеет кодировку UTF8 вперемешку с latin1, таким образом, любая из кодировок (cp1251 или utf8) при извлечении из MySQL будет отображаться коряво.

Если вам необходимо настроить кодировку cp1251, то первый способ, который легко отыскать в интернете и дающий решение данной проблемы – это просто в скрипт PHP, который у вас извлекает контент из базы, добавить вот такую строку:

mysql_query(«SET NAMES cp1251»);

Если не устраивает вариант, предусматривающий правку скритов, то необходимо править конфигурационный файл MySQL, в этой связи, прежде чем был найден ответ, была перепробована масса всяких вариантов, большинство из которых, вероятно, подходили для ранних версий Linux Ubuntu, но они не работают для UBUNTU 13.04.

default-character-set=cp1251 – не работает

Будем править конфигурационный файл my.cnf, который находится в каталоге /etc/mysql/my.cnf. Причем, если просто в my.cnf (путь — /etc/mysql/my.cnf ) [mysqld] заменить на такой вариант:
[mysqld]
default-character-set=cp1251

сохраняемся и перегружаемся:
service mysql restart

тогда при подключении к phpmyadmin мы получаем вот такую ошибку:
#2002 Невозможно подключиться к серверу MySQL

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

Рабочая конфигурация my.cnf MySQL

Выбираем другой алгоритм. Для начала входим в MySQL через phpmyadmin. На домашней странице в phpmyadmin видим заголовок «Основные настройки», в подразделе «Сопоставление кодировки соединения с MySQL» выбираем UTF8_UNICODE_ci.

Далее проверим конфигурацию MySQL. В phpmyadmin выберем вкладку SQL и пошлем туда запрос вида:
SHOW VARIABLES LIKE ‘char%’;
в ответ имеем:

Variable_name

Value character_set_client utf8 character_set_connection utf8

character_set_database

latin1 character_set_filesystem binary character_set_results utf8

latin1 character_set_system utf8 character_sets_dir /usr/share/mysql/charsets/

Видим в приведенной конфигурации в двух местах значения latin1, которые необходимо исправить в зависимости от того, какая кодировка вам нужна. Допустим, мы будем заменять на cp1251, поэтому в конфигурационном файле my.cnf, который находится в каталоге /etc/mysql/my.cnf, ищем модуль [mysqld] и меняем его на:

[mysqld]
skip-character-set-client-handshake
character_set_client=cp1251
character_set_server=cp1251

Делаем рестарт MySQL (перезагрузку необходимо делать всегда после внесения каких-либо изменений): service mysql restart

В phpmyadmin снова посылаем SQL — запрос вида:
SHOW VARIABLES LIKE ‘char%’;

Получаем ответ, исходя из которого видим, что наша конфигурация MySQL поменялась:

Variable_name

Value character_set_client utf8 character_set_connection utf8

cp1251 character_set_filesystem binary character_set_results utf8

cp1251 character_set_system utf8 character_sets_dir /usr/share/mysql/charsets/

У нас latin1 поменялись на cp1251, соответственно сразу после приведения конфигурации MySQL к указанному виду, из базы у нас извлекается все корректно, наконец-то видим русские слова. Вот пример нашего текста, извлекаемого из БД MySQL.

От кодировки БД MySQL теперь переходим к настройкам кодировки сообщений, которые у нас с сайта отправляются на электронную почту, см. PHP отправка на e-mail >>>

источник