понедельник, 22 ноября 2010 г.

Зачем нужна SHAnsiToUnicode?

Это перевод Whither SHAnsiToUnicode? Автор: Майкл Каплан.

Наш хороший друг Serge Wautier (автор утилиты appTranslator - я как нибудь напишу про неё тоже!) спросил меня в Suggestion Box:
Какова цель функции SHAnsiToUnicode? Я имею ввиду... какие преимущества она имеет в сравнении с обычной MultiByteToWideChar?

Очевидно, у неё меньше параметров. И всё?

TIA,
Очень хороший вопрос. Я и сам задумывался об этом!

Шучу-шучу :-)

Фактически мы, в команде NLS, пытаемся предоставить полную функциональность, которую должна поддерживать какая-то функция, через её параметры и флаги.

Но даже если вы работаете в Microsoft, обычно вы не пытаетесь смотреть на всю картину функциональности целиком. Вы просто решаете одни и те же повседневные задачи. Так что, не имеет значения, работаете ли вы в группе USER, или SHELL, или BCL, или Office, или где-то ещё - вы пишите для себя wrapper макросы и функции. И многие из этих функций в конечном итоге становятся частью документированного официального API. Это особенно применимо к команде Оболочки, потому что у них есть SHLWAPI (Shell Lightweight API), который постоянно обрастает всё новыми и новыми вспомогательными функциями-оболочками.

Это не означает, что функции SHUnicodeToAnsi и SHAnsiToUnicode идеальны для всех применений - они предполагают, что входной буфер нуль-терминирован, и они не дают выбрать кодовую страницу (всегда подразумевая кодовую страницу системы по умолчанию). Вы также не можете изменить символ замены или выбрать дополнительные опции (например, как обрабатывать precomposed/composite символы). В обеих функциях есть даже предупреждение о потенциальной уязвимости, несмотря на тот факт, что обе они гарантируют нуль-терминированность результата.

Но если вам нужно вызвать API функции NLS для выполнения конвертации строки и вы не хотите помнить всю эту семантику, плюс ваши желания по конвертации совпадают с действиями этих функций, то да, эти оболочки могут быть идеальны для этой цели.

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

Одним из недостатков функций-оболочек является то, что параметры и опции весьма ограничены. Если вам нужно изменить что-то, то обычно вы не можете это сделать. Я имею ввиду, что если вы использовали оболочку, а затем вам нужно что-то поменять, но вы не можете это сделать в оболочке и вам приходится заменять все вызовы на полноценный вариант.

Это выглядит достаточно сложно, чтобы вынудить многих людей использовать "настоящие" API всё время...

This post brought to you by "¥" (U+ffe5, a.k.a. FULLWIDTH WON SIGN)

Комментариев нет:

Отправить комментарий

Можно использовать некоторые HTML-теги, например:

<b>Жирный</b>
<i>Курсив</i>
<a href="http://www.example.com/">Ссылка</a>

Вам необязательно регистрироваться для комментирования - для этого просто выберите из списка "Анонимный" (для анонимного комментария) или "Имя/URL" (для указания вашего имени и ссылки на сайт). Все прочие варианты потребуют от вас входа в вашу учётку (поддерживается OpenID).

Пожалуйста, по возможности используйте "Имя/URL" вместо "Анонимный". URL можно просто не указывать.

Ваше сообщение может быть помечено как спам спам-фильтром - не волнуйтесь, оно появится после проверки администратором.