Почему SQL Server считает N '' 㐢 㐢 㐢 'и N' 㐢 㐢 㐢 'равными?

Question

Мы тестируем наше приложение на совместимость с Юникодом и выбираем случайные символы за пределами латинского набора символов для тестирования.

Как в латинской, так и в японской системах сопоставления выполняется следующее равенство ( U + 3422 ):

N'㐢㐢㐢㐢' = N'㐢㐢㐢'

но следующее не ( U + 30C1 ):

N'チチチチ' = N'チチチ'

Это было обнаружено, когда тестовый пример с использованием первого примера (с использованием U + 3422) нарушил уникальный индекс. Нужно ли нам быть более разборчивыми в отношении символов, которые мы используем для тестирования? Очевидно, мы не знаем семантического значения приведенных выше сравнений. Будет ли это поведение очевидным для носителей языка?

Answer 1

У Майкла Каплана есть запись в блоге, где он объясняет, как сравниваются строки Unicode. Все сводится к тому, что строка должна иметь вес, в противном случае она будет считаться равной пустой строке.

Сортировка всего: жюри не примет эту строку

В SQL Server на этот вес влияет определенное сопоставление. Microsoft добавила соответствующие параметры сортировки для унифицированных идеографов CJK в Windows XP / 2003 и SQL Server 2005. В этой статье рекомендуется использовать Chinese_Simplified_Pinyin_100_CI_AS или Chinese_Simplified_Stroke_Order_100_CI_AS:

Вы всегда можете использовать любые двоичные и двоичные2 сопоставления, хотя это не даст вам лингвистического правильного результата. Для SQL Server 2005 вы ДОЛЖНЫ использовать Chinese_PRC_90_CI_AS или Chinese_PRC_Stoke_90_CI_AS, которые поддерживают сравнение суррогатных пар (но не лингвистическое). Для SQL Server 2008 вы должны использовать Chinese_Simplified_Pinyin_100_CI_AS и Chinese_Simplified_Stroke_Order_100_CI_AS, которые имеют лучшее лингвистическое суррогатное сравнение. Я предлагаю вам использовать эти параметры сортировки в качестве параметров сортировки сервера / базы данных / таблицы вместо передачи имени параметров сравнения во время сравнения.

Таким образом, следующий оператор SQL будет работать, как и ожидалось:

select * from MyTable where N'' = N'㐀' COLLATE Chinese_Simplified_Stroke_Order_100_CI_AS;

Список всех поддерживаемых параметров сортировки можно найти в MSDN:

Электронная документация по SQL Server 2008: имя для сопоставления Windows

Answer 2

Этот символ U + 3422 взят из таблиц CJK Unified Ideographs , которые являются относительно неясной (и политически загруженной) частью стандарта Unicode. Я предполагаю, что SQL Server просто не знает эту часть - или, возможно, даже намеренно не реализует ее из-за политических соображений.

Редактировать : похоже, мое предположение было неверным, и реальная проблема заключалась в том, что ни латиница, ни японская сортировка не определяют веса для этого символа.

Answer 3

Если вы посмотрите на страницу данных Unihan , у персонажа, по-видимому, есть только поле «K-Source», которое соответствует отображению правительства Южной Кореи.

Я предполагаю, что MS SQL спрашивает "является ли этот символ китайским?" Если это так, тогда используйте японский стандарт сортировки, отбрасывая символ, если номер сортировки недоступен - скорее всего, проблема, связанная с сервером SQL.

Я очень сомневаюсь, что это политический спор, как предложил другой плакат, поскольку у персонажа даже нет картографирования кодирования Тайваня или Гонконга.

Дополнительная техническая информация: J-Source (порядок сортировки в Японии, предписанный правительством Японии) является пустым, поскольку он, вероятно, использовался только в классической корейской хандже (китайские символы, которые теперь используются только в некоторых контекстах.)

Стандарты сортировки JIS правительства Японии обычно сортируют символы Kanji по японскому при чтении (обычно это приблизительное китайское произношение, когда символы были импортированы в Японию). Но этот символ вероятно, не очень часто используется в японском языке и может даже не иметь японского произношения, связанного с ним, поэтому не был добавлен к данным.