MySQL, как и многие современные СУБД, поддерживает широкий набор возможностей для управления кодировками, в которых хранятся ваши текстовые данные. Зачастую этих возможностей так много, что в них легко запутаться. Например, MySQL позволяет указывать кодировку, а также способ сравнения строк, как для всего сервера, так и для отдельной базы данных, для отдельной таблицы или даже для одного поля таблицы. Любая ошибка − и ваш сайт превращается в знакомый всем парад вопросительных знаков.
Чтобы такого не происходило, и чтобы разработчику сайта приходилось как можно меньше думать о кодировках, PHPC предлагает соблюдать несколько несложных правил:
Все данные проекта хранятся в одной и той же кодировке. Для русскоязычных сайтов это CP1251;
Когда дело доходит до обмена данными с MySQL, кодировка явным порядком указывается только для всей базы данных и более нигде и никогда;
Тип сравнения (collation) не указывается вообще нигде, используется значение по умолчанию для выбранной кодировки;
В дампах данных кодировка не указывается нигде и никогда.
Это позволяет хранить кодировку всех данных проекта в одном месте − в параметрах вашей базы данных MySQL. При этом более частные кодировки отдельных таблиц, или отдельных полей, не указываются явно и поэтому нигде не сохраняются, а вместо этого "наследуются" от основной кодировки базы. Меньше повторения данных − меньше вероятность коллизии и ошибки.
Почему PHPC не хранит данные в кодировке UTF-8, а вместо этого использует "устаревшую" кодировку CP1251, спросите вы? Тому есть причины:
UTF-8 − это, по сути, никакая не кодировка, а формат обмена данными, единственным достоинством которого является частичная совместимость с ASCII. Настоящей Unicode-кодировкой является UTF-16, или UCS-2, но она пока мало распространена и плохо поддерживается. Когда PHP и MySQL начнут полноценно поддерживать UTF-16, тогда PHPC, возможно, переедет на юникод;
UTF-8 работает гораздо медленнее других кодировок (из-за непостоянной длины символа в байтах). К примеру, чтобы найти длину строки в CP1251, достаточно взять заранее известную длину ее в байтах. В случае UTF-8 этого недостаточно, необходимо "пробежаться" по всей строке, и посчитать количество открывающих знакомест. В зависимости от структуры и объема ваших данных, переезд на UTF-8 может стоить вам от 3- до 5-кратного замедления строковых операций в MySQL;
Строки в кодировке UTF-8 критичны к своему содержимому, и при добавлении данных может случиться ошибка "строка не является валидной", чего никогда не бывает с однобайтовыми кодировками. То есть все входящие данные нужно дополнительно проверять на соответствие стандартам UTF-8 (так называемая канонизация);
Строки на русском языке, хранимые в кодировке UTF-8, занимают ровно в два раза больше места на диске. Соответственно расходуется и оперативная память сервера.
Вывод простой: если вам не смерть как нужны китайские и японские иероглифы на сайте, используйте однобайтовые кодировки. В случае, если UTF-8 действительно необходим и без него никак, для PHPC существуют соответствующие модули расширения, найти их можно на форуме.
Каждый раз, когда вы заходите в панель управления вашим сайтом, PHPC посылает MySQL-серверу команду:
ALTER DATABASE CHARACTER SET cp1251
То же самое происходит в инсталляторе при установке нового PHPC-проекта. Эта команда означает следующее: установить для всей текущей базы данных кодировку по умолчанию CP1251. После этого, указывать кодировки для каждой создаваемой таблицы по отдельности становится необязательным − будет использована правильная, "базовая" кодировка.
Для создания резервных копий данных и для восстановления базы по ним, для переноса данных с одного сервера на другой, желательно пользоваться функциями "Экспорт БД" и "Импорт БД" в панели управления PHP Compiler:
Во-первых, они генерируют гораздо более "опрятный" дамп данных, по сравнению с phpMyAdmin, без ненужных параметров и атрибутов;
Во-вторых, PHPC генерирует дампы в той же кодировке, что и данные проекта (CP1251), а следовательно, они намного меньше весят;
В-третьих, работа через панель управления PHPC гарантирует, что для вашей базы всегда будет установлена правильная кодировка.
Но если по каким-то причинам вы сделали экспорт данных при помощи phpMyAdmin, то и импортировать их следует также при помощи phpMyAdmin. Не пытайтесь "скормить" дамп от phpMyAdmin админпанели PHPC, и наоборот − это может привести к потере ваших данных.
ICQ: 564226396