При выполнении запроса к бд возникли проблемы с кодировкой как их исправить

Время на прочтение
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. Спасибо Шортикам за веселый контент для примеров.

Почему в базе неправильное отображение через phpMyAdmin также через консоль, сплошная крякозябрина.

Потому что в таблицах лежат данные в utf8, в то время как в определении таблиц стоит умолчательное latin1. Убедиться в этом можно, введя команду

SHOW CREATE TABLE MyGuests;

Когда phpMyAdmin пытается рабтать правильно, запрашивая у БД данные в той кодировке, в которой собрался их выводить, БД пытается перекодировать русский текст из latin1 в utf8, и мы получаем ДениÑ.

Неправильное решение со skip-character-set-client-handshake выдает данные как есть, не перекодируя их. Но это, разумеется, кривой костыль. При первой же попытке поискть данные или отсортировать их, результаты ОЧЕНЬ сильно удивят.

Необходимо выставить таблицам адекватную кодировку. Если БД еще не живая, то удалить таблицы, задать дефолтную кодировку для database,

ALTER DATABASE aliendatabase CHARACTER SET utf8;

создать таблицы заново и начать работу с чистого листа. Просто «в лоб» поменять кодировку, сделать alter table не получится — после этой команды mysql добросовестно перекодирует лежащие данные в вид ДениÑ, точно так же, как она сейчас это делает при выдаче, но уже насовсем.

Если база «живая», можно воспользоваться инструкцией, но перед этим обязательно сделать бэкап.

Проблема возникает, если вы работаете с кодировкой, отличной от UTF-8, и храните в базе данных тексты, к примеру, в кодировке cp1251. Но MySql не всегда использует по умолчанию кодировку cp1251, в частности, не всегда по умолчанию используется эта кодировка для соединений с базой. Из-за этого возникают ситуации, когда в базе тексты хранятся в нормальном читабельном виде, но при выводе этих данных на сайт появляются одни лишь «кракозяблы» (знаки вопросов вместо букв – «?????????? ????»).

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

mysql_query("SET NAMES 'cp1251'");
mysql_query("SET CHARACTER SET 'cp1251'");

Обновлено: Количество запросов уменьшено благодаря прояснению ситуации Бирц`ом (см. комментарии).

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

На серверах, которые предоставляют услуги хостинга для русскоязычных сайтов, чаще всего все в порядке и такой проблемы нет (т.к. у них по умолчанию MySql настроен на работу в первую очередь с кодировкой cp1251). Если ваш сайт использует иностранный хостинг, то, скорее всего, единственным способом решения проблемы будет способ, описанный выше.

Но если же вы имеете возможность подкорректировать конфиг MySql на сервере, тогда есть еще одно решение, реализацию которого я с радостью для себя обнаружил (я-то «догадывался», что можно как-то изменить настройки самого MySql, но как это сделать, не знал) 🙂

MySQL и русская кодировка WINDOWS-1251

Сегодня мы рассмотрим, что нужно написать в конфигурационном файле /etc/my.cnf для того, чтобы настроить mysql стандартной сборки на работу с кодировкой cp1251 по умолчанию без всякой перекомпиляции.

Рассмотрим пример конфига на основе MySQL 5.x.

В раздел [mysqld] необходимо добавить следующее:

default-character-set=cp1251
character-set-server=cp1251
collation-server=cp1251_general_ci
init-connect=»SET NAMES cp1251″
skip-character-set-client-handshake

Две последние строки принудительно устанавливают кодировку cp1251 для всех запросов.

В раздел [mysqldump] достаточно добавить только

default-character-set=cp1251

Этого достаточно, чтобы MySQL работал с windows-1251 кодировкой по умолчанию.

(с) dodik.ru

Теперь я могу использовать свой локальный сервер на XAMPP (ну не нравится мне Денвер…) более комфортно 🙂 Также это прекрасно сработало на «самодельном» сервере под SUSE.

Проблемы с кодировкой в базе данных

Проблемы с кодировкой в базе данных

Не так давно я делал один сайт, и мне необходимо было сделать кодировку в базе данных UTF-8. Так я и сделал. Далее я поставил кодировку на сайте UTF-8. Всё казалось бы нормально, но при выборке данных из базы, они шли не в UTF-8, а в windows-1251. Разумеется, всё было в иероглифах. Я подумал, что решение этой проблемы с кодировкой в базе данных, необходимо Вам знать. И как раз об этом чуть ниже.

Если Вы используется UTF-8, то сразу после подключения необходимо выполнить всего лишь один запрос, но который исправит эту ошибку на корню. Вот он:

SET NAMES "utf8"

Он необходим, поскольку по умолчанию данные идут в кодировке windows-1251. И если Вам нужна windows-1251, то можете ничего не писать. Но если Вы используете UTF-8 (а я рекомендую использовать всё-таки эту кодировку), то обязательно после подключения выполните этот несложный запрос. Тогда проблемы с кодировкой при выборке из базы данных отпадут.

  • Создано 13.07.2011 14:41:36


  • Михаил Русаков

Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!

Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.

Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления

Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.

Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):

  1. Кнопка:

    Она выглядит вот так: Как создать свой сайт

  2. Текстовая ссылка:

    Она выглядит вот так: Как создать свой сайт

  3. BB-код ссылки для форумов (например, можете поставить её в подписи):

За последние 24 часа нас посетили 11156 программистов и 893 робота. Сейчас ищет 701 программист …

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

Тема в разделе «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

Понравилась статья? Поделить с друзьями:
  • Как составить отчет по топливу
  • Как составить схему теодолитного хода
  • Как найти человека через чат рулетку
  • Как составить меню для выпускного
  • Как найти знакомых людей в инстаграме