Зачем нужна 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)