(Фактическая проблема, кажется, указана c, но присущие проблемы могут быть обобщены относительно сопоставления, LIKE и Unicode.)
В T- SQL, я тестирую для суррогатных латинских алфавитов (например, вложенный Alphanumeri c дополнение ), например, так:
IF N'Hi??♂️' LIKE N'%[?-?]%' COLLATE Latin1_General_BIN2 PRINT 'Match'; -- why‽
Естественно, кажущиеся единичные эмодзи появляются только как таковые (что не должно быть проблемой) вообще):
[...'??♂️'].map(c=>'U+'+c.codePointAt(0).toString(16)).join(', ').toUpperCase(); // in JavaScript
Я обнаружил, что модификатор ? U+1F3FB (127995) вызывает такое неожиданное поведение в тестовой строке, хотя диапазон ?-? должен быть эквивалентен 127248–127487 с модификатором (127995), конечно, за пределами этого диапазона.
Кроме того, я не могу понять, почему региональные индикаторы из этого блока могут вести себя по-разному в чистых сравнениях по коду:
IF N'?' LIKE N'%[?-?]%' COLLATE Latin1_General_BIN2 PRINT 'Match'; -- ?-? = U+1F1E6 (127462) – U+1F1FF (127487)
Аналогично неожиданно, поскольку при LIKE и при «поисках по диапазону символы, включенные в диапазон, могут различаться в зависимости от правил сортировки параметров сортировки» . Это подходит для использования двоичного сопоставления , потому что оно реализует «чистое сравнение кодовых точек» .
Это ограничение сопоставления или диапазонов? По-разному ли обрабатываются региональные индикаторы или модификаторы эмодзи (т. Е. Объединение символов не пересекается)?