Записки самоучки

Ноябрь 11, 2006

Изменение кодировки таблиц в MySQL

Filed under: MySQL — 4matic @ 12:17 дп

Начиная с версии 4.1 ,СУБД MySQL умеет работать с кодировками. Для многих работа с кодировками в MySQL — это большая проблема. Проблемы, связанные с кодировками неплохо освещены в Википедии на сайте http://phpclub.ru. Тем, кто плавает в вопросах кодировки я рекомендую посетить ресурс и читать статью до полного понимания. В основном в статье освещаются проблемы, связанные с настройкой связки PHP vs MySQL. Главное, что нужно запомнить, что кодировка содержимого БД и кодировка соединения должны совпадать. Ну, мы немного отклонились от темы.

Итак, все началось с того, что вы установили MySQL, создали таблицы, наполнили их данными, а потом обнаружили, что запросы к таблицам, в которых есть поиск или сортировка по полям типа CHAR, VARCHAR, TEXT выдают непредсказуемые результаты. Если это происходит, то, скорее всего, у вас некорректно указаны кодировки для данных. Попытаюсь объяснить, в чем проблема. Надеюсь, вы понимаете, что такое кодировка. Если нет, то прогугилите вопрос и получите хотя бы первичные знания.

Итак. Проследим, как получилось так, что у вас появились проблемы с кодировкой. MySQL при установке по умолчанию указывает кодировку для БД latin1. Большинство клиентов, при подключении, настроены на кодировку latin1. Вы, пользуясь клиентами, вносите данные, просматриваете результаты и т.д. При этом везде используете кодировку latin1. Эта кодировка позволяет корректно отображать кириллицу. На этом корректность в работе с кириллице в кодировке latin1 заканчивается. Cимволы вы видите правильные, но коды в таблице символов в данной кодировке не соответствуют реальным кириллическим символам. И получается, что поиск и сортировка выдают непредсказуемые результаты, потому что работа происходит не с символами, которые вы видите, а с кодами. Может, запутано объяснил, тогда ставлю перед фактом: кодировка latin1 — это некорректная кодировка для полноценной работы с криллицей. Для корректно работы с кириллицей нужно выбирать кодировки, которые поддерживают кириллицу. Для того, что бы узнать полный список этих кодировок RTFM по MySQL. Я же остановлюсь на двух распространённых из них: utf-8 и cp1251. Начну с cp1251, потому что это родная кодировка для ОС Windows.

Итак, перед нами стоит задача: конвертировать данные, из изначально некорректно заявленной кодировки latin1 в корректную кодировку cp1251. Идем в документацию по языку:

If you want to change the table default character set and all character columns (CHAR, VARCHAR, TEXT) to a new character set, use a statement like this:
ALTER TABLE tbl_name CONVERT TO CHARACTER SET charset_name; (1)

Не спешим выполнять предложенное решение, а читаем дальше:

Warning: The preceding operation converts column values between the character sets. This is not what you want if you have a column in one character set (like latin1) but the stored values actually use some other, incompatible character set (like cp1251). In this case, you have to do the following for each such column:
ALTER TABLE t1 CHANGE c1 c1 BLOB; (2)
ALTER TABLE t1 CHANGE c1 c1 TEXT CHARACTER SET cp1251; (3)

The reason this works is that there is no conversion when you convert to or from BLOB columns.

Простое конвертирование данных (1) нам не подходит, потому что у нас некорректные коды для символов, а так как конвертирование происходит согласно таблице кодов, то мы получим некорректный результат. Выход в данной ситуации — это избавиться от привязки символов к кодировке. Это делается путем преобразования данных и символьного типа в двоичные данные (2). Представьте, что кодировка — это маска, которая накладывается на двоичные данные. Т.е. сам порядок байтов не изменяется, а изменяется только маска, по которой выбираются коды для визуального формирования символов. Итак, запросом (2) вы избавились от маски, а запросом (3) вы применили новую маску. Повторюсь еще раз (грубо говоря): физически мы не изменили ни одного байта данных, мы изменили правило формирования символов! В итоге вы получаете следующее: сами данные как были корректными для кодировки cp1251, так они и остались, но теперь мы правильно указали кодировку cp1251.

После таких манипуляций жизнь вашей БД и выборок должна наладиться, потому что теперь все сходится и все на своих местах. Теперь, если вы захотите изменить кодировку таблицы и полей, то можете смело пользоваться запросом (1). Кстати, я сейчас думаю переходить с cp1251 на utf-8, но пока что не могу чётко озвучить, зачем мне это надо: кое-какие предпосылки есть, но ясного понимания пока что нет.

Замечания:

  1. Если вы конвертируете данные, из изначально некорректно заявленной кодировки latin1 в корректную кодировку cp1251. Нельзя просто взять и изменить кодировку для столбца, т.е. не выполнять запрос (2), а сразу выполнить запрос (3). Потому что выполнив сразу запрос (3) мы физически не перестроим маску, а просто изменим текущее значение маски. Если у вас нет проблем с несоответствием кодировок, и вам нужно просто поменять кодировку таблицы, то вам нужно всего-навсего выполнить запрос (1).
  2. Если вы конвертируете данные, из изначально некорректно заявленной кодировки latin1 в корректную кодировку cp1251. При этом вы изменяете кодировку у поля, у которого есть индексы, то перестройте индексы (удалите и создайте заново).
  3. Если вы решите переходить на кодировку utf-8 — проверьте, что бы визуальные клиенты поддерживали unicode. Например, так горячо мною любимый SQLyog 5.2 курит бамбук при отображении содержимого таблиц, хранящих данные в utf-8.
  4. MySQL начал поддерживать unicode только с версии 4.1.x, т.е. до этого поддержки юникода не было. Это значит, если вы захотите перенсти таблицы с юникодом на версию младше 4.1.x, то у вас ничего не получится. Выходов два: или конвертировать данные из юникода во что-то менее многобайтовое, например, cp1251; или обновлять СУБД до версии не младше 4.1.x. Обновление СУБД предпочитетльней, потому что у MySQL уже 3ка по-моему не поддерживается и 4ка тоже скоро перестанет поддерживаться, при этом активно 5ка в двух ветках разрабатывается. Да и весь мир в юникоде активно в сети работает.

42 комментария »

  1. […] Изменение кодировки таблиц в MySQL « Записки самоучки Рекомендуется для прочтения всем кто столкнулся с “вопросиками” после переезда на новую версию MySQL или после смены хостинга. Кстати проблем (tags: mysql php кодировки руководство вебдев) […]

    Уведомление от Binary Look » links for 2006-11-18 — Ноябрь 19, 2006 @ 1:18 дп

  2. […] Изменение кодировки таблиц в MySQL « Записки самоучки (tags: webdev php mysql tipstrickshacks) […]

    Уведомление от links for 2006-11-20 « past is dead — Ноябрь 20, 2006 @ 5:18 дп

  3. «Главное, что нужно запомнить, что кодировка содержимого БД и кодировка соединения должны совпадать.»
    Не совсем так. Главное, чтобы клиент посылал данные в кодировке character_set_client (в несконфигурированной системе они различаются). А сервер уж у себя разберётся.

    комментарий от maXmo — Ноябрь 29, 2006 @ 3:18 пп

  4. […] Изменение кодировки таблиц в mysql […]

    Уведомление от Mysterya. Наша жизнь. » Blog Archive » Курим мануалы и ресурсы… — Ноябрь 29, 2006 @ 8:25 пп

  5. Вся жопа от того, что по умолчанию клиенты все работают как latin1.

    Предположим, что данные лежат в 1251 (реально), но в базе, которая считается как latin1 (то есть типа все работает, кроме сортировки, ибо в базе лежит некое шифрованное НЕЧТО, по нем и сортируется).

    Надобно сделать:
    mysqldump —default-character-set=latin1 > file.sql
    Теперь в файле лежат байтики «как было в БД», то бишь правильно.
    Создаем базу с utf8 (или 1251), в file.sql добавляем SET NAMES cp1251 (говорим, что кормить щас будем 1251 данные), везде где создаются таблицы latin1 меняем на cp1251 (если база в utf8, то на utf8). Запускаем, получаем правильную базу (если приконнектиться НЕ как latin1, конечно).
    Далее в /etc/my.cnf:
    [mysqld]
    init-connect=’SET NAMES cp1251′ (либо при каждом коннекте говорить то же самое ручками).
    и все будет работать замечательно, проверено и для utf8 тоже.

    комментарий от king2 — Январь 7, 2007 @ 12:21 дп

  6. Это отличное решение. Особенно когда много таблиц и много столбцов, в которых нужно менять кодировку. НО. Вариант с дампом может не пройти, когда у вас файл с дампом весит, ну скажем, около гига. Проблематично будет открывать и редактировать такой файл.
    Насчёт работы с кодировками. Я пользуюсь skip-character-set-client-handshake.

    комментарий от 4matic — Январь 9, 2007 @ 9:24 дп

  7. Вышла бета 6 SQLyog там с utf-8 насколько вижу все ок.

    комментарий от redic — Март 23, 2007 @ 9:35 пп

  8. Добрый день, вот такой вопрос, я так понимаю c1 c1 это colum1,а как сделать чтобы все колонки и строки таблицы сконвертировались ?

    комментарий от tester — Май 22, 2007 @ 12:25 дп

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

    комментарий от 4matic — Май 22, 2007 @ 9:32 дп

  10. > Проблематично будет открывать
    > и редактировать такой файл.
    > Comment by 4matic — January 9, 2007 @ 9:24 am

    создаем небольшой скрипт на perl (пусть будет lat2cp.pl)

    $latin = $ARGV0];
    open(LAT,»$latin»);
    while () {
    s/DEFAULT CHARACTER SET latin1/DEFAULT CHARACTER SET cp1251/g;

    s/DEFAULT CHARSET=latin1/DEFAULT CHARSET=cp1251/g;
    print $_;
    }

    делаем дамп в файл, далее
    ./lat2cp.pl >

    на выходе имеем дамп с подставленной кодировкой cp1251, что и требовалось. затраты ресурсов сервера минимальны

    комментарий от Дмитрий — Июнь 7, 2007 @ 1:08 пп

  11. Вот на одном из сайтов хостинга нашел решение. Сразу помогло.

    Какая кодировка MySQL установлена по умолчанию?
    По умолчанию установлена: cp1251_general_ci

    Если я импортирую данные в другой кодировке, например, latin1, что мне сделать что бы на сайте корректно выводилась кириллица?

    Вам нужно добавить запрос SET NAMES ‘latin1′ сразу после подключения к базе.

    $id = mysql_connect(’dbhost’, ‘dbuser’, ‘dbpasswd’);

    // Вставляем код сразу после mysql_connect:
    mysql_query(”SET NAMES ‘latin1′”, $id);

    База осталась в иероглифах, но на сайте все выводится нормально.

    комментарий от kript — Июнь 16, 2007 @ 12:11 пп

  12. База не осталась в иероглифах. В базе все хранится в кодировке latin1. latin1 — это некорректная кодировка для работы с русским языком. Рекомендую разобраться с кодировками, если это вам нужно в будущем, потому как на данный момент вы не понимаете, что и как работает.

    комментарий от 4matic — Июнь 17, 2007 @ 12:16 дп

  13. А что делать, если стоит мускул 3.23.58? У меня есть таблицы с полями, записи в которых на русском. На сайте отображается всё верно, но в исходном представлении хранятся иероглифы. Поэтому и сортировка не работает. Для того, чтобы исправить эту проблему обязательно ли переходить на новую версию мускула?

    комментарий от maximus — Июль 2, 2007 @ 3:56 пп

  14. Риспектище!

    комментарий от Antony C — Август 12, 2007 @ 4:25 пп

  15. Огромное человеческое спасибо! 8-D Статья действительно помогла, открыв глаза на докуметацию и дав идею: по-сути, collation в полях и таблицах не нужна. Заменил все на Binary. Только «MySQL connection collation» оставил в cp1251_general_cs(что, похоже, тоже особой роли не играет; главное, чтобы кириллица). И не нужно ничего в PHP-скрипте прописывать!

    комментарий от Astor — Август 25, 2007 @ 2:49 пп

  16. Для типа данных Binary, невозможно задать кодировку. Только для текстовых типов данных можно и нужно задавать кодировку и колейшн. Корректная работа с типом данных Binary, как текстовыми данными — это самообман.

    комментарий от 4matic — Август 25, 2007 @ 10:09 пп

  17. а что делать если, у меня бд в utf8, и мне так нужно и только одна таблица в latin1_swedish_ci, потому что с ней работает приложение («Вся жопа от того, что по умолчанию клиенты все работают как latin1.»), а на выводе данные мне нужно переконвертировать в utf8, и никак по другому, потому что в сайте прописаны и по другому тоже никак, и как быть, притом что таблица динамическая и постоянно поклоняющаяся

    комментарий от помогите — Ноябрь 21, 2007 @ 3:49 пп

  18. Извините, не нашел Ваших координат чтобы с Вами связаться. После 4 мучительных вечеров решения моей проблемы с кодировками нашел Вашу статью и понял вот ОНО! Все настолько, казалось бы имеет смысл, и объясняет мои прежние неудачные попытки… но НЕ ПОЛУЧАЕТСЯ у меня таки! Все пробовал. Все! Ничего не остается как биться головой об стену или писать Вам, многоуважаемый автор. Пожалуйста помогите. У меня нету больше никаких идей. Буду бесконечно благодарен если напишите мне на мой имэйл и я Вам пришлю все подробности. Спасибо. Миша.

    комментарий от Миша — Январь 18, 2008 @ 7:49 дп

  19. У меня были те же проблемы. Начал применять все эти скрипты, что тут приводятся, намучился, массу времени потратил, а ничего не заработало. Приведённые в статье скрипты вообще никакого эффекта не оказали.
    Тогда я просто после соединения с базой в PHP указал верную кодировку:
    $db_connect = @mysql_connect($db_host, $db_user, $db_pass);
    mysql_set_charset (‘utf8’,$db_connect);
    И всё заработало прекрасно, никакого cp1251 не нужно, utf8 работает прекрасно, да и теперь большинством MySQL оболочек можно пользоваться и не задумываться, какой там charset стоит.

    комментарий от Кир — Май 23, 2008 @ 10:11 дп

  20. А как быть когда скрипты пхп закодированы и нужно изменить кодировку соединения. На обчном хостинге.

    комментарий от Валерий — Май 30, 2008 @ 12:35 пп

  21. 2 Валерий. Раскодировать, подправить скрипты и залить обратно. На обычном хостинге нет возможности править файл my.ini для настроек СУБД, иначе бы можно было бы попробовать использовать параметр skip-character-set-client-handshake.
    2 Кир. Заметка был про конвертирование данных, а не о проблемах, возникающих при работе с кодировками.

    комментарий от 4matic — Май 30, 2008 @ 6:09 пп

  22. У меня стоит vBulletin.v3.6.8 вот думал попробовать перейти на Ipb скачал 2,3,4 попробовал конвертацию и после нее в IPB отображаються одни знаки вопроса, где было написанно на русском (???? ?? ??? ???????). Это как-то можно исправить? В админке кодировка форума стоит «win-1251». Где ещё нужно и что изменить? Сколько не пробывал — никак неполучается переконвертировать базу (она изначально в utf8).
    Если не сложно, расскажите по подробнее, по пунктам, т.к. опыта ещё немного в этом.
    Стоит: MySQL, NaviCat.
    Заранее Благодарю!

    комментарий от Денис — Июнь 2, 2008 @ 6:24 пп

  23. 1. Не понятно, о какой конвертации идёт речь (форума/кодировки)?
    2. Зачем переходить на cp1251, если все дороги ведут к Юникоду?
    3. Что такое «кодировка форума»?

    В любом случае изменение кодировки в базе подробно описана в моей заметке, которую вы комментируете. Подробней расписать — это перейти на уровень атомов и электронов.

    комментарий от 4matic — Июнь 2, 2008 @ 6:53 пп

  24. Вот это да!!! А я всё ищу как мне переконвертить latin1 в нормальную кодировку. Мегаспасибо!

    комментарий от Евгений Злобин — Июнь 7, 2008 @ 5:11 пп

  25. Одни вопросы, у меня тоже!
    1. MySQL v5.0 — база и таблицы в cp1251.
    2. в PHP при соединении:
    query(«SET character_set_client = ‘cp1251′»);
    query(«SET character_set_connection = ‘cp1251′»);
    query(«SET character_set_results = ‘cp1251′»);
    query(«SET NAMES ‘cp1251′»);
    set_charset(«cp1251»);
    все что можно.
    При ответе:

    3. На клиенте то-же charset=windows-1251
    Когда получаю данные для HTML от MySQL все хорошо!
    Посылаю запрос до PHP и обратно через GET или POST передается странно.
    $inputValue = $_POST[‘inputValue’];
    echo $inputValue; // нормально
    echo «Просто текст»; // квадратики (не знаки ?)
    Текст из $inputValue MySQL не видит.
    На MySQL идут квадратики может и обратно. Т.е. между PHP и MySQL идет перекодировка!
    Какие могут быть пожелания?!

    комментарий от oleg_at — Июнь 16, 2008 @ 3:27 пп

  26. У меня такая ситуация mysql 5.0.45 в принципе работает кодировки понимает(во всяком случае правильно отображает) только неправильно сортирует. Попробовал несколько вариантов приведенных выше но столкнулся с тем что mysql постоянно выдает:
    Warning: World-writable config file ‘/etc/my.cnf’ is ignored

    Стоит на FreeBSD 6.3

    комментарий от Александр — Август 11, 2008 @ 2:43 пп

  27. все таки utf или utf-8? аффтар, апределись!

    комментарий от непонятка — Октябрь 1, 2008 @ 11:25 пп

  28. Александру
    Warning: World-writable config file ‘/etc/my.cnf’ is ignored
    значит что у тебя права на запись в файлик стоят для всех, это ему не нравится и он его игнорирует. chmod o-w ‘/etc/my.cnf для счастья.

    комментарий от zloZ — Октябрь 13, 2008 @ 3:10 пп

  29. У меня ситуация такая:
    Сайт двуязычный рус/латышский.
    Кодировка сайта utf-8 .На страницах, которые видит посетитель всё ОК , а вот в административной панели
    полный бардак. Спачало были ?????? Вставил (по совету добрых людей)
    mysql_query («SET NAMES utf-8»);
    Вопросики пропали. Латышский текст — отлично.Русский превратился вот в это :ТУРБО Р”пїЅ?ЗЕЛЬ
    И, что интересно, одна и та же строка в разных местах отображается по разному
    Например тот же текст в другом месте выглядит так: ТУРБО Д�?ЗЕЛЬ
    Попробовал рецепт из этой статьи — не помогло. Видимо что-то я не догоняю.
    Если не трудно ещё раз. Для тупых.

    комментарий от Владимир — Октябрь 28, 2008 @ 10:23 пп

  30. вот-вот! у меня та же проблема что и у Владимира!

    «Вставил (по совету добрых людей)
    mysql_query (”SET NAMES utf-8″);
    Вопросики пропали. Латышский текст — отлично.Русский превратился вот в это :ТУРБО Р”пїЅ?ЗЕЛЬ
    И, что интересно, одна и та же строка в разных местах отображается по разному
    Например тот же текст в другом месте выглядит так: ТУРБО Д�?ЗЕЛЬ
    Попробовал рецепт из этой статьи — не помогло.»

    третий день разобраться пытаюсь. и ничего не получается(((

    комментарий от Irene — Ноябрь 15, 2008 @ 10:05 пп

  31. Еще раз убедился в том, что все гениальное — просто. Огромное спасибо автору статьи! Способ, описанный в ней сработал, что назывется, «На Ура!» Только хочется еще сделать одно маленькое, но существенное дополнение. После проведения вышеописанной операции после «mysql_connect», в конфигурационном файле сайта, надо обязательно добавить строчку mysql_query(«set CHARACTER SET utf8»); . В моем случае, нужная мне кодировка кодировка была utf8. Для другой кодировки нужно вместо utf8 прописать нужную Вам кодировку. После этого все становится на свои места. К сожалению, автор забыл указать на этот нюанс. Но, все равно, еще раз огромное спасибо за статью. В ней отлично описана сама физика процесса.

    комментарий от Сергей — Декабрь 2, 2008 @ 10:19 пп

  32. Спасибо большое за статью. Отдельное спасибо Сергею за mysql_query(”set CHARACTER SET utf8″);.4 дня бился. Действительно всё гениальное просто)

    комментарий от Николай — Январь 26, 2009 @ 11:08 дп

  33. Спасибо kript, очень помогло.
    У моей базы была MySQL-кодировка: UTF-8 Unicode (utf8).
    Мучался 4 дня, плясал с бубном вокруг кодировок таблиц, баз, запросов.
    Сделал так:
    Поставил «Сравнение»(кодирование) для базы (MyBase) в utf8_general_ci
    ALTER DATABASE `MyBase` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
    Поставил «Сравнение»(кодирование) для таблицы (MyTable):
    ALTER TABLE `MyTable` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
    Поставил «Сравнение»(кодирование) для каждого поля (Field1):
    ALTER TABLE `MyTable` CHANGE `Field1` `Field1` CHAR(20) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL;
    ALTER TABLE `MyTable` CHANGE `Field2` `Field2` CHAR(10) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL;
    Потом в своем скрипте, который выводит страницу сайта написал:
    (весь сайт написан в windows-1251, переделать почти нереально)
    $hand=mysql_connect($server,$user,$Pass);
    mysql_select_db($MyBase);
    mysql_query(«SET NAMES ‘cp1251′»);
    Все стало на свои места: принимаю и отсылаю данные в ‘cp1251’, приходя на сервер MySQL они перекодируются автоматически в ‘utf8’ и хранятся в ‘utf8’.

    mysql_query(«show variables;») выводит такой кусок:
    character_set_client cp1251
    character_set_connection cp1251
    character_set_database utf8
    character_set_filesystem binary
    character_set_results cp1251
    character_set_system utf8
    collation_connection cp1251_general_ci
    collation_database utf8_general_ci

    Сапсибо за тему ВСЕМ!

    комментарий от Mihail — Февраль 26, 2009 @ 4:18 пп

  34. Помогите, пожалуйста, с кодировкой все сделала (огромное, кстати, спасибо за советы) — знаки вопроса не появляются при отображении всех данных. Но теперь такая беда — в условии запроса есть переменная, в которой содержится русское слово и из-за этого не происходит поиск по базе данных, следовательно результат нулевой.

    комментарий от elka — Март 23, 2009 @ 2:45 пп

  35. Здравствуйте, такой вопрос:
    У меня стоит VPS под управлением PLESK, и каждый раз при обновлении PLESK + при переносе базы на новый хостинг вылезают проблемы с русскими символами…

    SHOW VARIABLES LIKE ‘ch%’ выводит:

    character_set_client utf8
    character_set_connection utf8
    character_set_database cp1251
    character_set_filesystem binary
    character_set_results utf8
    character_set_server cp1251
    character_set_system utf8
    character_sets_dir /usr/share/mysql/charsets/

    подскажите пожалуйста, как задать для всех полей с utf8 значение cp1251 по умолчанию???

    комментарий от Dime — Март 25, 2009 @ 3:13 пп

  36. Огромное спасибо за статью? Только у меня вопрос: а что храниться данные в cp1251 в базе не могут или конвертация необходима для того чтобы сортировать можно было по нормальному?

    комментарий от kirill — Октябрь 30, 2009 @ 10:28 дп

  37. Не понял вопроса. Перефразируйте.

    комментарий от 4matic — Ноябрь 19, 2009 @ 7:28 пп

  38. самый быстрый и простой вариант добавить строчку в connect.php

    mysql_query(«SET NAMES ‘cp1251′»);

    комментарий от Александр — Февраль 13, 2010 @ 3:10 пп

  39. Огромное спасибо за mysql_query(«set CHARACTER SET utf8»); !!!!!!

    комментарий от crashman — Февраль 14, 2010 @ 9:34 пп

  40. бред — ниче не помогает.
    Как изменить кодировку mysql по умолчанию чтобы при запросе show variables во всех параметрах прописывалось не latin1 а cp1251???
    Тогда мож и не будет проблем с отображением на пхп.

    комментарий от егор — Октябрь 1, 2010 @ 5:10 пп

  41. Большое спасибо вот это мне помогло

    «ALTER TABLE tbl_name CONVERT TO CHARACTER SET charset_name;»

    комментарий от Polo — Октябрь 30, 2010 @ 11:54 дп

  42. Альтернативный вариант конвертации данных на кириллице из корявой Latin1 в utf8:
    set names utf8;
    # @str строка с примерно таким содержанием òîðèíã (отображение в latin1) .
    set @str = convert(@str using binary); # снимаем кодировку и получаем бинарную строку, то бишь её двоичное представление.
    set @str = convert(@str using cp1251); # накладываем корректную кодировку на двоичное представление-> получаем необходимые нам символы.
    set @str = convert(@str using utf8);# переводим наши символы в юникод.
    алгоритм вне зависимости от средств остаётся одинаковым: получили бинарную строку -> наложили cp1251 -> конвертируем в юникод.
    пы.сы. а я уж почти решился на последовательный парсинг и подмену hex(@str)…. статья приоткрыла глаза, спасибо.

    комментарий от кракозябла — Ноябрь 29, 2011 @ 4:47 пп


RSS feed for comments on this post. TrackBack URI

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

Блог на WordPress.com.

%d такие блоггеры, как: