Кодировки MySQL

Доброе время суток, уважаемые фрилансеры.
Столкнулся с такой проблемой. В какой кодировке хранить русские символы? Чтобы потом корректно делать сортировку по алфавиту и т.д.
Какие должны быть вот эти данные? Server characterset: Db characterset: Client characterset: Conn. characterset:

Цитата:

C:\Program Files\MySQL\MySQL Server 4.1\bin\mysql.exe Ver 14.7 Distrib 4.1.14,
for Win32 (ia32)
Connection id: 1
Current database: products
Current user: admin@localhost
SSL: Not in use
Using delimiter: ;
Server version: 4.1.14-nt
Protocol version: 10
Connection: localhost via TCP/IP
Server characterset: cp1251
Db characterset: latin1
Client characterset: latin1
Conn. characterset: latin1

UTF-8

UTF-8 мультиязычная кодировка, в ней будут корректно сортироваться как русские так и латинские буквы

Простите за ламерство. Но в папке C:\Program Files\MySQL\MySQL Server 4.1\share\charsets
У меня нет кодировки UTF =(

В share/charsets нет отдельного файла или каталога для UTF-8, UCS-2, и еще ряда кодировок. Но они поддерживаются, так как встроено. Если Вы посмотрите в Ваш share/charsets/Index.xml (или в старых версиях MySQL просто Index) - то увидите что UTF-8 там описано.

Спасибо. Пока гуглил свой вопрос нашёл много топиков на эту тематику, почему то в основном все юзают cp1251. С чем это связано? Вроде ведь с utf меньше проблем.
И на какой mysql сделать свой выбор? У меня стоит 4.1.14 - на сколько я знаю этот билд уже старый. Стоит ли переходить на 5*?

Цитата ("DenTal"):

Спасибо. Пока гуглил свой вопрос нашёл много топиков на эту тематику, почему то в основном все юзают cp1251. С чем это связано? Вроде ведь с utf меньше проблем.
И на какой mysql сделать свой выбор? У меня стоит 4.1.14 - на сколько я знаю этот билд уже старый. Стоит ли переходить на 5*?

Проблем на самом деле не меньше. Но удобнее. Переходить на 5 стоит.

Цитата ("DenTal"):

Спасибо. Пока гуглил свой вопрос нашёл много топиков на эту тематику, почему то в основном все юзают cp1251. С чем это связано? Вроде ведь с utf меньше проблем.
И на какой mysql сделать свой выбор? У меня стоит 4.1.14 - на сколько я знаю этот билд уже старый. Стоит ли переходить на 5*?

То, что многие используют cp1251, имеет ряд причин. Во-первых - так сложилось исторически. Ранние версии MySQL, до MySQL 4, не поддерживали UTF-8 в полной мере. А ряд операций типа сортировок работало некорректно вплоть до MySQL 4.1. Вот люди и привыкли использовать cp1251. А новички используют то, что видят в примерах в инете, которым уже много лет и которые, поэтому, на cp1251.

Есть еще одна причина использовать cp1251. Символ кириллицы в cp1251 занимает только 1 байт, а в UTF-8 - 2 байта. То есть налицо экономия пространства. Также, работа с кодировкой cp1251 немного более производительна по скорости, так как, опять же, любой символ занимает один байт, а в UTF-8 длина символа переменная, и может занимать один байт, а может и несколько (для кириллицы 2 байта, для некоторых других может быть и например 4 байта) - и получается что например при сортировке когда идет сравнение строк в случае с UTF-8 делается более сложное преобразование.

Все остальное - это преимущества UTF-8. Например если в БД может храниться не только русский текст, но и нечто на других языках, причем вперемешку, что делать будете? Например главы труда Льва Толского "Война и Мир", где содержится также текст на французском языке. Тут уже нельзя использовать cp1251, так как некоторые символы французского текста будут попорчены.

Или если у Вас есть форум, то что будет если кто-то введет текст не по-русски, а например по-арабски, то получится что его сообщение выведется не в том виде что он ввел, а абракадаброй, ведь при сохранении в БД этот текст будет преобразован в cp1251. В UTF-8 этой проблемы не было бы.

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

Той же данью прогресса нужно руководствоваться, выбирая последние версии MySQL, и уходить о старых (ну еще новые версии стабильнее, содержат больше фич, багфиксы и т.д. - это само собой). Некоторые считают что MySQL 4 работает несколько быстрее в ряде операций. Они правы, так оно и есть при настройках по умолчанию на некоторых конфигурациях. То есть нужно тюнингом заняться, подстройкой конфигурационных параметров MySQL под конкретную задачу.

Спасибо за ответы, вот ещё. Я консультировался у человека с Фриланса. (человек вроде знает своё дело). Вот что он сказал.
Может кто нить прокомментировать? Я честно, ничего не понял. Какие шаблоны? Причём тут кодировка? На php ведь шаблоны делают
DenTal (14:06:04 13/05/2007)
вы не знаете чем обусловлено, что используют в основном 1251, хотя utf8 вроде менее геморный?

Ssergy (14:08:24 13/05/2007)
для utf8 ведь необходимо и код в нем разрабатывать и шаблоны. в 1251 делать удобнее

Ssergy (14:09:30 13/05/2007)
если нет специфических языков используют 1251.
да еще про индексацию поисковиками - точно не знаю но возможно с ютф8 чуть хуже

Цитата ("DenTal"):

Спасибо за ответы, вот ещё. Я консультировался у человека с Фриланса. (человек вроде знает своё дело). Вот что он сказал.
Может кто нить прокомментировать? Я честно, ничего не понял. Какие шаблоны? Причём тут кодировка? На php ведь шаблоны делают

DenTal, Этот человек говорил не о базе данных, а о кодировке шаблонов, из которых строится HTML страница с помощью PHP или еще чего-либо.

Цитата ("DenTal"):

DenTal (14:06:04 13/05/2007)
вы не знаете чем обусловлено, что используют в основном 1251, хотя utf8 вроде менее геморный?

Ssergy (14:08:24 13/05/2007)
для utf8 ведь необходимо и код в нем разрабатывать и шаблоны. в 1251 делать удобнее

Не согласен, в какой кодировке делать шаблоны абсолютно все равно, большинство IDE и текстовых редакторов прекрасно поддерживают кодировку UTF-8.

Даже если Вы используете редактор десятилетней давности который UTF-8 не поддерживает, и не хотите его на что-то другое сменить, всегда можно переконвертировать шаблоны одним махом перед тем как их выкладывать. Или можно их конвертировать прямо из скрипта при предкомпиляции и помещением в кеш. Но это уже избыточно и ненужно, если Вы выберете нормальный редактор, который поддерживает UTF-8 (почти любой поддерживает, например мне нравится Notepad++).

Цитата ("DenTal"):

Ssergy (14:09:30 13/05/2007)
если нет специфических языков используют 1251.
да еще про индексацию поисковиками - точно не знаю но возможно с ютф8 чуть хуже

1251 используют только в тех случаях, которые я описал в постах выше - или по инерции со старых версий движков, или используя CMS которые не умеют работать с UTF-8, или если используют MySQL 3, или если параноидально экономят место на диске (выигрыш копеечный). Или если задача связана с очень большим количеством запросов к базе данных, связанных с поиском/сравнением/сортировкой большого количества строк, и хочется выиграть несколько лишних миллисекунд (выигрыш тоже копеечный).

Про поисковики - неправда. UTF-8 все поисковики понимают прекрасно. Более того, зайдите например на ссылка, и посмотрите исходники страницы. Какая там кодировка по умолчанию? Именно UTF-8.

Недавно я столкнулся с неприятной проблемой. Программы форматирования кода PHP, как оказалось, в массе своей не любят utf-8, да и не все редакторы любят пока.
С другой стороны, некоторые стандартные функции PHP работают исключительно с unicode - например json_encode, так что либо надо перекодировать данные всё время, либо переходить на юникод. Второе проще.

Цитата ("Pilat66"):

Недавно я столкнулся с неприятной проблемой. Программы форматирования кода PHP, как оказалось, в массе своей не любят utf-8, да и не все редакторы любят пока.

Какие такие программы форматирования? И какие редакторы? Да и не должны все любить. Все основные - поддерживают utf и этого достаточно.

По поводу работы с файлами в UTF - попробуйте поработать в программе Zend Studio 5.5, работает со всеми кодировками, очень удобна и существенно повышает производительность кодирования.
(я не пробовал Eclipse, но после Zend пока ничего больше не хочется)

Кроме того, если Вы планируете работать с Ajax + PHP + MySQL база должна быть в UTF-8, головной боли меньше на порядок.

Если пошагово, то наиболее универсальная связка сейчас:
MySQL в кодировке UTF
Все файлы проекта тоже в кодировке UTF
Для кодирования используется или Zend Studio или Eclipse
Для скорости - CakePHP

Версии:
PHP 5 (c предварительным уточнением версии у хостера)
MySQL 5 (или 4, насколько я понимаю сейчас это не так принципиально для Web)

На ближайший год можете забыть об обновлениях...

tuls, вы так классно все расписали.. и даже про Zend стоимостью..ой как немало)
в общем помогите пожалста.. есть таблица
users { id:INT autoinc, username:VARCHAR(100) utf8; password:VARCHAR(32) utf8 - md5 }

есть форма регистрации
UTF-8

<form action="register.php" method="POST">

<input type="text" name="username" value="" />

<input type="password" name="password" value="" />

<input type="submit" />

</form>

Логин - буквы/цифры до 90 символов
Пароль - любые символы вводимые с клавиатуры без извращения (например, символ с кодом 0 ввести с клавиатуры "низя" и т.д... ну как вариант - допустимые символы по Shift+основная цифровая клавиатура)
надо зарегить юзера в базу MYSQL5/latin (mysql/mysqli - не принципиально) таблица users
на ошибки - die('текст' или echo 'Зареген';
Заранее пасиб

Цитата ("ArtLab"):

Цитата ("Pilat66"):

Недавно я столкнулся с неприятной проблемой. Программы форматирования кода PHP, как оказалось, в массе своей не любят utf-8, да и не все редакторы любят пока.

Какие такие программы форматирования? И какие редакторы? Да и не должны все любить. Все основные - поддерживают utf и этого достаточно.

SourceFormatX
ссылка

PHP Code Beautifuler
ссылка

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

Такой вопрос, почему когда ставишь в phpmyadmin кодировку на поле таблицы cp1251, то отображается всякий мусор

Можна ли это изменить при юзании базы под рутом?

Цитата ("jamper"):

Такой вопрос, почему когда ставишь в phpmyadmin кодировку на поле таблицы cp1251, то отображается всякий мусор

Можна ли это изменить при юзании базы под рутом?

ссылка
Тут все ответы по кодировкам.

Ответа на свой вопрос не нашёл.

CREATE TABLE `chartest` (

  `name` varchar(10) default NULL

) ENGINE=MyISAM charACTER SET=utf8

show variables like "%character%"; выдаёт

-----+

| 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       | C:Program FilesMySQLMySQL Server 5.0sharecharsets |

Таким образом всё заточено под utf8 (как мне советовали спецы постами выше)
Пишу данные из php скрипта
SET NAMES не выполняю, так как в ФАКах написано что это имеено если у вас стоит не так кодеровка в my.ini

mysql_query("insert into chartest values('Много-много данных'", $dbh) or die ("Умри!";
Записывает английские буквы пишет отлично, и любой длинны. Русские символы записывает (3-4), притом что VARCHAR(10). Больше оперделённой длинны - вижу надпись Умри! Как так?

PHP - 5.2.3
MySQL - mysql Ver 14.12 Distrib 5.0.45, for Win32 (ia32)
Apache - 2.2.4

Что самое интересно, добавляю mysql_query("SET NAMES 'utf8'"; И всё вроде бы начинает потихоньку работать.
Зачем мне нужна эта строчка если все кодировки я уже прописал в my.ini?
Мб это связано с вот этим багов ссылка
Хотя версия mysql у меня выше.

UTF-8 это 2 байта - не будет ли проблемм с некоторыми сриптами?

librarian, все может быть. php - см. функции с префиксом "mb_".