Пересекая DIGITal divide...

Это перевод Crossing the DIGITal divide.... Автор: Майкл Каплан.

Цифры работают в Windows уже какое-то время. Начиная с древнего LCTYPE для GetLocaleInfo и SetLocaleInfo (LOCALE_SNATIVEDIGITS/LOCALE_IDIGITSUBSTITUTION) и их сумасшедше странной поддержке в региональных настройках панели управления до (также древнего) проецирования типов в FoldString для свёртки многочисленных способов представления цифр в простые 0 .. 9 (MAP_FOLDDIGITS) - да, поддержка цифр в Windows уже была какое-то время.

Добавление: я осознал, что я не слишком-то сказал о поддержке свойств в Windows. Хотя в большинстве случаев она очень ограничена (это тема для другого дня!), но для цифр у нас есть отличный метод определения - функция GetStringTypeEx с её типом CT_CTYPE1. Возвращаемый массив информации о символах будет содержать C1_DIGIT для каждой кодовой точки, являющейся цифрой.

Конечно же, в самой Windows жизнь намного проще, потому что у нас нет парсинга строк. В .NET Framework есть парсинг строк, поэтому поддержка цифр здесь сложнее - на текущий момент у нас нет готовой версии, которая имела бы аналоги LOCALE_SNATIVEDIGITS или LOCALE_IDIGITSUBSTITUTION, а также есть откровенные несоответствия между Char.IsDigit (основанного на Unicode) и семантикой метода Parse, которые заметили Реймонд Чен и другие. Последнее осталось неизменным даже в новейшей "coming out RSN" (Real Soon Now) версии .NET Framework (Whidbey), и хотя основа будет поддерживаться в Whidbey в новых свойствах NumberFormatInfo (.NativeDigits и .DigitSubstitution), она носит чисто информационный характер, никак не влияя на результат.

Чтобы сделать всё ещё более запутанным, Whidbey поддерживает новый класс CharUnicodeInfo, у которого есть метод GetDecimalDigitValue. Этот метод даст вам значение Nd (Numeric Digit), которое имеет любая цифра, так что теперь разработчик может не только определить, является ли символ цифрой, но и выяснить, что это за цифра - важный шаг для нормальной работы парсера.

Поэтому возникает интересный вопрос: почему мы имеем все эти полумеры? Зачем делать только половину возможности?

Конечно же, часть проблемы заключается в том, что обозначение её одной возможностью ("поддержка цифр") не отменяет факта, что, на самом деле, она включает в себя множество других возможностей, каждая из которых разрабатывается отдельной командой.

Надев шапку "Извините" (только на один момент, не волнуйтесь!): те вещи, которые уже были добавлены, показывают разработчикам, что у них есть, и позволяют перейти на следующий уровень, делая возможным добавить более сложную поддержку парсинга (типа преобразования U+FF10 .. U+FF19, full-width цифр ０１２３４５６７８９ в их "более тонкие" аналоги) с наименьшей вероятностью задействования хаков. И, может быть, следующая версия CLR после Whidbey будет поддерживать дополнительный шаг в разборе цифр в методах .Parse и регулярных выражениях.

Но основной причиной для добавления NumberFormatInfo.NativeDigits и NumberFormatInfo.DigitSubstitution в Whidbey были CUSTOM CULTURES. Эта возможность - одна из тех, что будет включена в следующие версии Windows, где Longhorn будет использовать ту же поддержку, что и неуправляемый аналог (CUSTOM LOCALES). А чтобы это "разделение возможностей" (feature sharing) работало, было важным, чтобы как минимум текущие возможности поддержки Windows были бы реализованы и в framework-е.

Теперь .NET Framework в следующей своей версии вынуждена будет решить, как сделать оставшиеся два шага и попытаться заполнить белые места в поддержке цифр. Каждая версия даёт хорошую основу (что здорово), но без конечного решения (что совсем не так здорово).