- Sergey Danielyan
- Корректная настройка MySQL для работы с UTF8
- Рабочее окружение
- Параметры кодировок MySQL
- Кодировка (character set) и представление (collation) сервера
- Кодировка (character set) и представление (collation) базы данных
- Кодировка (character set) и представление (collation) таблиц
- Кодировка (character set) и представление (collation) колонок в таблице
- skip-character-set-client-handshake
- Верификация настроек
- Работа MySQL со строками
- Русскоязычные кодировки
- Сопоставления символов
- Кодировки символов в MySQL
- Кодировки по умолчанию и смена кодировки строк в MySQL
- Сопоставления в MySQL
- Клиентские кодировки MySQL
- Хранение информации в MySQL
- В MySQL знаки вопросов вместо русских букв — решение проблемы с кодировкой
- Исправляем знаки вопросов в MySQL на русские буквы
- Исправление проблемы кодировки MySQL, если запрос SET NAMES не помог
- Ничего не помогает, проблема кодировки MySQL так и осталась
- Также обратите внимание и на эти моменты при работе с базами данных
- Русский язык кодировка sql
- Русские буквы и символы в PHP скриптах и базе данных MySQL
- Обычный вывод в PHP
- Ошибки с русским текстом в базе данных MySQL
- Знаки вопроса при выводе данных из базы данных MySQL
- Видео
Sergey Danielyan
Корректная настройка MySQL для работы с UTF8
Основная цель данного поста — выяснить, какие параметры и с какими значениями следует прописать в конфигурационный файл my.cnf (my.ini) для дальнейшей беспроблемной работы с Юникодом.
Рабочее окружение
UTF8 на данный момент у меня успешно работает в Мастер-Слейв конфигурации:
Любой внешний клиент в состоянии корректно работать с UTF8 базой (проверено на EMS Manager for MySQL c Windows 8 x64).
Все опции и настройки я привожу для версии сервера 5.1.x, однако с минимальными (а то и вовсе без оных) изменениями все это будет работать и на версиях 5.5.x и 5.6.x.
Параметры кодировок MySQL
Довольно часто приходится видеть в ответах на вопросы о настройке UTF8 следующее:
Предполагается, что после вставки всего этого добра (тут кстати есть противоречащие друг другу опции) в конфигурационный файл my.cnf (my.ini) магический Юникод начнет работать.
Но давайте забудем о списке и попытаемся разбираться со всеми опциями сами и начнем с самого начала. То есть с документации. Потому как все это прекрасно описано в документации MySQL на официальном сайте. Я лишь постараюсь последовательно рассказать о параметрах сервера и прояснить неясные моменты.
Символьная кодировка может быть задана для:
Сделано это для гибкой настройки баз данных и доступа клиентов с разными кодировками. Однако, последнее не входит в область рассмотрения данного поста, поэтому будем рассматривать вариант с кодировкой UTF8 настроенной для всего по-умолчанию.
Все параметры могут быть переданы серверу тремя разными способами:
Второй и третий варианты рассматриваться не будут. Тут уместно будет просто прочитать официальные доки — в каждом разделе приведены примеры конфигурации с использованием всех трех способов. Я же буду использовать первый вариант.
Кодировка (character set) и представление (collation) сервера
Тут есть несколько фундаментальных вещей которые надо понимать.
Можно задать оба параметра либо только один из них. При этом важно знать как задача того или иного влияет на определение отсутствующего:
SHOW COLLATION LIKE ‘your_character_set_name’;
Поле Default дает ответ о представлении выбранной кодировки.
В нашем случае, при настройке дефолтной кодировки в UTF8, параметры должны быть определены, так как могут быть использованы при определении кодировки или представления базы данных:
Наши команды:
my.cnf (my.ini)
[mysqld]
character-set-server = utf8
collation-server = utf8_unicode_ci
Кодировка (character set) и представление (collation) базы данных
Тут есть два варианта определения кодировки и представления:
явно — при выполнении запроса на создание базы данных:
CREATE DATABASE db_name CHARACTER SET latin1 COLLATE latin1_swedish_ci;
Вообще при работе с базой данных огромную роль помимо серверных настроек играют настройки клиент-серверного соединения (connection). На этом этапе вступают в игру следующие специфичные для соединения параметры:
Есть еще представление кодировки соединения ( colation_connection ). Для чего нужен этот параметр думаю пояснять не надо.
Озадачиваться проблемой инициализации всех этих переменных не стоит (хотя в нашем случае присвоить им значения необходимо). Есть способ проще: существует два типа запросов (statements) которые задают настройки соединения клиента с сервером группой:
Запрос SET NAMES ‘charset_name’ [COLLATE ‘collation_name’]
Параметр определяет в какой кодировке теперь будут приходить сообщения для сервера от клиента. Прелесть в том, что запрос SET NAMES x эквивалентен следующей группе:
SET character_set_client = x;
SET character_set_results = x;
SET character_set_connection = x;
Для определении представления кодировки соединения ( colation_connection ) отличного от дефолтного, следует дополнить запрос:
SET NAMES x COLLATE y
SET NAMES utf8 COLLATE utf8_unicode_ci
Таким образом, используя только этот запрос, можно добиться корректной UTF8 инициализации соединения.
Однако, тут есть один нюанс:
init_connect=‘SET collation_connection = utf8_unicode_ci’
Запрос SET CHARACTER SET charset_name
Запрос групповой и он также эквивалентен следующей группе:
SET character_set_client = x;
SET character_set_results = x;
SET collation_connection = @@collation_database;
Согласно документации, разница между двумя запросами в том, что параметры character_set_connection и collation_connection будут установлены на @@character_set_database и @@collation_database соответственно (выше я про них упоминал).
Наши команды:
my.cnf (my.ini)
[client]
default_character_set = utf8
[mysqld]
init_connect=‘SET collation_connection = utf8_unicode_ci’
Кодировка (character set) и представление (collation) таблиц
Тут все довольно просто. Задать кодировку и ее представление можно через команды:
CREATE TABLE t1 ( … )
CHARACTER SET utf8 COLLATE utf8_unicode_ci;
Тут главное иметь в виду, что если эти настройки не заданы, то берутся настройки базы данных (см. пред. раздел). Нам эти настройки не интересны.
Кодировка (character set) и представление (collation) колонок в таблице
Тут по аналогии с пред. секцией. Если параметры кодировок не указаны, берутся те, что указывались для таблицы.
Прежде чем перейти к след. разделу, должен сказать, что все команды и запросы относятся к указанной версии MySQL и в случае возникновения каких-либо проблем советую обратиться к соответствующей версии документации.
skip-character-set-client-handshake
Верификация настроек
Итак, вот финальный snapshot наших изменений в файле my.cnf (my.ini):
[mysqld]
init_connect=‘SET collation_connection = utf8_unicode_ci’
character-set-server = utf8
collation-server = utf8_unicode_ci
[client]
default-character-set = utf8
После применения всех опций и рестарта сервера mysql для проверки настроек можно воспользоваться командами SHOW VARIABLES LIKE ‘char%’ и SHOW VARIABLES LIKE ‘collation%’ ;
Состояние среды до изменений:
Состояние среды после изменений (в случае, если вы приконнектились не SUPER пользователем):
Для примера, вот отличие при соединении через mysql.exe пользователем с и без привилегии SUPER:
с привилегией и выполненной вручную командой ‘SET collation_connection = utf8_unicode_ci’:
Поздравляю, теперь ваши база, таблицы и все в таблицах по-умолчанию в кодировке UTF8.
Работа MySQL со строками
Начиная с версии 4.0, сервер MySQL поддерживает преобразование кодировок символов. Эта статья рассказывает о том, что такое кодировки, сопоставления и о том, как работать с ними применительно к серверу MySQL.
Русскоязычные кодировки
Традиционно в России использовались четыре кодировки для представления русских символов:
Эти четыре кодировки имеют как общие черты, так и различия. Во-первых, все они используют один байт информации для хранения одного символа. Во-вторых, они совместимы с кодировкой latin1, т.е. у них совпадают первые 128 байт таблицы кодировки. Различаются же значения символов с установленным верхним битом (т.е. со значениями 128-255).
Даже четыре кодировки символов для одного языка — это очень много. Изначально люди не придавали этому значения, но в последние несколько лет это стало не так. Возникли разнообразные проблемы переносимости программ, и люди решили создать обобщающие кодировки, содержащие символы всех языков мира (в том числе, разумеется, и русского).
Так была создана кодировка Unicode (UCS-2). Разумеется, невозможно разместить очень большое количество символов в 8 битах, поэтому в этой кодировке используются 2 байта (т.е. 16 бит) на каждый символ. Строки в этой кодировке, безусловно, занимают больше места, чем в старых кодировках, но зато приложения, использующие такие строки, очень легко переносятся на другие языки.
Не смотря на введение UCS-2, некоторые проблемы все-же остались. Во-первых, это уже указанное увеличение длины строки. Люди, использующие только латинские символы, не могли для себя понять, почему они должны использовать 16 бит для обозначения символов, которые уместятся в 7 бит. Во-вторых, 65536 символов все равно не хватает для обозначения всех используемых символов на планете.
Для преодоления этих трудностей, была создана кодировка с переменной длиной символа UTF-8. В этой кодировке используется 1 байт для обозначения первых 128 символов (т.е. символов, входящих в latin1). Если установлен верхний бит первого байта, то используется второй байт (т.е. русские буквы в этой кодировке занимают 2 байта). Если установлен верхний бит второго байта, то используется третий байт (и туда входят разнообразные иероглифы и другие восточные символы) и так далее.
Такая кодировка во-первых, может разместить в себе произвольное количество символов (т.к. она позволяет увеличивать количество байт динамическим образом). Во-вторых, для английского языка используется 1 байт, и это очень приятно для англоговорящих стран. Восточные страны не очень любят эту кодировку, т.к. им приходится использовать 3 байта для обозначения своих символов (в UCS-2 они используют только два).
Сопоставления символов
Некоторые приложения (включая и MySQL, о котором речь пойдет далее) используют не только кодировки, но и сопоставления символов. Дело в том, что некоторые символы некоторые языки считают одинаковыми (а иногда считаются одинаковыми символ или последовательность символов). Например, «ü» в немецком языке может быть записан как «ue». С другой стороны, в шведском языке тот же символ может быть записан как «uy».
В русском языке можно, например, считать одинаковыми буквы «е» и «ё» (как часто делают в официальных документах). Также часто бывает полезным не различать большие и маленькие буквы (которые имеют разный код в любой кодировке).
Сопоставление влияет именно на то, как приложение работает с совокупностью символов, оно влияет на порядок сортировки и на сравнение символов. Разумеется, сопоставление зависит от кодировки символов.
Кодировки символов в MySQL
В сервере MySQL у каждой строки есть своя кодировка и сопоставление. При создании таблицы, Вы можете указать кодировку и сопоставление, в которых будут сохранены строки внутри таблицы. Вы можете даже указывать эти параметры для каждого поля таблицы. Например:
В данном примере создается таблица с двумя полями, одно из которых будет храниться в кодировке KOI8-R (и с сопоставлением по-умолчанию). Второе поле будет иметь сопоставление utf8_general_ci и кодировку UTF-8 (кодировка определяется по сопоставлению, т.к. сопоставление зависит от нее).
Список доступных кодировок и сопоставлений Вы можете получить, соответственно, командами
Кодировки по умолчанию и смена кодировки строк в MySQL
Если Вы не хотите явно указывать кодировку строк в таблице, Вы можете для этой таблицы указать кодировку символов по-умолчанию:
В данном случае, обе строки будут созданы в кодировке CP1251. Вы можете указывать кодировки отдельных строк и в случае указания кодировки по-умолчанию.
Вы также можете изменить кодировку символов для конкретного поля таблицы:
В данном случае, в поле str1 изменяется кодировка и все строки перекодируются. Учтите, что если Вы изменяете кодировку по-умолчанию для таблицы, то строки в ней не перекодируются, Вы просто влияете на создание других полей в этой таблице.
Сопоставления в MySQL
В MySQL для каждой кодировки есть по крайней мере одно сопоставление (а обычно, несколько). Для того, чтобы понять, чем они отличаются, они все имеют очень подробные названия.
Название каждого сопоставления начинается с названия соответствующей кодировки (например, utf8_). Далее идет спецификация сопоставления (чаще всего, идет простое сопоставление, general, не идентифицирующее буквы) и указание на чувствительность к регистру (cs — case sensitive — чувствительно к регистру, ci — case insensitive — не чувствительно).
Отдельно стоит отметить бинарные сопоставления (binary). Если строки сопоставляются бинарным образом, то между ними не делается никаких сопоставлений и преобразований. Такие строки не будут преобразованы командой SET NAMES (см. далее). Бинарные сопоставления особенно удобно использовать при переходе с MySQL 3.23, который не поддерживал кодировки и который указывает, что все таблицы находятся в кодировке latin1 (не смотря на то, что таблицы могут содержать данные, скажем, в KOI8-R).
Клиентские кодировки MySQL
Сервер MySQL автоматически изменяет кодировку строк при занесении данных в таблицу и при выборке данных из таблицы. При этом он использует данные из системных переменных, таких, как character_set_client. Список всех переменных, влияющих на кодировки, Вы можете получить, выполнив команду
Вы можете указывать или переменные по-одиночке, или изменять их сразу большим набором (как требуется в большинстве случаев):
После того, как сервер получит такую команду, он будет ожидать, что Вы будете передавать ему все строки в кодировке KOI8-R и будет автоматически переводить выводимые им строки в эту кодировку.
Это удобно тогда, когда сервер по-умолчанию работает не в той кодировке, которую Вы ожидаете (например, в KOI8-R, а Вы хотите выводить информацию на сайте в CP1251).
Хранение информации в MySQL
MySQL хранит информацию в соответствии с тем, какую кодировку вы указали. Так сервер выделяет по 1 байту на каждый символ для однобайтовых кодировок (при этом CHAR(10) занимает всегда 10 байт, VARCHAR(10) занимает от 1 до 11 байт в зависимости от длины строки, 1 лишний байт тратится на хранение длины строки).
Для кодировки UCS-2 сервер выделяет по 2 байта на каждый символ. Для кодировки UTF-8 сервер выделяет разное количество байт для разных символов (в соответствии с кодировкой) в случае VARCHAR и 3 байта на каждый символ в случае CHAR. Таким образом, в UTF-8 строка CHAR(10) всегда занимает 30 байт, а VARCHAR(10) — от 1 до 31 байта.При этом ни в каком случае при применении UTF-8 сервер не может хранить символы длиной от 4 байт (впрочем, это не накладывает особых ограничений).
В MySQL знаки вопросов вместо русских букв — решение проблемы с кодировкой
При переносе дампа или после нескольких манипуляций в базе неожиданно появились знаки вопросов в MySQL вместо русских букв? Это известная и распространённая проблема в MySQL старших версий.
Это руководство поможет предпринять быстрые шаги в исправлении ситуации.
Мы рассмотрим конкретные действия для быстрого решения. Обратите внимание на официальное руководство по кодировке в MySQL, чтобы вы смогли разбираться в сути и выполнять рекомендации осознанно.
Исправляем знаки вопросов в MySQL на русские буквы
Воспользуйтесь этими быстрыми рекомендациями, чтобы отобразить русские буквы без знаков вопросов и «крякозябр». Ниже мы привели некоторые уточнения.
Дождитесь выполнения соединения с сервером
Введите запрос:
set names кодировка
«кодировка» — это параметр кодировки, в которой вы выводите данные страницы на сайте.
То есть запрос для UTF-8 должен выглядеть так:
set names utf8
А для Windows-1251 вот так:
set names cp1251
Очень часто параметр «Set Names» не помогает решить проблему кодировке при сортировке по имени, хотя буквы отображаются нормально. Как это исправить, читайте далее.
Чтобы не задавать кодировку в каждом скрипте, допишите в my.ini
[mysqld]
init-connect=’SET NAMES utf8′
Исправление проблемы кодировки MySQL, если запрос SET NAMES не помог
Перед тем, как изменить кодировку MySQL, вновь выполните запрос «Set Names», но уже с указанием кодировки таблицы (мы должны её выяснить).
Причина кроется в том, что для таблиц настройка в одной кодировке, а данные в них — в другой.
Попробуйте начать с простого решения — того же запроса «Set Names», но в кодировке таблицы.
Для этого задайте запрос для названия вашей таблицы: show create table `table`
Используйте полученную кодировку в запросе «Set Names»:
SET NAMES кодировка
«кодировка» — это параметр, который показал результат запроса «Show Create Table» из пункта 3 ( DEFAULT CHARSET=кодировка ).
Так вы уберёте «крякозябры» и знаки вопросов из MySQL, настроите правильную отдачу и запись русских букв в данных (главное, чтобы у самой веб-страницы была соответствующая кодировка), но проблему сортировки и поиска пока не решите. Идём дальше.
Теперь, зная кодировку таблицы (например, latin1 ) и имея данные в той же кодировке, мы должны изменить фактическую кодировку данных.
Через mysqldump создайте дамп базы данных.
Главное не перепутать кодировку таблиц с кодировкой данных.
В дампе найдите оператор «Create Database» и проверьте, правильная ли в нём кодировка.
Если нет, то исправьте. Тоже самое можно (и лучше сделать) с оператором «Create Table».
Ничего не помогает, проблема кодировки MySQL так и осталась
Объёмный wiki-раздел по кодировке MySQL составили белорусские коллеги, где вы можете получить исчерпывающее описание процесса правильного создания баз данных и таблиц. Ведь именно в этом процессе кроются все причины возникновения проблемы со знаками вопросов MySQL и «крякозябрами» вместо русских букв.
Также обратите внимание и на эти моменты при работе с базами данных
Не хотите самостоятельно разбираться в настройке MySQL и оптимизировать работу ИТ-инфраструктуры предприятия? Передайте заботы о программном обеспечении в компанию ИТ-аутсорсинга с полноценным ИТ-аудитом и экспертной поддержкой по любым техническим вопросам и задачам.
Русский язык кодировка sql
� MS-SQL �� �������� ��������� (���������) � SQL server management studio!
select * from table
where title like ‘%����%’
���� «title» => varchar(255) �\��� text
��������� � ���� ������ => Collation => Cyrillic_General_CI_AS
=> options => ansi null default
� ��� ����� ���� ��������, ��� ��������� SQL �������� ���������?? ������� ������ �������������� MSSQL??
 Re: MS-SQL �� �������� ��������� (���������) � SQL server management studio! [new] | |
| HandKot Member ������: Sergiev Posad | � ���� ��� �������� ? |
| 13 ��� 12, 14:09����[13157802] �������� | ���������� �������� ���������� | |
| Re: MS-SQL �� �������� ��������� (���������) � SQL server management studio! [new] | |
| Aysvel Member � ��� ��������) ��� � ��� �� ����, ��� � ������ ������ ��������� ���������� ���� «N» | |
| 13 ��� 12, 14:10����[13157815] �������� | ���������� �������� ���������� | |
| Re: MS-SQL �� �������� ��������� (���������) � SQL server management studio! [new] | |
| HandKot Member ������: Sergiev Posad | ��� ��� ����� ������ ������ � ��� SSMS ��������� � ������ ����������, � ��� ��� ��������������� � �� ���� |
| 13 ��� 12, 14:17����[13157884] �������� | ���������� �������� ���������� | |
| Re: MS-SQL �� �������� ��������� (���������) � SQL server management studio! [new] | ||||||||
| Aysvel Member ������: ������ |
| |||||||
