Судья не даст этой строке веса

Это перевод The jury will give this string no weight. Автор: Майкл Каплан.

(заголовок сделан под вдохновением от полтора десятилетия Law & Order на NBC, затем A&E, а сейчас - TNT!)

Я не хочу ругаться на сравнения (collation) в Windows, потому что я считаю, что они сделаны круто. Они покрывают большую территорию и работают (и работают хорошо) в большей части мира. Однако иногда вы можете обнаружить, что вы находитесь на острой грани, отделяющей поддерживаемые возможности. А когда вы на такой грани - то важно не порезаться. Поэтому я попробую поговорить о таких краевых случаях...

Всё начинается в API NLS, которые и обрабатывают сравнения. Когда вы используете функцию CompareString для сравнения двух строк, или LCMapString с флагом MAP_SORTKEY для получения ключа сортировки строки - при этом работает NLS архитектура. А именно, от NLS вовлечена таблица весов, на основе которой эти API и делают лингвистическую работу.

Я обсуждал концепцию веса в предыдущем посте, и в этом посте я собираюсь сказать ещё несколько слов о них.

Главная проблема здесь - хотя таблицы весов, используемые Windows и .NET замечательно работают для всех языков и алфавитов, которые поддерживает Windows, но они не так полезны, когда эти веса не существуют.

Есть много причин, по которым кодовая точка (code point) может не иметь веса. Во-первых, она может не быть допустимой кодовой точкой Unicode - вполне очевидно, что тогда у неё не будет веса.

Или же эта кодовая точка могла появиться в стандарте Unicode уже после того, как операционная система вышла в свет (в этом случае она не будет иметь веса, поскольку у нас нет ясновидящих сотрудников!).

Или, в конце концов, (и вот этот момент немножко отстой) она может быть просто пока не добавлена в наши таблицы. Поэтому...

Если вы попробуете сравнить строки содержащие (к примеру) тибетский алфавит в любой из выпущенных на сегодня версиях Windows, то все строки будут рассматриваться одинаковыми. Если вы попробуете получить ключи сортировки для них - вы обнаружите, что все они не имеют веса. Поэтому любое лингвистическое сравнение таких строк не даст вам никаких полезных результатов; все строки будут равными. И это имеет место даже для строк разной длины!

Вероятно, найдутся разработчики, которые будут спорить против этого последнего момента, но я могу привести такой аргумент. Предположим, что вы сравниваете "hello" (U+0068 U+0065 U+006c U+006c U+006f) и "hëllô" (U+0068 U+0065 U+0302 U+006c U+006c U+006f U+030a), используя CompareString с флагом NORM_IGNORENONSPACE. Вы ожидаете, что эти строки будут равны, несмотря на их длину, потому что вы указали игнорировать диакритические отличия, что, в принципе, означает "не давай веса диакритическим знакам". Поэтому длина здесь не важна - важно, что вес двух строк одинаков.

Вы получите те же результаты, если попробуете сравнить две строки в разных языках, обе из которых не имеют веса (вроде Yi Syllables или кхмерском).

Это произойдёт в Windows 2000 и в SQL Server 2000 с CJK Unified Ideographs Extension A (1.5 Мб) или CJK Unified Ideographs Extension B (13 Мб) - хотя мы исправили это в Windows XP и Windows Server 2003, а также SQL Server 2005.

А в Longhorn (Vista) мы планируем сделать всё, чтобы определить всем хотя бы вес по-умолчанию.

Замечание: исходный вариант этого поста содержал множество тибетских строк, но я не смог его запостить с таким текстом (вероятно, у кого-то были проблемы с этим текстом без веса - быть может у парсера?). Но это случилось только в той первой версии поста. Я поправил его и сумел добавить символы (вроде спонсора поста). Странный баг...

Поскольку (a) MSKLC доступен, (b) спецификации OpenType открыты и (c) в новом "Whidbey" релизе Visual Studio и .NET Framework ожидаются пользовательские культуры, то очевидно, что Microsoft работает над попыткой "убраться с дороги" для тех, кто не хочет ждать появления официальной поддержки их языка в Windows. Да, они правы; мы должны им просто не мешать. И это просто ещё один шаг в этом направлении.

И да, я расскажу больше об этих планах в будущих постах, особенно, когда выйдут VS 2005 Beta 2 и SQL Server 2005 Beta 3, и особенно, когда прозвучат слова о релизе "Longhorn" Windows. Оставайтесь с нами... потому что это будет интересно. :-)

This post sponsored by "ག" (U+0f42, a.k.a. TIBETAN LETTER GA)