Расскажите всю правду о кодировках в MySQL

Кодировка страницы (текста)

Кодировка подключения/работы к mysql серверу (SET NAMES)

Сравнение (Collation) таблиц/бд

http://google.ru/

Добивайтесь чтобы кодировка всех трех пунктов была одинаковая - заносимого текста; установленного подключения и сравнение бд и ее таблиц.

ну это вроде понятно как

этим пока не пользуюсь вроде как

Это получается при любом запросе надо посылать кодировку? Какбы один раз настроить и всё нельзя? Я правильно понял?

Если вроде как, то лучше воспользоваться ссылкой из предыдущего поста.

http://phpfaq.ru/charset#encodings

спасибо, siv1987. Становится всё более понятней, но вот новый вопрос: зачем всё так сложно? Почему не придумают одну кодировку на все языки?

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

На самом деле, чтобы работать с кодировкой utf-8 надо:

1. Заставить площадку работать в кодировке utf-8, например в .htaccess прописать AddDefaultCharset UTF-8 или средствами хостера

2. Иметь БД в кодировке UTF-8

3. После подключения к БД выполнить запрос mysql_query("SET NAMES UTF8");

продолжение...

или соснуть тунца. 🙅😂

Придумали! Она называется: UTF-8. Предвижу следующий вопрос: зачем придумали все остальные кодировки? :-) Дело в том, что раньше (в прошлом веке) компьютеры были слабенькие, каналы связи - тоненькие, ну в общем, всё было плохо, и приходилось экономить. Для того, чтобы можно было показать в одной кодировке все возможные буквы всех земных алфавитов, требуется по 2 байта места на каждую букву. А если задаваться целью показать только два алфавита (русский и английский, например), то достаточно одного байта на букву. Вот и представьте, если когда-то в прошлом веке страница, размером в 1 килобайт грузилась в браузер минуту, а страница в два килобайта - две минуты. Захотели бы вы заставлять пользователя ждать загрузки вашей страницы лишнюю минуту ради того, чтобы у вас была возможность, если когда-нибудь понадобиться, написать словечко по японски?

С кодировками в MySQL важно понимать следующее: кодировка, она же charset, она же (почти) Collation - задаётся на уровне полей. Кодировка таблицы - это кодировка "по умолчанию", которая будет использована при добавлении в таблицу нового поля, если не будет указана его кодировка в явном виде. Так же, кодировка базы данных - это кодировка по умолчанию, которая будет использована в качестве кодировки таблицы, при создании таблицы, если при этом не указывается другая кодировка. Поэтому удобно и правильно - задать нужную кодировку сразу после создания базы данных (пока она пустая). Тогда дальше (при добавлении таблиц) можно будет о ней не задумываться.

Важно чтобы кодировка полей базы данных соответсвтвовала кодировке ваших интернет-страниц. То есть, к примеру, если вы создали базу данных в UTF-8, то следите за тем, чтобы во-первых, ваш текстовый редактор, которым вы редактируете PHP-скрипты, сохранял файлы в этой же кодировке, и во-вторых, чтобы в разметке этих страниц указывалось: <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> или <meta charset="utf-8" /> для HTML5.

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

mysql_query('SET NAMES utf8');

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

KostaShah, спасибо за расширенный ответ. Теперь всё стало на свои места в моей голове.

Вот так, на пустом месте рождаются легенды. ASCII кодировка создалась за десятилетия до появления слабеньких каналов связи. Создавалась американцами и для американцев, и их вообще не парило наличие других языков. Даже в первой половине 90-х, когда в России уже функционировали коммерческие интернет-каналы, большое количество сетевого оборудования (почтового) резало 8-й бит при передаче данных. Чтобы использовать однобайтовый национальный алфавит и прочие бинарные файлы, придумывались всякие перекодировщики в ascii типа base64 и uuencode - которые совсем не короче utf8. Таким образом, скорость здесь вообще ни при чем. Просто такая логика исторического развития.

а китайцы-то не знают об этом 😕 даром, что у них используются 3-4 байтные символы utf8

SET NAMES то, что вам нужно для соединения приложения с сервером. Само собой, если вы понимаете, на каком этапе ломается кодировка. Потому что прослойка между наблюдателем и базой — веб сервер.