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

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

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

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

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

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

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

Ответ 1

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

Сортировка всего: Out: Жюри не придаст этой строке никакого веса

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

Вы всегда можете использовать любые бинарные и двоичные сопоставления, хотя это не даст вам лингвистический правильный результат. Для 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

Ответ 2

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

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

Ответ 3

Если вы посмотрите страницу данных Unihan, у символа появится только поле "K-Source", которое соответствует югу Корейское правительство.

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

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

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

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