Перенос данных между My SQL версии 4.0 и 4.1
- Автор темы Фанат
- Дата начала
ну какой my.ini на хостинге?
вот в факе тоже - через слово - my.ini. "кто все эти люди? страшно далеки они от народа!"
-~{}~ 22.11.07 10:56:
Pigmeich
спасибо SHOW CREATE TABLE показывает, ага
zerkms
latin1
что пишешь эти команды, что не пишешь.
вот интересно, у меня-то была одна таблица в дампе. а если их сотни?
как же, все-таки, дефолтную кодировку при создании таблиц выставлять?
вот в факе тоже - через слово - my.ini. "кто все эти люди? страшно далеки они от народа!"
-~{}~ 22.11.07 10:56:
Pigmeich
спасибо SHOW CREATE TABLE показывает, ага
zerkms
latin1
что пишешь эти команды, что не пишешь.
вот интересно, у меня-то была одна таблица в дампе. а если их сотни?
как же, все-таки, дефолтную кодировку при создании таблиц выставлять?
*****
эти переменные (а точнее лишь одна из них) влияют на кодировку таблиц лишь косвенно
а именно:
character_set_server определяет кодировку вновь создаваемой БД (если она не указана явно)
а кодировка таблиц - будет такая же, как кодировка у БД (если, опять же, её не указать явно)
Ну, а чего ж тогда этот текст в факе делает?
-~{}~ 22.11.07 16:14:
То есть, по хорошему, фак по кодировкам должен быть таким:
1. Данные из таблицы выводятся в виде ?????????????
set names=кодировка
2.Если новые таблицы создаются (из консоли, скрипта или дампа) не с той кодировкой, которая нужна (посмотреть можно командой SHOW CREATE TABLE), то
а. Если есть возможность, то попросить хостера создать БД заново, указав перед созданием
SET character_set_server=кодировка;
б. Если такой возможности нет, то кодировку таблицы задаем руками. Не забывая указывать и COLLATION
так?
-~{}~ 22.11.07 16:14:
То есть, по хорошему, фак по кодировкам должен быть таким:
1. Данные из таблицы выводятся в виде ?????????????
set names=кодировка
2.Если новые таблицы создаются (из консоли, скрипта или дампа) не с той кодировкой, которая нужна (посмотреть можно командой SHOW CREATE TABLE), то
а. Если есть возможность, то попросить хостера создать БД заново, указав перед созданием
SET character_set_server=кодировка;
б. Если такой возможности нет, то кодировку таблицы задаем руками. Не забывая указывать и COLLATION
так?
а можно как-то посмотреть настройки database?
ага, нашел
use `database`
show variables like "character_set_database";
show variables like "collation_database";
-~{}~ 22.11.07 19:26:
едем дальше
Если заглянуть в интернет, то окажется, что проблема с кодировками в mysql, начиная с версии 4.1, является чуть ли не самой сложной в веб-программировании. постоянно у всех какие-то сложности.
И зачем было вводить эти кодировки? Нет, чтобы оставить все, как раньше - что в базу положил - то и достал, не заботясь, в какой оно кодировке.
Такая возможность, кстати, осталась (binary), но мы о ней не будем.
Итак. Кодировки в MySQL версий 4.1+.
На самом деле, все элементарно просто.
Mysql теперь знает, в какой кодировке она хранит данные.
Если говорить упрощенно, то таблица (а так же - отдельные поля в ней) теперь имеет такие параметры, как кодировка (CHARACTER SET) и сортировка (COLLATION)
Если класть в таблицу данные в другой кодировке - получатся вопросики. Если запрашивать в другой кодировке - появятся вопросики.
Вот и все.
Соответственно, нам надо сделать всего две вещи:
1. Убедиться, что у таблицы установлены нужные параметры кодировки и сортировки.
2. Сказать базе, в какой кодировке в неё поступают данные и из её .
Ответ на второй вопрос знают все: волшебный запрос
set names "кодировка"
Но ведь перед тем, как записывать данные в таблицу, надо сначала эту таблицу создать! Этот вопрос в интернете рассмотрен гораздо хуже. Исправим ситуацию.
Самое простое - это указывать кодировку и сортировку прямо в коде CREATE TABLE. Пример:
CREATE TABLE `chartest` (
`name` varchar(10) default NULL
) ENGINE=MyISAM DEFAULT CHARSET=cp1251 COLLATION=cp1251_general_ci
Но что, если у нас огромный дамп на сотни таблиц, сделанный в прошлой версии MySQL? Дописывать к каждой таблице вручную? Возможно, это и придется делать. Но сначала надо попробовать установить параметры по умолчанию.
Создаваемые таблицы, если для них не указывается collation и charset, берут эти параметры из настройки database.
Следовательно, надо попытаться изменить эти настройки.
сначала смотрим, какие они сейчас.
Заходим в консоль и пишем
use `mydb`
show variables like "character_set_database";
show variables like "collation_database";
Если полученный результат нас не устраивает, то пытаемся переопределить настройки самостоятельно
alter database `mydb` character set cp1251;
alter database `mydb` collate cp1251_general_ci;
если запросы прошли успешно, то проверяем ещё раз, и ,если все нормально, то начинаем создавтаь таблицы или заливать дамп.
Если таким образом сделать не удалось (не хватает прав), то варианта только два - или обращаться к провайдеру, чтобы он сам поменял настройки кодировки и сортировки, или дописывать COLLATION И CHARACTER SET ко всем таблицам вручную.
-~{}~ 22.11.07 20:59:
кто что скажет по вышенаписанному?
и еще вопрос.Какое вообще практическое значение имеет charset?
какое имеет collation - я понимаю
а charset?
из вышенаписанного следует, что важно совпадение кодировки таблицы и кодировки соединения. а уж какая она - дело десятое.
сейчас проверил - точно, в latin1 сайт работает, как ни в чем ни бывало.
в чем суть указания правильной кодировки, если это не мультибайт?
ага, нашел
use `database`
show variables like "character_set_database";
show variables like "collation_database";
-~{}~ 22.11.07 19:26:
едем дальше
Если заглянуть в интернет, то окажется, что проблема с кодировками в mysql, начиная с версии 4.1, является чуть ли не самой сложной в веб-программировании. постоянно у всех какие-то сложности.
И зачем было вводить эти кодировки? Нет, чтобы оставить все, как раньше - что в базу положил - то и достал, не заботясь, в какой оно кодировке.
Такая возможность, кстати, осталась (binary), но мы о ней не будем.
Итак. Кодировки в MySQL версий 4.1+.
На самом деле, все элементарно просто.
Mysql теперь знает, в какой кодировке она хранит данные.
Если говорить упрощенно, то таблица (а так же - отдельные поля в ней) теперь имеет такие параметры, как кодировка (CHARACTER SET) и сортировка (COLLATION)
Если класть в таблицу данные в другой кодировке - получатся вопросики. Если запрашивать в другой кодировке - появятся вопросики.
Вот и все.
Соответственно, нам надо сделать всего две вещи:
1. Убедиться, что у таблицы установлены нужные параметры кодировки и сортировки.
2. Сказать базе, в какой кодировке в неё поступают данные и из её .
Ответ на второй вопрос знают все: волшебный запрос
set names "кодировка"
Но ведь перед тем, как записывать данные в таблицу, надо сначала эту таблицу создать! Этот вопрос в интернете рассмотрен гораздо хуже. Исправим ситуацию.
Самое простое - это указывать кодировку и сортировку прямо в коде CREATE TABLE. Пример:
CREATE TABLE `chartest` (
`name` varchar(10) default NULL
) ENGINE=MyISAM DEFAULT CHARSET=cp1251 COLLATION=cp1251_general_ci
Но что, если у нас огромный дамп на сотни таблиц, сделанный в прошлой версии MySQL? Дописывать к каждой таблице вручную? Возможно, это и придется делать. Но сначала надо попробовать установить параметры по умолчанию.
Создаваемые таблицы, если для них не указывается collation и charset, берут эти параметры из настройки database.
Следовательно, надо попытаться изменить эти настройки.
сначала смотрим, какие они сейчас.
Заходим в консоль и пишем
use `mydb`
show variables like "character_set_database";
show variables like "collation_database";
Если полученный результат нас не устраивает, то пытаемся переопределить настройки самостоятельно
alter database `mydb` character set cp1251;
alter database `mydb` collate cp1251_general_ci;
если запросы прошли успешно, то проверяем ещё раз, и ,если все нормально, то начинаем создавтаь таблицы или заливать дамп.
Если таким образом сделать не удалось (не хватает прав), то варианта только два - или обращаться к провайдеру, чтобы он сам поменял настройки кодировки и сортировки, или дописывать COLLATION И CHARACTER SET ко всем таблицам вручную.
-~{}~ 22.11.07 20:59:
кто что скажет по вышенаписанному?
и еще вопрос.Какое вообще практическое значение имеет charset?
какое имеет collation - я понимаю
а charset?
из вышенаписанного следует, что важно совпадение кодировки таблицы и кодировки соединения. а уж какая она - дело десятое.
сейчас проверил - точно, в latin1 сайт работает, как ни в чем ни бывало.
в чем суть указания правильной кодировки, если это не мультибайт?
Nelius
кипарис во дворе
Вообще я считаю что все эти "замуты" с кодировками это лишнее. Наоборот надо стремиться к чему-то единому, а не тормозить этот процесс. С одной стороны да, удобно (правда я пока не встречал проекта где в одной таблице из 2-х полей типа TEXT одно было в utf-8 а другое в cp1251), но с другой стороны создание единого стандарта намного облегчило бы жизнь программистам и вообще многим людям.
Благо технологии, в наше время, уже достаточно развились для того чтобы можно было себе это позволить.
ИМХО
Благо технологии, в наше время, уже достаточно развились для того чтобы можно было себе это позволить.
ИМХО
ran
Новичок
>Но я уже сам понял - колейшен без чарсета не работают.
и в мануле даже четко написаны правила, по которым collation формируется для каждого charset:
There is a convention for collation names: They start with the name of the character set with which they are associated, they usually include a language name, and they end with _ci (case insensitive), _cs (case sensitive), or _bin (binary).
получается, что charset указывает в какой кодировке будут храниться данные, а collation - на правила работы с ними для разных языков. но если они так зависят друг от друга, то действительно - зачем вообще указывать charset, если collation по-любому его включает.
и в мануле даже четко написаны правила, по которым collation формируется для каждого charset:
There is a convention for collation names: They start with the name of the character set with which they are associated, they usually include a language name, and they end with _ci (case insensitive), _cs (case sensitive), or _bin (binary).
получается, что charset указывает в какой кодировке будут храниться данные, а collation - на правила работы с ними для разных языков. но если они так зависят друг от друга, то действительно - зачем вообще указывать charset, если collation по-любому его включает.
http://www.linux.by/wiki/index.php/FAQ_PHP_MySQL_charset
вот, блин, пример фака по кодировкам 4.1+, каким он должен быть.
а то, что лежит в вики - это пример того, как не должно быть.
вот, блин, пример фака по кодировкам 4.1+, каким он должен быть.
а то, что лежит в вики - это пример того, как не должно быть.
чота вы все много написали
у таблички есть charset и collation
charset - набор символов, являющихся грубо говоря буквами языка (можут быть многобайтовые)
collation - их порядок (правило сортировки)
у клиента есть только charset, может не совпадать с серверным (например, клиент не понимает многобайтные кодировки), нужен для соответствующей перекодировки
у таблички есть charset и collation
charset - набор символов, являющихся грубо говоря буквами языка (можут быть многобайтовые)
collation - их порядок (правило сортировки)
у клиента есть только charset, может не совпадать с серверным (например, клиент не понимает многобайтные кодировки), нужен для соответствующей перекодировки