Mysql ошибка кодировки

Время на прочтение
3 мин

Количество просмотров 22K

Боремся с кракозябрамиВ связи с тем, что довольно много людей обращается с просьбой помочь исправить проблему с кодировками 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). После этой строки нужно добавить строку которая укажет кодировку соединения.

mysql_query("SET NAMES 'cp1251'");

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

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

P.S. Спасибо Шортикам за веселый контент для примеров.

За последние 24 часа нас посетили 10074 программиста и 928 роботов. Сейчас ищут 557 программистов …

Проблема с кодировкой. Вместо русских букв кракозябры.

Тема в разделе «MySQL», создана пользователем Sergey89, 30 янв 2008.

Страница 1 из 3


  1. Sergey89

    Sergey89
    Активный пользователь

    С нами с:
    4 янв 2007
    Сообщения:
    4.796
    Симпатии:
    0

    Данная «проблема» ждёт пользователей MySQL версии 4.1 и выше, которые никогда не пытались читать документацию.

    Первым делом нужно проверить, что установлено нужное сопоставление (collation) для текстовых полей в таблице. Именно в установленной кодировке хранятся данные. Если для полей выставлена «неправильная» кодировка, то измените её. В phpMyAdmin это можно сделать при редактировании столбца таблицы, выбрав нужное значение из списка Сравнений. Для русский символов это может быть, например, cp1251_general_ci (основная регистронезависимая cp1251). Для UTF-8 — utf8_general_ci.

    Теперь нужно выставить кодировку соединения с сервером. В MySQL есть выражение SET NAMES, предназначенное специально для этого:
    [sql]SET NAMES ‘cp1251’;[/sql]
    Выполнить данный запрос нужно сразу после подключения к серверу.

    После этого все данные будут приходить в установленной кодировке. Кодировку соединения можно менять:
    [sql]SET NAMES ‘utf8’;[/sql]
    В этом случае данные будут приходить в UTF-8, никак не затрагивая данные в таблице, которые могут храниться в другой кодировке. Следите за тем, чтобы весь остальной текст на странице тоже был в UTF-8.

    Вопросы? Замечания?


  2. M@rko

    M@rko
    Активный пользователь

    С нами с:
    21 янв 2008
    Сообщения:
    5
    Симпатии:
    0

    пробовал.
    все равно ведает кроказяблы! хоть и другие…


  3. Sergey89

    Sergey89
    Активный пользователь

    С нами с:
    4 янв 2007
    Сообщения:
    4.796
    Симпатии:
    0

    Предлагаешь мне погадать? В какой кодировке таблица, в какой кодировке страница? Юзер рутовый или нет?


  4. Elkaz

    Команда форума
    Модератор

    Добавлю к сообщения Сергея:
    Сегодня была фигня, что русский текст показывался корректно (utf8 и в БД и на странице), но буквы «ш» и «И» показываются в виде квадратиков (в IE) и другими крякозябрами в других браузерах. Погуглив, решил проблему так:

    На БД и таблицы установил utf8_general_ci
    После коннекта к БД:
    [sql]
    mysql_query(«SET NAMES ‘utf8’;»);
    mysql_query(«SET CHARACTER SET ‘utf8’;»);
    mysql_query(«SET SESSION collation_connection = ‘utf8_general_ci’;»);
    [/sql]

    И все нормально работает.


  5. tmanager

    tmanager
    Активный пользователь

    С нами с:
    12 мар 2008
    Сообщения:
    108
    Симпатии:
    0

    Стоит добавить, как поддержка кодировки уcтанавливается на MySQL под Windows

    Пример конфигурационного файла my.ini

    [client]
    port = 3306

    #Конфигурационные параметры для сервера MySQL
    [mysqld]
    port = 3306
    socket = /tmp/mysql.sock
    skip-locking
    key_buffer = 16K
    max_allowed_packet = 1M
    table_cache = 4
    sort_buffer_size = 64K
    read_buffer_size = 256K
    read_rnd_buffer_size = 256K
    net_buffer_length = 2K
    thread_stack = 64K
    # Установка кириллицы на сервере
    default-character-set=cp1251 #Указание кодировки
    character-sets-dir=g:/mysql/share/charsets #Указание пути к папке кодировок (скорректируйте для своего сервера!)

    server-id = 1

    # Конфигурационные параметры для программы резервного копирования
    [mysqldump]
    quick
    max_allowed_packet = 16M
    # Установка кириллицы
    default-character-set=cp1251 #Указание кодировки
    character-sets-dir=g:/mysql/share/charsets #Указание пути к папке кодировок (скорректируйте для своего сервера!)

    # Конфигурационные параметры для программы-клиента mysql.exe
    [mysql]
    no-auto-rehash
    # Установка кириллицы
    default-character-set=cp1251 #Указание кодировки
    character-sets-dir=g:/mysql/share/charsets #Указание пути к папке кодировок (скорректируйте для своего сервера!)

    [isamchk]
    key_buffer = 8M
    sort_buffer_size = 8M

    [myisamchk]
    key_buffer = 8M
    sort_buffer_size = 8M

    [mysqlhotcopy]
    interactive-timeout


  6. Astoret

    Astoret
    Активный пользователь

    С нами с:
    28 фев 2008
    Сообщения:
    9
    Симпатии:
    0

    Спасибо Sergey89, очень помог твой пост. Двое суток бился, иска))

  7. Astoret
    Вот этот?

    :)


  8. Astoret

    Astoret
    Активный пользователь

    С нами с:
    28 фев 2008
    Сообщения:
    9
    Симпатии:
    0


  9. EugeneTM

    EugeneTM
    Активный пользователь

    С нами с:
    19 апр 2008
    Сообщения:
    85
    Симпатии:
    0

    Возможно окончательная победа в войне с utf8

    MySQL
    my.cnf или под виндой my.ini:

    [client]

    default-character-set= utf8

    [mysql]

    default-character-set=utf8

    [mysqld]

    default-character-set=utf8

    В PHP-скрипте
    <?php
    /* create a connection object which is not connected */
    $link = mysqli_init();
    /* connect to server */
    mysqli_real_connect($link, ‘localhost’, ‘root’, ‘бла-бла-бла’, ‘бла’);

    /* check connection */
    if (mysqli_connect_errno()) {
    printf(«Ошибка соединения с БД : %sn», mysqli_connect_error());
    exit();
    }

    /* Устанавливаем кодировку для корректного вывода в браузере */
    $query = «SET NAMES ‘utf8′»;
    if (mysqli_query($link,$query) === TRUE) {
    printf(«Кодировка UTF8 успешно установлена.n»);
    }
    else {
    printf(«Ошибка выполнения запроса на установку кодировки UTF8 для вывода в браузере : %sn»,
    mysqli_error($link));
    exit ();
    }

    /* Устанавливаем кодировку для корректного collation*/
    $query = «SET SESSION collation_connection = ‘utf8_general_ci’;»);
    if (mysqli_query($link,$query) === TRUE) {
    printf(«Collation UTF8 успешно установлен.n»);
    }
    else {
    printf(«Ошибка выполнения запроса на установку collation UTF8 : %sn»,
    mysqli_error($link));
    exit ();
    }

    /* close connection */
    mysqli_close($link);
    ?>
    Если используете библитеку mysql, соотвтственно подкорректировать вызываемые функции.

    !!!!! Сам PHP-скрипт должен быть в кодировке UTF8

    !!!!! Скрипты MySQL должны быть в кодировке UTF8. Для танкистов: Если в notepad создать текстовый файл, набить какой нибудь код. Этот файл будет иметь кодировку cp1251. Если он будет содержать русские символы, то при попытке выполнить его из под mysql будете посланы на ERROR. Один из примитивных вариантов: в MySQL Query Browser создайте новый Script Tab. В него из Clipboard’а вставте ваш текст. Сохраните его как superpuper.SQL, сравните размер с исходным текстовым файлом. Этот скрипт будет нормально выполняться из под mysql при наличии в нем русских символов. Аналогично проверьте PHP-скрипт.

    !!!!! Вставка из clipboarda винды в командную строку mysql катит только если текст не содержит русских символов. Винда вставляет cp1251, и соответственноо mysql посылает на ERROR.

    Если все это выполнено, нигде никаких упоминаний про cp1251 не нужно.

    PS. Имейте в виду — размер VARCHAR при использовании utf8 не должен превышать 64К/3 = 21,33К

  10. Не думал, что после того чего уже пережил — напишу сюда, но :)
    Винда, кодировки в базах — юникод, на страничках — utf8, то же и скрипты.
    Не пугайтесь, со страничками все хорошо, везде все по русски. Но, решил сегодня воспользоваться консолью мускуловской, не тут то было: ╨Э╨░╤З╨░╤В╨░ вот такие бяки. И сет намес ставил..
    Мне кажется что просто сама консоль 1251 по этому и такие карявости. Я не прав? в любом случае, как это победить, или лучше не париться и юзать как раньше майадмин?


  11. Sergey89

    Sergey89
    Активный пользователь

    С нами с:
    4 янв 2007
    Сообщения:
    4.796
    Симпатии:
    0

  12. У меня программа, в которой я php-код редактирую, иногда возмёт да и сохранит файл в однобайтовой кодировке.
    Она это может делать автоматически, если все символы в документе принадлежат одной однобайтовой кодировке и нет ни одного символа из другой.

    Чтобы быть уверенным, вставляю в начало документа комментарий: #юертз ěščřž
    Т.е. набор из символов, которые могут быть одновременно только в многобайтовой кодировке.

    В notpade тоже можно сохранить в utf-8, если при сохранении в окне её выбрать.

  13. Помогите мне пожалуйста…. :_(

    Пользуюсь консольным клиентом.
    Я создал БД:[sql]CREATE DATABASE admins DEFAULT CHARACTER SET cp1251 COLLATE cp1251_general_ci[/sql]
    Создал таблицу, внес в нее данные и между каждым действием писал[sql] set names c1251;[/sql]
    На самой странице написал:

    1. <meta http-equiv=Content-Type content=«text/html; charset=windows-1251» />

    И всеравно пишутся каракули *WALL*


  14. Anonymous

    тоже из консоли?
    У консоли кодировка cp866


  15. Luge

    С нами с:
    2 фев 2007
    Сообщения:
    4.680
    Симпатии:
    1
    Адрес:
    Минск

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

    LokiFC
    set names c1251; достаточно 1 раз прописать. После соединения с бд.
    И вполене возможно, что данные твои пишутся нормально. Попробуй отсешь другие варианты.
    В какой кодировке сохранён сам файл? Сомневаюсь, что utf-8, но а вдруг?
    Потом, в апаче есть такая директива, как AddDefaultCharset. Отвечает за кодировку в которой по умолчанию будут отдаваться серваком файлы. И если стоит utf-8 или другая отличная от WINDOWS-1251, то чихал он на

    1. <meta http-equiv=Content-Type content=«text/html; charset=windows-1251» />

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

    1. <? header(‘Content-Type: text/html; charset=CP1251’); ?>

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


  16. Sergey89

    Sergey89
    Активный пользователь

    С нами с:
    4 янв 2007
    Сообщения:
    4.796
    Симпатии:
    0

    Набери в консоли или обрати внимание на то, что

  17. 2Luge, помогло :D
    Не думал, что проблема может заключатся в неправильном способе задачи кодировке странице…
    …а это было так….


  18. Madkin

    Madkin
    Активный пользователь

    С нами с:
    23 янв 2008
    Сообщения:
    18
    Симпатии:
    0

    Доброго времени суток!

    Мужики, что я делаю не так?

    Ситуевина следующая:
    1. База, таблица, записи в кодировке cp1251
    2. Страница в кодировке cp1251
    3. На странице даже вставлен mysql_query(«SET NAMES ‘cp1251′»);

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


  19. Kreker

    С нами с:
    8 апр 2007
    Сообщения:
    5.433
    Симпатии:
    0

    Может сервер высылает заголовок http в другой кодировке?
    Попробуйте header(«Content-type: text/html; charset=windows-1251»);


  20. Madkin

    Madkin
    Активный пользователь

    С нами с:
    23 янв 2008
    Сообщения:
    18
    Симпатии:
    0

    Ну я так понимаю, что изменив в апаче AddDefaultCharset UTF-8 на CP-1251, я вроде бы как сделал тоже самое.

    К сожалению проблема осталась (((.

    Есть ли смысл дефолтовой кодировкой мускуля сделать CP-1251? Сейчас в мускуле повсюду юникод — созданное мной как белая ворона в виндовой кодировке лежит.


  21. Madkin

    Madkin
    Активный пользователь

    С нами с:
    23 янв 2008
    Сообщения:
    18
    Симпатии:
    0

    Еще раз, здравствуйте!
    Продолжаю мучение:
    Выставил дефолтовую кодировку для mysql в cp1251 — результат от же ((((
    Может кто-нить подбросит совет? вот что имею:
    1. Апаче раздает страницы с параметром AddDefaultCharset CP-1251
    2. Мускуль в настройках my.cnf раздел [mysqld] (может тут беда?) имеет 2 параметра
    — collation_server = cp1251_general_ci
    — character_set_server = cp1251
    3. База, таблицы в базе, записи в таблицах в в cp12-51_general_ci
    4. Страница в windows-1251
    5. Страница имеет mysql_query(«SET NAMES ‘cp1251′»);

    Со всем этим у меня трабла — все что вытягивается из мускуля — на странице превращается в знаки вопроса.

    УПД.
    Загугли решают )) Правильно поставленный поисковый вопрос — 80% сделано
    Добавил следующее после коннекта с базой — заработало

    1. mysql_query («set collation_connection=’cp1251_general_ci'»);

    Спамибо ответившим.


  22. ZMANZ

    ZMANZ
    Активный пользователь

    С нами с:
    10 мар 2008
    Сообщения:
    161
    Симпатии:
    0

    Здраствуйте!!!
    При добавлении информации через блок администратора в базу данных mysql, в базе данных информация отображается иероглифами, но только когда печатаешь русскими буквами!!! При отправке формы английскими или цифрами приходит все нормально!!! Страница с которой происходит отправка имеет кодировку utf8!!! phpMyAdmin 2.6.1, MySQL 4.1.16, Appach 1.3.33 Php 5.1.2!!!
    Где и что нужно поменять, чтоб небыло этих иероглифов??? Как я понял идет именно несовместимость кодировок страница в utf8, а mysql 1251!!! А так все отображаеца нормально, проблема именно при поступлении данных в базу, приходят ИЕРОГЛИФЫ!!!


  23. Luge

    С нами с:
    2 фев 2007
    Сообщения:
    4.680
    Симпатии:
    1
    Адрес:
    Минск

    привычку не читать первое же сообщение в теме.

Страница 1 из 3

Битые символы в базе данных образуются, в большинстве случаев, из-за несовпадения кодировок в файле источнике, клиенте БД или таблице БД. Пройдемся по проблемным местам, один из пунктов ниже обычно помогает решать проблемы с «кракозябрями».

1. Файл-источник данных.

С этим пунктом все просто, текстовые данные в файле нужно хранить в utf8. Проверить кодировку можно в большинстве популярных IDE, например, в PhpStorm или текстовом редакторе наподобие Notepad++.

Если нет прямого доступа к БД, то в файл-источник данных следует прописать:

SET NAMES 'utf8' COLLATE 'utf8_general_ci'; -- Для utf8

или

SET NAMES 'utf8mb4' COLLATE 'utf8mb4_general_ci'; -- Для utf8mb4

2. Кодировка и формат сопоставления данных в таблице.

Вероятнее всего вы используете utf8 (он же utf8mb3) или utf8mb4 для хранения данных в MySql. Поэтому при создании таблиц желательно напрямую указывать это, т.к. не всегда общие настройки БД разрешается менять.

Для utf8:

CREATE TABLE `example_table`
(
    id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    example_field VARCHAR(255) NOT NULL
) CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE=InnoDB;

Для utf8mb4:

CREATE TABLE `example_table`
(
    id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    example_field VARCHAR(255) NOT NULL
) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci ENGINE=InnoDB;

3. Импорт данных из файла-источника.

При импорте тоже желательно указывать кодировку.

Для utf8:

mysql -u USER_NAME -p --default-character-set=utf8 DB_NAME < SOURCE_FILE.sql

Для utf8mb4:

mysql -u USER_NAME -p --default-character-set=utf8mb4 DB_NAME < SOURCE_FILE.sql

4. Веб-интерфейсы.

Иногда требуется заполнять БД из веб-интерфейсов и в этом случае стоит проверять отправляемую кодировку с сервера в заголовках и HTML-коде.

HTML:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

PHP:

header('Content-Type: text/html; charset=utf-8');

Полезные команды

Отображение форматов сопоставления данных в MySql:

SHOW VARIABLES LIKE 'collation%';

Отображение настроек кодировок:

SHOW VARIABLES LIKE 'character%';

Your answer is you can configure by MySql Settings. In My Answer may be something gone out of context but this is also know is help for you.
how to configure Character Set and Collation.

For applications that store data using the default MySQL character set
and collation (latin1, latin1_swedish_ci), no special configuration
should be needed. If applications require data storage using a
different character set or collation, you can configure character set
information several ways:

  • Specify character settings per database. For example, applications
    that use one database might require utf8, whereas applications that
    use another database might require sjis.
  • Specify character settings at server startup. This causes the server
    to use the given settings for all applications that do not make other
    arrangements.
  • Specify character settings at configuration time, if you build MySQL
    from source. This causes the server to use the given settings for all
    applications, without having to specify them at server startup.

The examples shown here for your question to set utf8 character set , here also set collation for more helpful(utf8_general_ci collation`).

Specify character settings per database

  CREATE DATABASE new_db
  DEFAULT CHARACTER SET utf8
  DEFAULT COLLATE utf8_general_ci;

Specify character settings at server startup

[mysqld]
character-set-server=utf8
collation-server=utf8_general_ci

Specify character settings at MySQL configuration time

shell> cmake . -DDEFAULT_CHARSET=utf8 
           -DDEFAULT_COLLATION=utf8_general_ci

To see the values of the character set and collation system variables that apply to your connection, use these statements:

SHOW VARIABLES LIKE 'character_set%';
SHOW VARIABLES LIKE 'collation%';

This May be lengthy answer but there is all way, you can use. Hopeful my answer is helpful for you. for more information http://dev.mysql.com/doc/refman/5.7/en/charset-applications.html

Автор: Fix Xxer (PHP Club)

У MySQL версии 4.1 и выше (далее 4.1+) с русскими буквами бывают несколько проблем — рассмотрим их по отдельности.

1. PHP использует неверную кодировку в качестве клиентской.

Симптомы:

  • Через phpMyAdmin (здесь и далее подразумевается версия умеющая работать с кодировками, т.е. >= 2.6.0) все по-русски, а в скрипт приходят вопросительные знаки.
  • Скрипт, заносящий данные в базу, видит русский нормально, а после вставки, как в правильном скрипте, так и в phpMyAdmin-е — знаки вопросов.

Тестирование:
Попробуйте в начале вашего скрипта, но после соединения, выполнить SQL-запрос «SET NAMES кодировка». Где кодировка — та кодировка, в которой у вас (по вашему мнению) данные. Например, для русской Windows кодировки (windows-1251) это будет cp1251, для KOI8-R – koi8r, для UTF-8 – utf8 и так далее. В дальнейшем она будет упоминаться как «кодировка».

Результат тестирования:

  • Если буквы (но необязательно слова) стали русскими, значит, данные в базе лежат в правильной кодировке, сама база эту самую кодировку и использует.
  • Если буквы стали русскими, а слова нет («бнопня»), значит, скрипт ожидает данные в другой русской кодировке — пробуйте другие, пока не получится русских слов.

Решение:
1) Оставить запрос «SET NAMES кодировка» в начале скрипта. Если скриптов много – см. вариант 2.

2) Заставить MySQL автоматически выполнять этот запрос при каждом соединении с ним.
Для этого необходимо в конфигурационном файле MySQL, в секции [mysqld] добавить следующую строку: init-connect=»SET NAMES кодировка».

Однако, следует заметить, что это НЕ будет работать, если пользователь, которым вы подключаетесь к базе имеет привилегию SUPER (а стандартный пользователь root к таким относится, так же как и все созданные через «GRANT ALL PRIVILEGES ON *.* TO …»). Это сделано для того, чтобы в случае ошибки в этом запросе (а его можно изменить во время работы), хоть кто-то мог подключиться к базе и исправить его.

Внимание! Функция mysqli_client_encoding() и сотоварищи, отображает кодировку клиента на момент соединения и не меняют возвращаемое значение в процессе работы. Поэтому не стоит кричать, что кодировка не меняется. Просто делайте, что говорят и смотрите результат работы скрипта. Получить нужное значение можно SQL-запросом «SHOW VARIABLES LIKE ‘character_set_client'».

3) Начиная с версий 4.1.15 и 5.0.13 добавить в секцию [mysqld] или [server] конфигурационного файла MySQL параметр skip-character-set-client-handshake. Этот параметр заставляет сервер игнорировать кодировку, посылаемую клиентом, и использовать указанную серверу. В примере конфигурации ниже этот параметр уже есть.

2. MySQL использует неверную кодировку

Симптомы:
Русский текст приходит в скрипт как русский, в консольном клиенте тоже все хорошо. Однако не работает сортировка, перевод в верхний/нижний регистр и т.д. Если применить решение из проблемы №1, то либо русский текст становится вопросами, либо mysql_error() возвращает сообщение похожее на «Illegal mix of collations (latin1_general_ci,IMPLICIT) and (cp1251_general_ci,COERCIBLE)…». В тоже время phpMyAdmin русский текст отображает как «крокозябры» (латинские символы с умляутами и т.д.).

Тестирование:
Попробуйте в phpMyAdmin’е выполнить запрос вида «SELECT CONVERT(CONVERT(поле USING binary) USING кодировка) FROM таблица». Где «таблица» и «поле» — соответствующая таблица и поле с русским текстом, а «кодировка» — кодировка из проблемы №1.

Результат тестирования:

  • Если буквы (но необязательно слова) стали русскими, значит текст в базе лежал не в правильной кодировке и его нужно сконвертировать.
  • Если буквы стали русскими, а слова нет («бнопня»), значит неверно выбрана одна из русских кодировок – пробуйте другие, пока не получится русских слов.

Решение:
1) Установить для MySQL нужную кодировку по умолчанию.

Внимание! Это решение сработает сработает, только если кодировки не переопределены для базы, таблицы или столбца.
Для этого нужно в конфигурационном файле MySQL в секции [mysqld] добавить следующую строку:
default-character-set=cp1251

2) Сконвертировать таблицы в нужную кодировку.
Про то как конвертировать таблицы с неверными кодировками хорошо написано в мануале MySQL. Повторять здесь то же самое не к чему.

Дополнительно:

Наша справка:

Конфигурационный файл MySQL — применяется для записи и хранения параметров программ MySQL, что исключает необходимость ввода этих параметров в командной строке при каждом вызове программы. Все определенные в конфигурационном файле параметры могут перекрываться параметрами, заданными в командной строке. В ОС UNIX в качестве конфигурационного файла используется my.cnf, в ОС Windows используется my.ini. Найти конфигурационный файл можно в корневой директории MySQL (см. местоположение конфигурационного файла MySQL). Внутри конфигурационных файлов параметры распределены по группам. Например:

[client]
user=sampadm
password=secret

[mysqld]
port = 3306
socket = /tmp/mysql.sock
Названия групп заключаются в квадратные скобки и обычно соответствуют именам программ. Так, например, группа [mysqld] (в ранних версиях mysql — [server]) соответствует программе mysqld, являющейся сервером MySQL, который обеспечивает клиентским программам доступ к базам данных.


0

2

В консоли MySQL не пишется кириллица, в ответе на запрос отображается, в терминале пишется и отображается нормально.

 locale
LANG=ru_RU.UTF-8
LANGUAGE=
LC_CTYPE="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES="ru_RU.UTF-8"
LC_PAPER="ru_RU.UTF-8"
LC_NAME="ru_RU.UTF-8"
LC_ADDRESS="ru_RU.UTF-8"
LC_TELEPHONE="ru_RU.UTF-8"
LC_MEASUREMENT="ru_RU.UTF-8"
LC_IDENTIFICATION="ru_RU.UTF-8"
LC_ALL=
***********************************************
в Mysql
SHOW VARIABLES LIKE 'char%';
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | utf8                       |
| character_set_connection | utf8                       |
| character_set_database   | utf8                       |
| character_set_filesystem | binary                     |
| character_set_results    | utf8                       |
| character_set_server     | utf8                       |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.00 sec)

 SHOW VARIABLES LIKE 'collation%';
+----------------------+-----------------+
| Variable_name        | Value           |
+----------------------+-----------------+
| collation_connection | utf8_general_ci |
| collation_database   | utf8_general_ci |
| collation_server     | utf8_general_ci |
+----------------------+-----------------+
3 rows in set (0.01 sec)

Пробовал вручную

SET NAMES 'utf8';
SET CHARACTER SET 'utf8';
SET SESSION collation_connection = 'utf8_general_ci';

в результате запроса отображается

ков С.           | 5      | 051051    | 2022-11-26 02:25:32 |         5 | NULL   | NULL  | NULL      | 08ПС    

но запрос написать не могу типа:

select * from tab where name like 'Иванов';

Всем доброго времени суток!
Отчаялся искать в интернете ответ, поэтому пишу здесь)
Итак,
Создана utf8 таблица в бд:
require_once $_SERVER[‘DOCUMENT_ROOT’].»/php/mysql_connect_private.php»;
@mysql_connect_private();

$string = «CREATE TABLE `users` (`user_id` int(9) unsigned not null auto_increment,
`email` VARCHAR(50),
`password` VARCHAR(40),
`name` VARCHAR(30),
`surname` VARCHAR(40),
`avatar` VARCHAR(50),
PRIMARY KEY (`user_id`)) ENGINE=MyISAM CHARACTER SET=utf8″;
mysql_query($string) or die(mysql_error());
mysql_query(«ALTER TABLE `users` ADD INDEX (`user_id`)») or die(mysql_error());
mysql_query(«ALTER TABLE `users` ADD INDEX (`email`)») or die(mysql_error());

В таблицу делаем инъекцию при регистрации пользователя:
$string = «INSERT INTO `users` (`user_id`, `email`, `password`, `name`, `surname`) VALUES (‘0’, «;
$string .= «‘».mysql_real_escape_string($_REQUEST[’email’]).»‘, «;
$string .= «‘».mysql_real_escape_string(md5($_REQUEST[‘password’])).»‘, «;
$string .= «‘».mysql_real_escape_string($_REQUEST[‘name’]).»‘, «;
$string .= «‘».mysql_real_escape_string($_REQUEST[‘surname’]).»‘)»;
echo $string;
mysql_query($string) or die(mysql_error());

Выдает:
INSERT INTO `users` (`user_id`, `email`, `password`, `name`, `surname`) VALUES (‘0’, ‘[email protected]‘, ‘098f6bcd4621d373cade4e832627b4f6’, ‘Mihail’, ‘Баженов’)

— Проверял и русский и английский языки.

В итоге в БД фамилия на русском языке не заносится — пусто.
Если вручную через phpmyadmin заношу фамилию, то все нормально.
В итоге, что делать?) Понимаю, что ответ, скорее всего, прост, но уже убил час на поиск решения и тщетно.
Кстати, комментарии по правильному оформлению тоже приветствуются) Может что не так написано с точки черния защиты/правильно оформления. Спасибо!

П.С. Подключение к базе:

function mysql_connect_private()
{
$addr = «localhost»;
$user = «____»;
$pass = «____»;
$db = «____»;
// MySQl
$abc = mysql_connect($addr, $user, $pass)
or die(» MySQL: «.mysql_error());
//
@mysql_query(‘CREATE DATABASE $db’);
//
mysql_select_db($db)
or die(» $db: «.mysql_error());
mysql_query(«SET NAMES ‘utf8′»);
mysql_query («set character_set_client=’utf8′»);
mysql_query («set character_set_connection=’utf8′»);
mysql_query («set character_set_results=’utf8′»);
mysql_query («set character_set_database=’utf8′»);
mysql_query («set collation_connection=’utf8_bin'»);
}

П.П.С.
Отображается при вытаскивании из базы вручную внесенная фамилия на русском тоже иероглифами…

Также, в процессе передачи данных к скриптам везде проверил работающую с mysql кодировку:
$z = mysql_fetch_array(mysql_query(«SHOW VARIABLES LIKE ‘character_set_database'»));
print_r($z);
Пишет везде, что utf8

Пробовал везде прописать
<meta http-equiv=»Content-Type» content=»text/html»; charset=»utf8″>

Тоже не помогает.

MySQL кодировки

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

Кодировка, в которой хранятся данные на сервере MySQL, должна совпадать с кодировкой самих данных. Например, для русских символов используется кодировка cp1251. Если в таблице будут храниться записи русскими буквами, то и кодировка этой таблицы должна быть задана cp1251, иначе отображаться будут не русские символы, а знаки вопроса или другие знаки.

При создании баз данных сразу указывайте кодировку для хранения символов, поскольку в случае отсутствия явно заданной кодировки будет использовано значение по умолчанию (latin1). Например, создавайте базу данных командой:

create database `my-db` default charset cp1251;

Кодировка соединения сервера с клиентом устанавливает, в каком виде будут передаваться данные между ними. Например, если в скрипте на сайте используются русские символы, то при обращении сайта к базе данных MySQL должен правильно распознать эти символы, чтобы корректно выполнить скрипт. Если кодировка соединения использует значение по умолчанию latin1, то русские символы сервер баз данных не сможет правильно распознать, следовательно, скрипт выполнится с ошибкой.

Установите нужную вам кодировку соединения сразу после подключения к серверу MySQL запросом:

set names cp1251

Существует ряд клиентов, которые не могут установить нужную кодировку, имеют свою собственную. Для подобных случаев внесите в файл my.cnf в секцию [mysqld] строку:

set init_connect="set names cp1251"

где cp1251 – это нужная вам кодировка.

В этом случае сервер выполнит команду «set names cp1251» сразу после соединения с клиентом и установит указанную в запросе кодировку.

Самые распространенные в России кодировки следующие:

utf8, cp866 (DOS), cp1251 (Windows), koi8r

Установка и использование на всех уровнях сервера баз данных одинаковой кодировки устраняет 90% проблем с кодировкой в MySQL.

Как русифицировать MySQL?

Внесите следующие изменения в файл my.cnf:

[client]

default-character-set=cp1251

[mysqld]

character-set-server=cp1251

collation-server=cp1251_general_ci

init-connect = "set names cp1251"

Перезапустите MySQL сервер.

Понравилась статья? Поделить с друзьями:
  • Mysql ошибка 267
  • Mysql ошибка 233
  • Mysql ошибка 2054
  • Mysql ошибка 2003
  • Mysql ошибка 1698