Какое сопоставление лучше всего использовать для MySQL с PHP? [закрыто]

Мне интересно, есть ли «лучший» выбор для сортировки в MySQL для общего веб-сайта, где вы не уверены на 100%, что будет введено? Я понимаю, что все кодировки должны быть одинаковыми, например, MySQL, Apache, HTML и все, что находится внутри PHP.

В прошлом я устанавливал PHP для вывода в "UTF-8", но с каким сопоставлением это соответствует в MySQL? Я думаю , что это одна из UTF-8 из них, но я использовал utf8_unicode_ci, utf8_general_ciи utf8_binраньше.

Основным отличием является точность сортировки (при сравнении символов на языке) и производительность. Единственный специальный - это utf8_bin, который предназначен для сравнения символов в двоичном формате.

utf8_general_ciнесколько быстрее чем utf8_unicode_ci, но менее точно (для сортировки). Конкретный язык utf8 кодирование (например utf8_swedish_ci) содержит дополнительные правила языка , которые делают их наиболее точной для сортировки для этих языков. Большую часть времени я использую utf8_unicode_ci(я предпочитаю точность небольшим улучшениям производительности), если у меня нет веских причин предпочитать конкретный язык.

Вы можете прочитать больше о конкретных наборах символов Юникода в руководстве по MySQL - http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-sets.html

На самом деле, вы, вероятно, хотите использовать utf8_unicode_ciили utf8_general_ci.

• utf8_general_ci сортирует, удаляя все акценты и сортируя, как будто это ASCII
• utf8_unicode_ci использует порядок сортировки Unicode, поэтому он сортирует правильно на нескольких языках

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

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

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

Эта проблема раскрывается как минимум в ранних версиях 5.x - я не уверен, изменилось ли это поведение позже.

Я не администратор баз данных, но чтобы избежать этой проблемы, я всегда использую utf8-binвместо регистронезависимого.

Сценарий ниже описывает проблему на примере.

-- first, create a sandbox to play in
CREATE DATABASE `sandbox`;
use `sandbox`;

-- next, make sure that your client connection is of the same 
-- character/collate type as the one we're going to test next:
charset utf8 collate utf8_general_ci

-- now, create the table and fill it with values
CREATE TABLE `test` (`key` VARCHAR(16), `value` VARCHAR(16) )
    CHARACTER SET utf8 COLLATE utf8_general_ci;

INSERT INTO `test` VALUES ('Key ONE', 'value'), ('Key TWO', 'valúe');

-- (verify)
SELECT * FROM `test`;

-- now, expose the problem/bug:
SELECT * FROM test WHERE `value` = 'value';

--
-- Note that we get BOTH keys here! MySQLs UTF8 collates that are 
-- case insensitive (ending with _ci) do not distinguish between 
-- both values!
--
-- collate 'utf8_bin' doesn't have this problem, as I'll show next:
--

-- first, reset the client connection charset/collate type
charset utf8 collate utf8_bin

-- next, convert the values that we've previously inserted in the table
ALTER TABLE `test` CONVERT TO CHARACTER SET utf8 COLLATE utf8_bin;

-- now, re-check for the bug
SELECT * FROM test WHERE `value` = 'value';

--
-- Note that we get just one key now, as you'd expect.
--
-- This problem appears to be specific to utf8. Next, I'll try to 
-- do the same with the 'latin1' charset:
--

-- first, reset the client connection charset/collate type
charset latin1 collate latin1_general_ci

-- next, convert the values that we've previously inserted
-- in the table
ALTER TABLE `test` CONVERT TO CHARACTER SET latin1 COLLATE latin1_general_ci;

-- now, re-check for the bug
SELECT * FROM test WHERE `value` = 'value';

--
-- Again, only one key is returned (expected). This shows 
-- that the problem with utf8/utf8_generic_ci isn't present 
-- in latin1/latin1_general_ci
--
-- To complete the example, I'll check with the binary collate
-- of latin1 as well:

-- first, reset the client connection charset/collate type
charset latin1 collate latin1_bin

-- next, convert the values that we've previously inserted in the table
ALTER TABLE `test` CONVERT TO CHARACTER SET latin1 COLLATE latin1_bin;

-- now, re-check for the bug
SELECT * FROM test WHERE `value` = 'value';

--
-- Again, only one key is returned (expected).
--
-- Finally, I'll re-introduce the problem in the exact same 
-- way (for any sceptics out there):

-- first, reset the client connection charset/collate type
charset utf8 collate utf8_generic_ci

-- next, convert the values that we've previously inserted in the table
ALTER TABLE `test` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;

-- now, re-check for the problem/bug
SELECT * FROM test WHERE `value` = 'value';

--
-- Two keys.
--

DROP DATABASE sandbox;

Лучше всего использовать набор символов utf8mb4с сопоставлением utf8mb4_unicode_ci.

Набор символов, utf8поддерживает только небольшое количество кодовых точек UTF-8, около 6% возможных символов. utf8поддерживает только базовую многоязычную плоскость (BMP). Там 16 других самолетов. Каждая плоскость содержит 65 536 символов. utf8mb4поддерживает все 17 самолетов.

MySQL будет обрезать 4-байтовые символы UTF-8, что приведет к повреждению данных.

Набор utf8mb4символов был введен в MySQL 5.5.3 2010-03-24.

Некоторые из необходимых изменений для использования нового набора символов не являются тривиальными:

• Возможно, потребуется внести изменения в адаптер базы данных приложения.
• В my.cnf необходимо будет внести изменения, включая установку набора символов, сопоставление и переключение innodb_file_format на Barracuda.
• Операторы SQL CREATE могут включать в себя: ROW_FORMAT=DYNAMIC
  • DYNAMIC требуется для индексов на VARCHAR (192) и выше.

ПРИМЕЧАНИЕ. Для переключения Barracudaс Antelope, возможно, потребуется перезапустить службу MySQL более одного раза. innodb_file_format_maxне изменится до тех пор , после того , как служба MySQL перезапущена для: innodb_file_format = barracuda.

MySQL использует старый Antelopeформат файла InnoDB. Barracudaподдерживает динамические форматы строк, которые вам понадобятся, если вы не хотите нажимать на ошибки SQL для создания индексов и ключей после переключения на кодировку:utf8mb4

• # 1709 - Слишком большой размер столбца индекса. Максимальный размер столбца составляет 767 байт.
• # 1071 - Указанный ключ был слишком длинным; максимальная длина ключа 767 байт

Следующий сценарий был протестирован на MySQL 5.6.17: по умолчанию MySQL настроен так:

SHOW VARIABLES;

innodb_large_prefix = OFF
innodb_file_format = Antelope

Остановите службу MySQL и добавьте параметры в существующий my.cnf:

[client]
default-character-set= utf8mb4

[mysqld]
explicit_defaults_for_timestamp = true
innodb_large_prefix = true
innodb_file_format = barracuda
innodb_file_format_max = barracuda
innodb_file_per_table = true

# Character collation
character_set_server=utf8mb4
collation_server=utf8mb4_unicode_ci

Пример оператора SQL CREATE:

CREATE TABLE Contacts (
 id INT AUTO_INCREMENT NOT NULL,
 ownerId INT DEFAULT NULL,
 created timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
 modified timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
 contact VARCHAR(640) NOT NULL,
 prefix VARCHAR(128) NOT NULL,
 first VARCHAR(128) NOT NULL,
 middle VARCHAR(128) NOT NULL,
 last VARCHAR(128) NOT NULL,
 suffix VARCHAR(128) NOT NULL,
 notes MEDIUMTEXT NOT NULL,
 INDEX IDX_CA367725E05EFD25 (ownerId),
 INDEX created (created),
 INDEX modified_idx (modified),
 INDEX contact_idx (contact),
 PRIMARY KEY(id)
) DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci ENGINE = InnoDB ROW_FORMAT=DYNAMIC;

• Вы можете увидеть ошибку # 1709, сгенерированную для INDEX contact_idx (contact)if ROW_FORMAT=DYNAMIC, удаленную из оператора CREATE.

ПРИМЕЧАНИЕ. Изменение индекса до первых 128 символов contactисключает необходимость использования Barracuda сROW_FORMAT=DYNAMIC

INDEX contact_idx (contact(128)),

Также обратите внимание: когда говорится, что размер поля равен VARCHAR(128)128 байтам. Вы можете использовать 128, 4-байтовые символы или 128, 1-байтовые символы.

Этот INSERTоператор должен содержать 4-байтовый символ 'poo' в строке 2:

INSERT INTO `Contacts` (`id`, `ownerId`, `created`, `modified`, `contact`, `prefix`, `first`, `middle`, `last`, `suffix`, `notes`) VALUES
(1, NULL, '0000-00-00 00:00:00', '2014-08-25 03:00:36', '1234567890', '12345678901234567890', '1234567890123456789012345678901234567890', '1234567890123456789012345678901234567890', '12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678', '', ''),
(2, NULL, '0000-00-00 00:00:00', '2014-08-25 03:05:57', 'poo', '12345678901234567890', '💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '', ''),
(3, NULL, '0000-00-00 00:00:00', '2014-08-25 03:05:57', 'poo', '12345678901234567890', '💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '123💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '', '');

Вы можете увидеть количество места, используемого в lastстолбце:

mysql> SELECT BIT_LENGTH(`last`), CHAR_LENGTH(`last`) FROM `Contacts`;
+--------------------+---------------------+
| BIT_LENGTH(`last`) | CHAR_LENGTH(`last`) |
+--------------------+---------------------+
|               1024 |                 128 | -- All characters are ASCII
|               4096 |                 128 | -- All characters are 4 bytes
|               4024 |                 128 | -- 3 characters are ASCII, 125 are 4 bytes
+--------------------+---------------------+

В вашем адаптере базы данных вы можете установить кодировку и параметры сортировки для вашего соединения:

SET NAMES 'utf8mb4' COLLATE 'utf8mb4_unicode_ci'

В PHP это будет установлено для: \PDO::MYSQL_ATTR_INIT_COMMAND

Ссылки:

• Mysql 5.6 Справочное руководство: ограничения на таблицы InnoDB
• Как поддерживать полный Unicode в базах данных MySQL

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

Пример из документации по кодировке Unicode :

utf8_general_ciтакже подходит для немецкого и французского языков, за исключением того, что «ß» равно «s», а не «ss». Если это приемлемо для вашего приложения, то вы должны использовать, utf8_general_ciпотому что это быстрее. В противном случае используйте, utf8_unicode_ciпотому что это более точно.

Так что - это зависит от вашей ожидаемой пользовательской базы и от того, насколько вам нужна правильная сортировка. Для английской пользовательской базы utf8_general_ciдолжно хватить, для других языков, таких как шведский, были созданы специальные сопоставления.

По сути, это зависит от того, как вы думаете о строке.

Я всегда использую utf8_bin из-за проблемы, выделенной Гусом. На мой взгляд, что касается базы данных, строка по-прежнему просто строка. Строка - это число символов UTF-8. Символ имеет двоичное представление, так почему ему нужно знать язык, который вы используете? Обычно люди будут создавать базы данных для систем с многоязычными сайтами. В этом весь смысл использования UTF-8 в качестве набора символов. Я немного приверженец чистоты, но я думаю, что ошибка может сильно перевесить небольшое преимущество, которое вы можете получить при индексации. Любые языковые правила должны выполняться на гораздо более высоком уровне, чем СУБД.

В моих книгах «ценность» никогда не должна равняться миллиону лет.

Если я хочу сохранить текстовое поле и выполнить поиск без учета регистра, я буду использовать строковые функции MYSQL с функциями PHP, такими как LOWER () и функция php strtolower ().

Для текстовой информации UTF-8, вы должны использовать, utf8_general_ciпотому что ...

• utf8_bin: сравнить строки по двоичному значению каждого символа в строке

• utf8_general_ci: сравнивать строки, используя общие правила языка и используя сравнения без учета регистра

иначе это должно сделать поиск и индексацию данных более быстрым / более эффективным / более полезным.

Принятый ответ довольно определенно предполагает использование utf8_unicode_ci, и хотя для новых проектов это здорово, я хотел бы рассказать о своем недавнем противоречивом опыте на тот случай, если он кого-нибудь сэкономит.

Поскольку utf8_general_ci является сопоставлением по умолчанию для Unicode в MySQL, если вы хотите использовать utf8_unicode_ci, вам придется указывать его во многих местах.

Например, все клиентские соединения имеют не только кодировку по умолчанию (имеет смысл для меня), но также и параметры сортировки по умолчанию (т. Е. Параметры сортировки всегда будут по умолчанию utf8_general_ci для юникода).

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

В результате при преобразовании существующей системы любого размера в Unicode / utf8 может возникнуть необходимость использовать utf8_general_ci из-за того, что MySQL обрабатывает значения по умолчанию.

Для случая, выделенного Guus, я настоятельно рекомендую использовать utf8_unicode_cs (чувствительный к регистру, строгое соответствие, правильное упорядочение по большей части) вместо utf8_bin (строгое соответствие, неправильное упорядочение).

Если поле предназначено для поиска, а не для пользователя, то используйте utf8_general_ci или utf8_unicode_ci. Оба регистрозависимы, одно совпадение будет проигрышным («ß» равно «s», а не «ss»). Существуют также языковые версии, такие как utf8_german_ci, где сопоставление с потерями больше подходит для указанного языка.

[Редактировать - почти 6 лет спустя]

Я больше не рекомендую набор символов «utf8» в MySQL, а вместо этого рекомендую набор символов «utf8mb4». Они почти полностью совпадают, но допускают немного (намного) больше символов Юникода.

Реально, MySQL должен был обновить набор символов «utf8» и соответствующие параметры сортировки, чтобы соответствовать спецификации «utf8», но вместо этого - отдельный набор символов и соответствующие параметры сортировки, чтобы не влиять на обозначение хранилища для тех, кто уже использует их неполный набор символов «utf8». ,

Я нашел эти таблицы сравнения полезными. http://collation-charts.org/mysql60/ . Я не уверен, что используется utf8_general_ci, хотя.

Например, вот график для utf8_swedish_ci. Он показывает, какие символы он интерпретирует как одинаковые. http://collation-charts.org/mysql60/mysql604.utf8_swedish_ci.html

В файле загрузки базы данных добавьте следующую строку перед любой строкой:

SET NAMES utf8;

И ваша проблема должна быть решена.