SQL не различает u и ü, хотя сопоставление utf8mb4_unicode_ci

Сопоставление и набор символов - две разные вещи.

Набор символов — это просто «неупорядоченный» список символов и их представление. utf8mb4 — это набор символов, который охватывает множество символов.

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

В utf8mb4_unicode_ci все (большинство?) символы с акцентом рассматриваются как один и тот же символ, поэтому вы получаете u и ü. Короче говоря, эта сортировка нечувствительна к акценту.

Это похоже на тот факт, что немецкие сопоставления обрабатывают ss и ß как одно и то же.

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

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

Вот пример использования похожей, но, возможно, более знакомой части сопоставления:

ci в конце сопоставления означает Case Insensitive, и почти все сопоставления с ci имеют пару, заканчивающуюся на cs, что означает Case Sensitive.

Если ваш столбец нечувствителен к регистру, условие where column = 'foo' найдет все это: foo Foo fOo FoO Foo FoO fOO, FOO.

Теперь, если вы попытаетесь установить сортировку с учетом регистра (например, utf8mb4_unicode_cs), все приведенные выше значения будут рассматриваться как разные значения.

Локализованные сопоставления (например, немецкий, британский, американский, венгерский и т. д.) следуют правилам именованного языка. В Германии ss и ß одинаковы, и это указано в правилах немецкого языка. Когда немецкий пользователь ищет значение Straße, он будет ожидать, что программное обеспечение (поддерживающее немецкий язык или написанное в Германии) вернет как Straße, так и Strasse.

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

Не забывайте, что ограничение UNIQUE — это всего лишь способ упорядочивания/фильтрации значений. Таким образом, если в столбце с немецким сопоставлением определен уникальный ключ, он не позволит вставить как Straße, так и Strasse, поскольку по правилам языка они должны рассматриваться как равные.

Теперь давайте посмотрим на нашу исходную сортировку: utf8mb4_unicode_ci. Это «универсальная» сортировка, что означает, что она пытается упростить все, поэтому, поскольку ü не очень распространенный символ, и большинство пользователей понятия не имеют, как его вводить, эта сортировка делает он равен u. Это упрощение для поддержки большинства языков, но, как вы уже знаете, такого рода упрощения имеют некоторые побочные эффекты. (например, при упорядочении, фильтрации, использовании уникальных ограничений и т. д.).

utf8mb4_bin — это другой конец спектра. Это сопоставление разработано, чтобы быть настолько строгим, насколько это возможно. Для этого он буквально использует коды символов для различения символов. Это означает, что каждая форма символа отличается, это сопоставление неявно чувствительно к регистру и ударению.

У обоих есть недостатки: локализованные и общие сопоставления предназначены для одного конкретного языка или для предоставления общего решения. (utf8mb4_unicode_ci является «расширением» старого сопоставления utf8_general_ci)

Двоичный файл требует особой осторожности, когда дело доходит до взаимодействия с пользователем. Поскольку это CS и AS, это может сбить с толку пользователей, которые привыкли получать значение «Foo», когда они ищут значение «foo». Кроме того, как разработчик, вы должны быть особенно осторожны, когда речь идет о объединениях и других функциях. ВНУТРЕННЕЕ СОЕДИНЕНИЕ 'foo' = 'Foo' ничего не вернет, так как 'foo' не равно 'Foo'.

Я надеюсь, что эти примеры и объяснения немного помогут.

utf8_collations.html перечисляет, какие буквы "равны" в различных сопоставления utf8 (или utf8mb4). За редким исключением все диакритические знаки удаляются перед сравнением в любом ..._ci сопоставлении. Некоторые исключения зависят от языка, а не от Unicode в целом. Пример: в исландском É > E.

..._bin — это единственная сортировка, которая учитывает буквы с акцентом как разные. То же самое для складывания корпуса.

Если вы часто сравниваете, вам следует изменить порядок сортировки столбца на ..._bin. При использовании предложения COLLATE в WHERE нельзя использовать индекс.

Примечание к ß. ss = ß практически во всех сопоставлениях. В частности, utf8_general_ci (который раньше был значением по умолчанию) рассматривал их как неравные. Этот один вариант сортировки не пытался рассматривать любую комбинацию из двух букв (ss) как одну "букву". Кроме того, из-за ошибки в версии 5.0 utf8_general_mysql500_ci относится к ним неодинаково.

В дальнейшем utf8mb4_unicode_520_ci является лучшим до версии 5.7. Для 8.0 utf8mb4_0900_ai_ci "лучше". «520» и «900» относятся к стандартам Unicode, поэтому в будущем могут появиться еще более новые.

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

Я просто добавлю к другим ответам, что сопоставление _bin также имеет свои особенности.

Например, после следующего:

CREATE TABLE `dummy` (`key` VARCHAR(255) NOT NULL UNIQUE);
INSERT INTO `dummy` (`key`) VALUES ('one');

это не удастся:

INSERT INTO `dummy` (`key`) VALUES ('one ');

Это описано в разделе бинарные сопоставления по сравнению с сопоставлениями _bin< /а>.

Изменить: я разместил связанный вопрос здесь.